Hi,
I am using LPC2368. It has pretty complex code running with 1 Timer interrupt (100uS continuous) , 2 UART interrupts, 1 SPI Interrupt, 1 USB interrupt and main loop.
Watchdog timer is of 5 sec and is feed in main loop and in different places.
System works well till 2 hrs.
After 2-3 hrs (undefined interval) there is sudden watchdog reset and system goes in error (handled in my code.)
In errata sheet of LPC2368 following is written
Introduction:
The Watchdog timer can reset the microcontroller within a reasonable amount of time if it
enters an erroneous state.
Problem:
After writing 0xAA to WDFEED, any APB register access other than writing 0x55 to
WDFEED may cause an immediate reset.
Work-around:
Avoid APB accesses in the middle of the feedsequence. This implies that interrupts and
the GPDMA should be disabled while feeding the Watchdog.
What is the cause of WDT reset??? that too after 2-3 hrs??
How to find at which point in code WDT reset occures?? I don't have any debugger.
Thanks
Hemant Undale
Hello Hemant,
I am afraid this is really NXP's expertise needed rather than ARM.
For this, I would advise the dedicated forums: lpc2000 | www.LPCware.com
If you are sure it is indeed a watchdog reset, maybe you could look at your time spent in interrupt subroutines.
With different modules talking and asking for interrupts, maybe you keep re-entering ISR without kicking that dog for a while.
Thanks Alban,
I have posted this question on LPC forum as well (as per your advice.)
You have pointed out one case that "you keep re-entering ISR without kicking that dog for a while"
If I assume that this is happening then how should i come out of this situation, any workaround? Do I need to feed the dog in ISR?? Is it a good practice?
Also
I have some strange observation that when my system is handling error state (after watch dog reset), it jumps to a location in bootloader (that we have written) and hangs there.
Hemant Undale.
If your code keeps re-entering the different ISR without progressing the main, it could mean two things:
a- either your interrupts are too long
b- you receive so many interrupts that your MCU cannot cope at its current speed. Increasing the execution speed could be one way to find out.
Another second way to find out would be for you to calculate the CPU load. From the communication speed, you can determine the interrupt rate for your SPI and UARTs. Multiplying by the length of the ISR (clock cycles) will tell you how much headroom you have left. Predicting the USB may be a bit more difficult. I have to say USB is not my expertise (or cup of tea).
A third way to find out would be to disable the modules generating most interrupts load (depends on your application). If your software doesn't hang anymore, that would give a clue.
I believe that feeding the dog in the interrupt is not a good practice. If, for a reason or another, you start to have "code runaway", you would still have interrupts happening due to your serial transmissions and you would feed the dog whilst your main is not executing anymore. That is why I have not fed the dog in my ISR.
Also, ISR are supposed to be very short, so they should not need it.
I am not familiar with the microcontroller, so I am not sure on how much a watchdog reset is different from a reset pin reset.
It could be possible that the reset is not as clean as a pin reset in order to help debugging the watchdog reset reason. If that is the case, you may either start from an unknown state or have some values in memory leading the execution to your bootloader. Tracing the execution should help here.
I am not sure you will find these generic elements useful... Tell me if you do/don't.