COP & Zap "can't abort target".

Started by Andrew Lohmann's New Email Server June 25, 2004
Hi, From time to time my P&E BDM debugger with Cosmic Zap will not properly stop my target running, and I get a dialog box "can't abort target". I have got one particular instance where consistently I can't step one more step without the debugger loosing control, and stop then does not work. There a lots of has lots of interrupts including !XIRQ running, even so usually when I press Stop Zap displays a sensible portion of code. There seems to be plenty of stack space, and I have also turned the COP on to see if the target is locked up in a loop, but the COP does not fire, so that's probably not the problem.

I understand "synchronisation lost", so back to the question how does the dialog box "can't abort target" come about? And how can I mitigate it?

There is a follow on question also:-

In my start-up code crsti.s I route:- reset vector __stext and others __trap_isr, _clockmonitor_isr, __cop_isr all change flag bits in a bss byte then jump to WarmStart. In theory I should be able look at that byte in .bss called _SystemFlags and identify the cause of reintialisation. Unfortunately I have misunderstood something about the initialisation of C, because _SystemFlags is always zero. WarmStart is the initialisation before calling f_main.

Here is an excerpt of: crsti.s. you will see that I have added bgnd instructions, but Zap similarly never catches those, even if I don't use the pll, because BDM synchronisation is always lost at the time COP occurred.

__trap_isr:
bgnd // for debugger
bset _SystemFlags, #SystemFlag_TrapWarmStart; // set the warmstart flag AL 02-03-04
bra WarmStart

__clockmonitor_isr:
bgnd // for debugger
brclr CRGFLG, #LOCKIF, NotPllLockFail
bset CRGFLG, #LOCKIF
bset _SystemFlags, #SystemFlag_PllLockWarmStart
NotPllLockFail:
brclr CRGFLG, #SCMIF, WarmStart
bset CRGFLG, #SCMIF
bset _SystemFlags, #SystemFlag_SelfClkWarmStart
bra WarmStart

__cop_isr: //Warm Start AL 02-03-04
bgnd // for debugger
bset _SystemFlags, #SystemFlag_CopWarmStart; // set the warmstart flag AL 02-03-04
bra WarmStart

__stext: ; Normal Reset call (Cosmic)
clr _SystemFlags // flags AL 02-03-04

WarmStart:
// normal initialisation here.

Andrew Lohmann AIIE
Design Engineer

PLEASE NOTE NEW EMAIL ADDRESS IS: Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com





If this is a code problem, it sounds like this type of problem can be easy
to find with a full-emulator.

A full emulator is equipped with a trace that shows a long execution and
data read and writes history, even if the target HCS12 goes into
never_land, (like it sounds it may be doing from your description). With a
full emulator, you can simply stop the trace (even if the HCS12 would not
respond) and look at the execution history to find out what led to this
condition.

Hope this helps,
Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 12:31 25/06/2004 +0100, you wrote:
>Hi, > >From time to time my P&E BDM debugger with Cosmic Zap will not properly
> stop my target running, and I get a dialog box "can't abort target". I
> have got one particular instance where consistently I can't step one more
> step without the debugger loosing control, and stop then does not work.
> There a lots of has lots of interrupts including !XIRQ running, even so
> usually when I press Stop Zap displays a sensible portion of code. There
> seems to be plenty of stack space, and I have also turned the COP on to
> see if the target is locked up in a loop, but the COP does not fire, so
> that's probably not the problem.
>
>I understand "synchronisation lost", so back to the question how does the
>dialog box "can't abort target" come about? And how can I mitigate it?
>
>There is a follow on question also:-
>
>In my start-up code crsti.s I route:- reset vector __stext and others
>__trap_isr, _clockmonitor_isr, __cop_isr all change flag bits in a bss
>byte then jump to WarmStart. In theory I should be able look at that byte
>in .bss called _SystemFlags and identify the cause of reintialisation.
>Unfortunately I have misunderstood something about the initialisation of
>C, because _SystemFlags is always zero. WarmStart is the initialisation
>before calling f_main.
>
>Here is an excerpt of: crsti.s. you will see that I have added bgnd
>instructions, but Zap similarly never catches those, even if I don't use
>the pll, because BDM synchronisation is always lost at the time COP occurred.
>
>__trap_isr:
> bgnd // for debugger
> bset _SystemFlags, #SystemFlag_TrapWarmStart; // set the warmstart flag
> AL 02-03-04
> bra WarmStart
>
>__clockmonitor_isr:
> bgnd // for debugger
> brclr CRGFLG, #LOCKIF, NotPllLockFail
> bset CRGFLG, #LOCKIF
> bset _SystemFlags, #SystemFlag_PllLockWarmStart
>NotPllLockFail:
> brclr CRGFLG, #SCMIF, WarmStart
> bset CRGFLG, #SCMIF
> bset _SystemFlags, #SystemFlag_SelfClkWarmStart
> bra WarmStart
>
>__cop_isr: //Warm Start AL 02-03-04
> bgnd // for debugger
> bset _SystemFlags, #SystemFlag_CopWarmStart; // set the warmstart flag
> AL 02-03-04
> bra WarmStart
>
>__stext: ; Normal Reset call (Cosmic)
> clr _SystemFlags // flags AL 02-03-04
>
>WarmStart:
>// normal initialisation here. >
>
>Andrew Lohmann AIIE
>Design Engineer
>
>PLEASE NOTE NEW EMAIL ADDRESS IS: >Bellingham + Stanley Ltd.
>Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
>Tel: +44 (0) 1892 500400
>Fax: +44 (0) 1892 543115
>Website: www.bs-ltd.com >
>--------------------To learn more
>about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>o learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>
>Yahoo! Groups Links >
>





I've had that same problem with ZAP, and it isn't a code problem. I never
figured out what caused it, and the only cure seemed to be to cycle power
and start over. After a coffee break, of course, especially after the
fourth or fifth time.

Gary Olmstead
Toucan Technology
Ventura CA At 08:41 AM 6/25/04, you wrote:

>If this is a code problem, it sounds like this type of problem can be easy
>to find with a full-emulator.


A somewhat related issue --

My experience is that P&E BDM-USB with Cosmic-ZAP (on Windows-XP with a
modern PC) is bothersomely unstable. Frequent "Synchronization Lost"
situations, etc. Seems to often be induced by me moving in my chair
(static?).

Anyone with similar experiences? 607-656-2597 -----Original Message-----
From: Andrew Lohmann's New Email Server
[mailto:]
Sent: Friday, June 25, 2004 7:31 AM
To: 68HC12 yahoogroups.com
Subject: [68HC12] COP & Zap "can't abort target". Hi, From time to time my P&E BDM debugger with Cosmic Zap will not properly stop
my target running, and I get a dialog box "can't abort target". I have got
one particular instance where consistently I can't step one more step
without the debugger loosing control, and stop then does not work. There a
lots of has lots of interrupts including !XIRQ running, even so usually when
I press Stop Zap displays a sensible portion of code. There seems to be
plenty of stack space, and I have also turned the COP on to see if the
target is locked up in a loop, but the COP does not fire, so that's probably
not the problem.

I understand "synchronisation lost", so back to the question how does the
dialog box "can't abort target" come about? And how can I mitigate it?

There is a follow on question also:-

In my start-up code crsti.s I route:- reset vector __stext and others
__trap_isr, _clockmonitor_isr, __cop_isr all change flag bits in a bss byte
then jump to WarmStart. In theory I should be able look at that byte in
.bss called _SystemFlags and identify the cause of reintialisation.
Unfortunately I have misunderstood something about the initialisation of C,
because _SystemFlags is always zero. WarmStart is the initialisation before
calling f_main.

Here is an excerpt of: crsti.s. you will see that I have added bgnd
instructions, but Zap similarly never catches those, even if I don't use the
pll, because BDM synchronisation is always lost at the time COP occurred.

__trap_isr:
bgnd // for debugger
bset _SystemFlags, #SystemFlag_TrapWarmStart; // set the warmstart flag AL
02-03-04
bra WarmStart

__clockmonitor_isr:
bgnd // for debugger
brclr CRGFLG, #LOCKIF, NotPllLockFail
bset CRGFLG, #LOCKIF
bset _SystemFlags, #SystemFlag_PllLockWarmStart
NotPllLockFail:
brclr CRGFLG, #SCMIF, WarmStart
bset CRGFLG, #SCMIF
bset _SystemFlags, #SystemFlag_SelfClkWarmStart
bra WarmStart

__cop_isr: //Warm Start AL 02-03-04
bgnd // for debugger
bset _SystemFlags, #SystemFlag_CopWarmStart; // set the warmstart flag AL
02-03-04
bra WarmStart

__stext: ; Normal Reset call (Cosmic)
clr _SystemFlags // flags AL 02-03-04

WarmStart:
// normal initialisation here.

Andrew Lohmann AIIE
Design Engineer

PLEASE NOTE NEW EMAIL ADDRESS IS: Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com
--------------------To learn more about
Motorola Microcontrollers, please visit
http://www.motorola.com/mcu
o learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu

Yahoo! Groups Links



If you are running Microsoft XP with a parallel port cable, then you
might need to run a utility from P&E's web site to stop XP from polling
and changing the parallel port.

Regards
Dave Kellogg Dave wrote:

>A somewhat related issue --
>
>My experience is that P&E BDM-USB with Cosmic-ZAP (on Windows-XP with a
>modern PC) is bothersomely unstable. Frequent "Synchronization Lost"
>situations, etc. Seems to often be induced by me moving in my chair
>(static?).
>
>Anyone with similar experiences? >607-656-2597 >-----Original Message-----
>From: Andrew Lohmann's New Email Server
>[mailto:]
>Sent: Friday, June 25, 2004 7:31 AM
>To: 68HC12 yahoogroups.com
>Subject: [68HC12] COP & Zap "can't abort target". >Hi, >>From time to time my P&E BDM debugger with Cosmic Zap will not properly stop
>my target running, and I get a dialog box "can't abort target". I have got
>one particular instance where consistently I can't step one more step
>without the debugger loosing control, and stop then does not work. There a
>lots of has lots of interrupts including !XIRQ running, even so usually when
>I press Stop Zap displays a sensible portion of code. There seems to be
>plenty of stack space, and I have also turned the COP on to see if the
>target is locked up in a loop, but the COP does not fire, so that's probably
>not the problem.
>
>I understand "synchronisation lost", so back to the question how does the
>dialog box "can't abort target" come about? And how can I mitigate it?
>
>There is a follow on question also:-
>
>In my start-up code crsti.s I route:- reset vector __stext and others
>__trap_isr, _clockmonitor_isr, __cop_isr all change flag bits in a bss byte
>then jump to WarmStart. In theory I should be able look at that byte in
>.bss called _SystemFlags and identify the cause of reintialisation.
>Unfortunately I have misunderstood something about the initialisation of C,
>because _SystemFlags is always zero. WarmStart is the initialisation before
>calling f_main.
>
>Here is an excerpt of: crsti.s. you will see that I have added bgnd
>instructions, but Zap similarly never catches those, even if I don't use the
>pll, because BDM synchronisation is always lost at the time COP occurred.
>
>__trap_isr:
> bgnd // for debugger
> bset _SystemFlags, #SystemFlag_TrapWarmStart; // set the warmstart flag AL
>02-03-04
> bra WarmStart
>
>__clockmonitor_isr:
> bgnd // for debugger
> brclr CRGFLG, #LOCKIF, NotPllLockFail
> bset CRGFLG, #LOCKIF
> bset _SystemFlags, #SystemFlag_PllLockWarmStart
>NotPllLockFail:
> brclr CRGFLG, #SCMIF, WarmStart
> bset CRGFLG, #SCMIF
> bset _SystemFlags, #SystemFlag_SelfClkWarmStart
> bra WarmStart
>
>__cop_isr: //Warm Start AL 02-03-04
> bgnd // for debugger
> bset _SystemFlags, #SystemFlag_CopWarmStart; // set the warmstart flag AL
>02-03-04
> bra WarmStart
>
>__stext: ; Normal Reset call (Cosmic)
> clr _SystemFlags // flags AL 02-03-04
>
>WarmStart:
>// normal initialisation here. >
>
>Andrew Lohmann AIIE
>Design Engineer
>
>PLEASE NOTE NEW EMAIL ADDRESS IS: >Bellingham + Stanley Ltd.
>Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
>Tel: +44 (0) 1892 500400
>Fax: +44 (0) 1892 543115
>Website: www.bs-ltd.com >
>--------------------To learn more about
>Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>o learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>
>Yahoo! Groups Links >
>
>--------------------To learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>o learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>
>Yahoo! Groups Links




Thanks for your replies. > I've had that same problem with ZAP, and it isn't a code problem. I never
figured out what caused it, and the only cure seemed to be to cycle power
and start over. After a coffee break, of course, especially after the
fourth or fifth time.

Gary is generally correct, but in this particular case it happens if I set a breakpoint just before the point it is going to happen then single step a few lines, and hey presto it won't stop and so when I press STOP I'm back to "can't abort target". Incidentally use the Connect on Zap, there is no need to power off, drink coffee, or close Zap, unless you want to. I have interspersed some more comments with other replies below. - Again thanks Andrew

> If you are running Microsoft XP with a parallel port cable, then you
might need to run a utility from P&E's web site to stop XP from polling
and changing the parallel port.

That patch makes the Parrallel and USB Multilink BDM's as stable as each other. I had also thought BDM on NT4 was incredibly stable until I discovered there was a hardware reset issue on my target forced the colpits ocilator to run if at all in a peirce mode I guess. I now don't have any external hardware reset on my MC9S12E128 target because theirs a reliable one on chip. >A somewhat related issue --
>
>My experience is that P&E BDM-USB with Cosmic-ZAP (on Windows-XP with a
>modern PC) is bothersomely unstable. Frequent "Synchronization Lost"
>situations, etc. Seems to often be induced by me moving in my chair
>(static?).
>
>Anyone with similar experiences?
My first target with Colpits oscillator was very good, but my second target with a larger area on no ground plane under neath is better. In that second board there is one ground plane via for the pll and crystal and a track from it to the crystal case pads. This second target can run from minutes to hours before "Synchronization Lost" usually hours if at all, but I find if I stop the target depending on how long it has been running I am more likely to see "can't abort target".

> Full emulator

I am sure that would help - a short term hire would be handy, I have asked for the money to buy one and the answer is no. It would be inconvenient to wire it in. - Such a shame S12 BDM is not like HC16 BDM, that is as good as an emulator. But I guess fitting a canned oscilator temporarily to my target would make the BDM reliable.

** The answer to the two for the price of one question on the Cop I guess is. Reset and cop disable my external RAM so therefor I cannot use a variable even if its in bss after either of those until I have configured external RAM access again. That is not the whole answer though in my function Reset() the variable is changed prior to a forced COP, so the changed state of that variable should be there again after COP and RAM configuration, but it is not.
>Hi, >>From time to time my P&E BDM debugger with Cosmic Zap will not properly stop
>my target running, and I get a dialog box "can't abort target". I have got
>one particular instance where consistently I can't step one more step
>without the debugger loosing control, and stop then does not work. There a
>lots of has lots of interrupts including !XIRQ running, even so usually when
>I press Stop Zap displays a sensible portion of code. There seems to be
>plenty of stack space, and I have also turned the COP on to see if the
>target is locked up in a loop, but the COP does not fire, so that's probably
>not the problem.
>
>I understand "synchronisation lost", so back to the question how does the
>dialog box "can't abort target" come about? And how can I mitigate it?
>
>There is a follow on question also:-
>
>In my start-up code crsti.s I route:- reset vector __stext and others
>__trap_isr, _clockmonitor_isr, __cop_isr all change flag bits in a bss byte
>then jump to WarmStart. In theory I should be able look at that byte in
>.bss called _SystemFlags and identify the cause of reintialisation.
>Unfortunately I have misunderstood something about the initialisation of C,
>because _SystemFlags is always zero. WarmStart is the initialisation before
>calling f_main.
>
>Here is an excerpt of: crsti.s. you will see that I have added bgnd
>instructions, but Zap similarly never catches those, even if I don't use the
>pll, because BDM synchronisation is always lost at the time COP occurred.
>
>__trap_isr:
> bgnd // for debugger
> bset _SystemFlags, #SystemFlag_TrapWarmStart; // set the warmstart flag AL
>02-03-04
> bra WarmStart
>
>__clockmonitor_isr:
> bgnd // for debugger
> brclr CRGFLG, #LOCKIF, NotPllLockFail
> bset CRGFLG, #LOCKIF
> bset _SystemFlags, #SystemFlag_PllLockWarmStart
>NotPllLockFail:
> brclr CRGFLG, #SCMIF, WarmStart
> bset CRGFLG, #SCMIF
> bset _SystemFlags, #SystemFlag_SelfClkWarmStart
> bra WarmStart
>
>__cop_isr: //Warm Start AL 02-03-04
> bgnd // for debugger
> bset _SystemFlags, #SystemFlag_CopWarmStart; // set the warmstart flag AL
>02-03-04
> bra WarmStart
>
>__stext: ; Normal Reset call (Cosmic)
> clr _SystemFlags // flags AL 02-03-04
>
>WarmStart:
>// normal initialisation here. >
>
>Andrew Lohmann AIIE
>Design Engineer
>
>PLEASE NOTE NEW EMAIL ADDRESS IS: >Bellingham + Stanley Ltd.
>Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
>Tel: +44 (0) 1892 500400
>Fax: +44 (0) 1892 543115
>Website: www.bs-ltd.com
>



I have discovered some significant points:-

1) NT4 is better behaved than XP Pro.
2) BDM is better with Pierce oscillator.
3) "wai" Instruction throws the BDM, and may be the primary cause of "can't abort target".

At the present time I am running XP Pro, and find both the USB or parallel P&E BDM interfaces less stable even with the P&E Patch than when run on NT4. I have also had problems with the mouse with XP Pro. My target was previously more stable when running on NT4 and I never normal came across "can't abort target" or "scynchonisation lost" in the month prior to switching to XP Pro.

In order to reproduce somewhat what I had with NT4 I have obtained an evaluation licence from Cosmic C for an old PC running NT4. In addition I've got my target modified to use the pierce oscillator configuration, which is how I may have been running the target inadvertently then. I also modified my code by taking out "wai" instructions, and the found the target to be stable.

Reverting to my new PC with XP Pro I find that debugging is also more stable with "wai" removed. So my guess is that freescale could improve the BDM by making the RSBCK bit in Crg.copctl.byte also inhibit something when operating in BDM active mode. In other words it is partly code dependant, and I suspect that it is the repeated uses of "wai" that throws the BDM more surverally. Andrew Lohmann AIIE
Design Engineer

>
>>From time to time my P&E BDM debugger with Cosmic Zap will not properly stop
>my target running, and I get a dialog box "can't abort target". I have got
>one particular instance where consistently I can't step one more step
>without the debugger loosing control, and stop then does not work. There a
>lots of has lots of interrupts including !XIRQ running, even so usually when
>I press Stop Zap displays a sensible portion of code. There seems to be
>plenty of stack space, and I have also turned the COP on to see if the
>target is locked up in a loop, but the COP does not fire, so that's probably
>not the problem.
>
>I understand "synchronisation lost", so back to the question how does the
>dialog box "can't abort target" come about? And how can I mitigate it?
>





--- In , "Andrew Lohmann's New Email Server" <andrew.lohmann@b...> wrote:

Hi Andrew,

> I have discovered some significant points:-
> 2) BDM is better with Pierce oscillator.

At what frequence does the oscilator run and do you use the PLL?

Just curious, I have had a few startup failures of my 16MHz Colpits, the Xtal needs replacing for some reason.

Cheers,

Theo


Theo and all,

RE:-
> At what frequency does the oscillator run and do you use the PLL?
> Just curious, I have had a few startup failures of my 16MHz Colpits, the Xtal needs replacing for some reason.

My Colpits oscillator crystal is ~3.6MHz and the pll boosts E-Bus to ~16MHz in my target. Cold start is reliable, in Colpits mode (!XCLKS pin floating high) but I think the oscillator needs a resistor across the crystal in pierce mode (!XCLKS pin pulled low) to make it start. You should all so be aware that Motorola mixes high and low for the !XCLKS pin without taking account of the pin inversion - I got it wrong in my first target which made start up difficult. The spec for the Colpits oscillator on MC9S12E128 is 1 to 5MHz can I guess that when you say 16MHz you are referring to e-bus after pll multiplication?

In my own case the Coplits oscillator is stable with the BDM, the problem was using "wai" instruction. It's a shame that BDM can't track code after the COP has fired, but that problem is fairly trivial to work around. Andrew




The Colpitts oscillator is specified in the spec. to work up to 16MHz
frequency (not 5MHz as you write). Regardless of the spec, it is a good
idea to operate the Colpitts oscillator at frequencies up to 8MHz only,
since the Colpitts oscillator is more stable at the lower frequencies.

The 1 to 5 MHz spec. that you quote is for the self-clock mode - the bus
frequency that will be generated by the HCS12 internally when it detects no
valid external crystal or clock frequency on the EXTAL pin. By the way,
operation in self-clock mode is not possible with BDM either.

All these operating conditions that you mention (COP Watchdog Reset &
External Reset, STOP and WAIT Power-Down Modes, Self-Clock Mode, and
unlimited speed changes), can only be supported using a full HCS12
emulator, and cannot be supported by BDMs.

Hope this helps,
Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 09:04 01/07/2004 +0100, you wrote:
>Theo and all,
>
>RE:-
> > At what frequency does the oscillator run and do you use the PLL?
> > Just curious, I have had a few startup failures of my 16MHz Colpits,
> the Xtal needs replacing for some reason.
>
>My Colpits oscillator crystal is ~3.6MHz and the pll boosts E-Bus to
>~16MHz in my target. Cold start is reliable, in Colpits mode (!XCLKS pin
>floating high) but I think the oscillator needs a resistor across the
>crystal in pierce mode (!XCLKS pin pulled low) to make it start. You
>should all so be aware that Motorola mixes high and low for the !XCLKS pin
>without taking account of the pin inversion - I got it wrong in my first
>target which made start up difficult. The spec for the Colpits oscillator
>on MC9S12E128 is 1 to 5MHz can I guess that when you say 16MHz you are
>referring to e-bus after pll multiplication?
>
>In my own case the Coplits oscillator is stable with the BDM, the problem
>was using "wai" instruction. It's a shame that BDM can't track code after
>the COP has fired, but that problem is fairly trivial to work around. >Andrew