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.
When a watchdog timeout occurs, it could be the result of many causes. The code could be 'out in space' due to a bad pointer corrupting anything it wants to. It could be due to a fault condition that did not affect data space. Who knows?
Since the watchdog reset is considered a 'hard reset' we know where it will then start execution from.
If I want to save existing data ram into flash prior to executing __main() I would think the place to do this would be here:
; Reset Handler Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT __main LDR R0, =__main BX R0 ENDP
I could jump into a routine which calls an IAP command to save RAM to flash and then return to finish the startup.
I would have to EXPORT the routine I want to jump to as well as load the LR with the return value. Is there anything else that I am missing?
BTW: the processor is a Cortex M3 core.
Thanks.
isn't it better to trigger an interrupt in case of a watchdog violation, save to non-volatile memory, and then reprogram the watchdog to actually reset the system...?
According to the users manual:
"...the intent of the watchdog interrupt is to allow debugging watchdog activity without resetting the device when the watchdog overflows."
"Watchdog reset mode: operate with the Watchdog interrupt and WDRESET enabled. When this mode is selected, a watchdog counter underflow will reset the microcontroller. Although the Watchdog interrupt is also enabled in this case (WDEN = 1) it will not be recognized since the watchdog reset will clear the WDINT flag."
"Once the WDEN and/or WDRESET bits are set they can not be cleared by software."
So the watchdog can either be set for INT or RESET, but once set thats it. It must be set for a RESET condition. Earlier tests I ran confirm this behavior.