9S08GB32: Odd BDM-related behavior

[BlkStang]

Been struggling with this for a while now and am at my wits end:

My system uses a 9S08GB32. It normally runs from external power but has a constant battery power backup to allow certain functionality when external power is absent. If the logic sees that the external power is gone it shuts the micro down and executes a STOP instruction, putting the micro to sleep. Normally this is fine; in sleep mode the micro draw roughly 4.8uA and can be woken normally by asserting IRQ low either as a result of external power being connected or a user switch being pressed. Note that the RESET pin in our design is pulled to Vdd with a pull-up resistor and is not driven by an external device: wakeup from sleep is done by pulling the IRQ pin low. PTG0/BKGD/MS is connected to the debug port pin only with no external pull resistors.

The problem occurs after a specific series of operations involving the BDM. I'm using P&Es USB-ML-12 pod. When I want to program the device in circuit, I'll connect the pod, start the debugger and go through the normal programming sequence successfully. If I reset the target (ctrl-R) and start (F5), the processor seems to run properly. If I halt the target (F6) to check some memory, reset and start, everything seems normal. I/O pins configured as test points show the uC is operating as expected. So far so good. At this point, I'm finished with the BDM so I unplug the cable from the target with it still running and everything still looks good.

Here's the tricky part: If I then cycle external power to the system (part of the overall system reset sequence), the micro "goes away" when power is restored. It doesn't even appear to boot since test points placed at the start of the code show no activity. It's almost as if the uC is still in STOP mode (although a high current consumption does not jive with this) and that it did not respond to the IRQ pin being taken low . Seems like the only way to recover from this is to assert the RESET pin.

I've tried this leaving the debugger connected: Hit F5 to start it and then power-cycle. The debugger window seems to indicate the micro is still running (the F5/Start button is greyed out) but the micro is outwardly dead again. If I stop the debugger with F6, the Register window shows the PC sitting at hte instruction immediately following the STOP instruction. Again, it's as if the micro is simply not waking up.

What am I seeing here? Is there something about the background debug I'm missing? And can this "condition" be entered without the debugger connected (this is the real problem I'm trying to address: the micro will sometimes seem to get into a very similar condition even though a debugger hasn't been anywhere near it...)

[JimDon]

First of all, you should determine if it does get into this state with no debugger. Blink a LED, pulse a GPIO, what ever.

For one thing, when you enter full stop mode, and it is drawing low power the BDM is completely disabled (or you would not be drawing low power), so you may not be able to reconnect until a full reset. The debugger has really no way of knowing this, so it will not indicate this - it will appear to be "confused".

I have seen this before, when after using the BDM it required a full reset to resume normal operation, so it is important that you determine none of this is actually happening when not using the BDM. When you remove the power, you are not resetting, so the BDM module could be left in an indeterminate state.

I always considered it routine to do a hard reset before expecting 100% normal operation after using the BDM.

[BlkStang]

---

JimDon wrote:

First of all, you should determine if it does get into this state with no debugger. Blink a LED, pulse a GPIO, what ever.

For one thing, when you enter full stop mode, and it is drawing low power the BDM is completely disabled (or you would not be drawing low power), so you may not be able to reconnect until a full reset. The debugger has really no way of knowing this, so it will not indicate this - it will appear to be "confused".

I have seen this before, when after using the BDM it required a full reset to resume normal operation, so it is important that you determine none of this is actually happening when not using the BDM. When you remove the power, you are not resetting, so the BDM module could be left in an indeterminate state.

I always considered it routine to do a hard reset before expecting 100% normal operation after using the BDM.

---

Hi. As I noted in the above post, the micro seems to be able to get into a state that outwardly appears to be the same as the topic of this thread without any BDM hardware attached. It's rare though and repeating it has been tricky for us. We've only had 3 or 4 micros display this behavior out of many hundreds, 3 of them at customer sites. Many hours of testing haven't yet produced the problem though the 4th of the 4 I mentioned happened here quite by accident: A coworker came to me and said "this one's got something wrong" and it appeared the micro was in that state. She was doing nothing unusual at the time it got "stuck."

Thought: When I select "go" in the debugger I assume the multilink is sending a GO command to the micro. While I (mistakenly?) think that the micro is not in BDM mode anymore, if I were to read the BDMSCR I would actually find that the BDMACT bit is set because the BDC is still in active BDM mode. So even though I've been thinking up to this point that selecting issuing a GO leaves the micro in a state where it's safe to disconnect the BDM cable, in fact it's not. When the micro executes the stop instruction, it's hosed at that point because BDMACT is still active but the BDC is inactive in stop mode.

Could this combination of events lead to an indeterminant state that might cause unexpected behavior?

[CompilerGuru]

Is the application normally running fine with no debugger ?
Or does it only run with the debugger attached?

The "it does not start without debugger attached" topic has been discussed quite a few times in the past.
The usual suspects are:
COP - (does you code run with COP disabled as first thing (in _Startup)?)
write once register - in special mode, they can be written more then once...
missing initialization (although I don't think by default anything is initialized by the debugger for a S08)

Daniel
http://forums.freescale.com/message?board.id=8BITCOMM&message.id=11271" rel="nofollow" target="_blan...

[BlkStang]

---

CompilerGuru wrote:
Is the application normally running fine with no debugger ?
Or does it only run with the debugger attached?

The "it does not start without debugger attached" topic has been discussed quite a few times in the past.
The usual suspects are:
COP - (does you code run with COP disabled as first thing (in _Startup)?)
write once register - in special mode, they can be written more then once...
missing initialization (although I don't think by default anything is initialized by the debugger for a S08)

Daniel
http://forums.freescale.com/message?board.id=8BITCOMM&message.id=11271" rel="nofollow" target="_blan...

---

Thanks for the reply. There's two issues here that may or may not be related. The issue that's the topic of this thread of course but the primary, critical problem I've been working on tracking down is that the micro may exhibit this behavior -- unresponsive, almost like it's not running code at all -- when at customer sites. When we get the unit back here for FA we find the micro is drawing power from the battery at a rate that's less than 50% of its normal current draw but does not appear to be actually doing anything. In my start up code, I've got one potential trap:

Code:

void InitializeMachine( void ){    //safe system IOs first    InitIOs();            //system options, clock generation    SOPT = initSOPT;    ICGC2 = initICGC2;    ICGC1 = initICGC1;    while( !ICGS1_LOCK )    {                                //DEBUG        prtG_TP_PIN62 ^= 1;                __RESET_WATCHDOG(); //reset COP while waiting on FLL lock                    }//while    ...

where, if the FLL fails to lock, the micro could get stuck here forever. So far I don't see any indication that this is the case though. There are no other such occurences of while loops where the COP is reset in this way.

The only way to recover these customer units seems to be to disconnect power (or have the battery die). While I cannot be sure it's not stuck in a "buzz loop", the current draw, at 6.9mA or so, doesn't match the draw of a micro whose ICG is not initialized further than self-clocked mode. The behavior of the micro in this condition is very much like when the BDC has the thing in active BDM, as if the user code isn't even running.

When I saw that I was able to induce very similar behavior by simply holding BKGD low during a reset -- ending up with a non-responsive micro that wouldn't even talk to a P&E USB multilink, I got suspicious that perhaps the micro is somehow ending up in a similar condition either through something I'm doing in my code or perhaps by bad power or levels on BKGD or other pins during power-on and -off transitions.

The problem is very rare. We have not yet intentionally induced it by doing normal things people might do with the product although maddeningly, they seem to have been able to get it to happen a couple of times now...

I have one unit in that state on my workbench and am attempting to find a way to see if I can see if the BDC is alive and read the BDCSCR to determine if the BDMACT bit is set indicating BDM mode is active. That would tell me alot.

So far I haven't been able to find a way to read this status non-intrusively via the Codewarrior IDE so I'm left with two options: attempt to craft up my own BDM interface (1/2 done) or see if there's a low-level API available for the P&E USB multilink that would allow me to ask it to do a SYNC and a READ_STATUS without disturbing the state of the micro by asserting reset.

You say that there have been previous discussions of the "it does not start without debugger attached" topic which sounds like it might be interesting: Do you have any links to these discussions?