We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
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.