Mike Palmer

9S08GB32: Odd BDM-related behavior

Discussion created by Mike Palmer on Jul 3, 2008
Latest reply on Jul 7, 2008 by Mike Palmer
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...)

Outcomes