Backup watchdog freezes - M52259 ColdFire V2

[samalo0]

Hello everyone,

I have a project in which I use a watchdog both in the bootloader and in the main code. Once I leave the bootloader, the watchdog doesn't cause the system to reset properly, but instead causes a hard lockup.

I believe the problem is that the backup watchdog doesn't do a hard reset, but instead perhaps jumps to a reset vector or something like that to do a 'warm reboot'.

Does anyone know the exact procedure that occurs? This way I can look in the memory and perhaps determine why I get a hard lock; it really seems as though it is jumping somewhere unexpected.

My bootloader code has the vector table at 0x0; the main code at 0x8000, and the interrupt vectors are copied by MQX into RAM @ 0x20000000. So my reset vector while in the bootloader is 0x4, and while in the main code is 0x20000004 (copied from 0x8004).

Thanks,

Steve

[scifi]

According to the manual, the backup watchdog timer is still enabled after the warm reset. So if you don't service it properly after the reset, you'll enter the endless reset loop.

[samalo0]

Yes. But the problem is not that I reboot endlessly, which would be nice. The problem is that the backup watchdog causes the system to FREEZE once I leave the bootloader.

[mjbcswitzerland]

Steve

The core watchdog timer uses an interrupt vector, while the backup watch timer generates a warm reset. The backup watchdog timer can also not be disabled once started, also not through a warm reset (only after a power up reset).

I have used both watchdods in conjunction with boot loaders and haven't experienced any problems (that is, no incorrect behaviour of the backup watchdog) so don't believe that it can cause such an effect as a freeze of the system. Therefore  I would consider the following:

1) if you continue to retrigger the background watchdog when leaving the boot loader it shouldn't cause a reset and so shouldn't be able to influence.

2) If the background watchdog is firing when you leave the boot loader (this could be several seconds later, depending on the timeout value set) it should start the boot loader again. Is it possible that the boot loader has a difficulty starting in this situation? The reset vector part should be identical, but is there something afterwards that causes the problem (RAM  content, reset register content)?

Regards

Mark

[samalo0]

Thanks mjbcswitzerland.

Yes, I have use the watchdog and tested it to correctly reset the system in the bootloader, and also it works if I just load my MQX project without the bootloader at the base address.

But once I leave the base address that is when it freezes.

So I do believe that it is something that is set incorrectly when the backwatchdog kicks, which is why I would really like someone to tell me exactly what happens when it does. I mean, does it cause the PC to jump to 0x4, the reset vector? (This is obviously not the case since that would cause the code to reboot).

I feed the watchdog immediately in both the bootloader and the main code, and in any event, if i did that incorrectly as you mentioned it should reboot over and over.

Here is a response I got from Freescale:

Dear Stephen Maloney, In reply to your message regarding Service Request SR 1-734970054:Actually you are right. They are “write once” registers. You will have to implement the bootloader in a way that bootloader mode is conditioned to something (i.e. a push button, jumper, etc.). Let’s describe an example:Your board starts. In the interrupt vector you decide if you have to enter or not to the bootloader mode (any condition as previous examples). If yes then you enter to bootloader and do what you need to do (for example, flash with new S19). What dog is used and so on. When the bootloader finished its job it calls software reset to the MCU. This time the enter bootloader condition is not asserted and you will enter to your MQX application. No watchdog is activated and the MQX application runs normally. This is the way we recommend to implement the bootloaders. The preference is to have the MCU starting the application in an after reset state. That way we ensure that all the registers return to the original state.This would be the only way to fix this. The other option is to disable the watchdog in your bootloader. The problem is that this will put in risk the recovery capacity in your application.I hope this helps. Please let me know if you have more doubts. Have a nice weekend.Should you need to contact us with regard to this message, please see the notes below. Best Regards,[Service Request.Owner Fst Name] Technical Information & Commercial Support Freescale Semiconductor---------------------------------------------------------------------This message is in reply to Activity ID: 1-C5ZV80 Comment: I see, that makes sense. The one problem I have is that you cannot disable the backup watchdog once you have enabled it, at least in any way that I can find. The registers are write once.Is there a way to go into a 'supervisor' mode to be able to write them more than once?Thanks,SteveOn 4/8/2011 12:46 PM, Freescale Support wrote:

> Dear Stephen Maloney,>> In reply to your message regarding Service Request SR 1-734970054:>> Now it is clearer to me. What it is happening is that MQX is losing itself in an indeterminate state. The problem is that you cannot use the microcontroller watchdog timer. The MCU has some internal timeouts that may cause the watchdog to restart the MCU. Also the scheduler/kernel gets into some infinite loops needed to wait the initialize of some tasks in the system. MQX is implementing the watchdog timer component. This watchdog is by task. Each task can has its own watchdog timer. You can get more information about this watchdog timer take a look to the section 3.9.6 Watchdogs from the C:\Program Files\Freescale\Freescale MQX 3.6\doc\mqx\MQXUG.pdf document. There are also examples of who to use this watchdog component. C:\Program Files\Freescale\Freescale MQX 3.6\mqx\examples\watchdog>> My suggestion is to disable the watchdog once you enter to MQX application and instead use the Watchdog component. With this you are covering your bootloader and also the MQX application.>> Please let me know if you still have probl...