MCF51JM128 Watchdog Doesn't Reset

[kenricsmith]

I have a MCF51JM128 and it seems to work fine except that the watchdog reset doesn't do the same thing as an external reset.   I have been having issues debugging it since the watchdog doesn't go off if I step through the code.  I just have a while(1) with a nop, and the code is triggered to go there via a USB command.  I have gotten around it for now by jumping to the start vector, but it concerns me that my watchdog isn't ever going to work.  Anyone know what might be wrong?

[pawelszramowski · Accepted solution]

My setup is MCF51JM128 on a custom board, P&E USB Multilink Universal, and CW for MCU 10.2. I use debug/run configurations with default debugger settings.

When I have the debugger connected and COP watchdog times out, then execution stops and an exception handler (I'd have to check for which vector) is executed continuously.

If I then disconnect the debugger, reset the MCU with an external reset button and wait for an another COP timeout, then I can see that MCU gets reset but it doesn't restart program execution.

I recently spent a very indecent amount of time debugging this, until I discovered that once the power is cycled program execution is restarted normally after COP timeout. The conclusion was that even if the debugger is disconnected from the target in CodeWarrior before disconnecting it physically from the target, it still leaves MCU's debug controller active and waiting for debug commands, thus preventing the core from starting program execution after reset.

I think that you may be experiencing the same "problem". If you have an LED connected to your MCU's GPIO then just turn it on before jumping to the infinite loop. It should turn off after COP timeout when all the peripherals get reset. Reset pin is also pulsed low so you can check it with a 'scope.

If you only want to check whether the COP is working, then load the program through the debugger, disconnect it, cycle target's power and then have the MCU jump to the infinite loop.

If you want to force a hardware reset, then I think that writing an invalid value (e.g. 0) to SRS is the best option. It causes the MCU to reset immediately, you don't have to wait up to a second for a COP timeout.

If that is not it, then maybe a bug in your code disables COP. You can lock COP setting by writing its control bits in SOPT1 and SOPT2.

[kenricsmith]

Marked as answered.  The key is this:

The conclusion was that even if the debugger is disconnected from the target in CodeWarrior before disconnecting it physically from the target, it still leaves MCU's debug controller active and waiting for debug commands, thus preventing the core from starting program execution after reset.

I was not power cycling it after disconnecting the debugger.   After a power cycle, it appears to operate as expected.

Thanks for the help.

[TomE]

> the watchdog doesn't go off if I step through the code.

It would be rather hard to debug the rest of your code if the watchdog kept resetting it during single step.

Other (more complicated) micros like the MCF5329 have bits in the watchdog control register that let you specify whether you want the watchdog to keep running during Wait, Doze and Halted/Debug modes. I use that in my code so that the boot detects if it is running from the debugger (detects that it has been loaded into RAM rather than starting in FLASH) and disables the watchdog in HALT/DEBUG in that case only.

This whip and its watchdog is a bit simpler:

This may explain what you're seeing:

5.3.1 Computer Operating Properly (COP) Watchdog
If the bus clock source is selected, the COP counter does not increment
while the microcontroller is in background debug mode or while the
system is in stop mode. The COP counter resumes when the
microcontroller exits background debug mode or stop mode.

That implies that it should trigger if you start the code running again under the debugger.

There's another problem though. Having the chip throw a reset while you've got the debugger connected is tricky. Do you expect the debugger to "regain control" of the micro and let it run, regain control and stop it or do you expect the CPU to run "out of control" or just lock up? I can't find in a quick read of the manual what is meant to happen here, but I suspect this operation is "unsupported". The only real way to get the debugger running is to have it reset the micro and force entry into debug mode.

On my MCF5329 if I'm running with the debugger connected and the CPU resets (after a software load or through a separate diagnostic interface), I've lost it and can't regain control. But I think that's expected and normal.

If you want to test the watchdog, I think you have to test it "stand-alone" and in normal operation and without the debugger.

Tom