I am looking for R/W register who's contents can survive a watchdog reset. I have cases where a watchdog is not an error, but purposely done via S/W. I need to flag these cases so that during the subsequent reboot, the S/W can handle it differently compared to an unexpected watchdog. Unfortunately, I can't use the user area flash storage...
The whole RAM is not "touched" by a watchdog reset. It is however initialized/cleared by the startup code. You can modify your linker script to artificially "shrink" the RAM:
RAM (rwx) : ORIGIN = 0x20000000 + 4, LENGTH = 131072 - 4
the 4 bytes beginning at 0x20000000 will not be touched by the startup code (nor will the compiler/linker place anything there), so you can place your flag there. Example:
uint32_t *flag = (uint32_t*)0x20000000; *flag = MY_MAGIC_123;
You may want to use a __DSB() instruction to make sure that the write actually goes in to RAM before the reset.
I am wondering which device you are working on, EFM32GG or EFM32GG11.
you can read the reset cause register to determine if it caused by watchdog.
By the way, the behavior of the reset was configurable, you could take a look at the RMU section of the reference manual.
I am using the "original" efm32gg290f1024. I read the reset cause register to determine if it was a watchdog. After this is determined, I need to know whether S/W forced the watchdog or whether it was a completely unexpected watchdog (S/W bug?). The flag would be set before S/W caused the watchdog so that on the resulting reset (from S/W watchdog) the S/W can take the appropriate action.
I will try Artur's idea of reserving ram to store the flag.
I need to know whether S/W forced the watchdog or whether it was a completely unexpected watchdog (S/W bug?).
what do you mean by "S/W forced the watchdog" here?
I am still wondering if I understand your requirement correctly or not.
My understanding is:
1. you need to determine if the debugger is connected, because you need to enter EM2, if you use the 'debug' button of Simplicity Studio to start the debug your firmware, this would not allow the EFM32GG to enter real EM2. after you call EM2 in your firmware the device in fact will not execute code any more (the device enter EM2), but some clock remain active, so the power consumption is high.
2. That's the reason you want to have a workaround. use the watchdog to reset the device.
a. the firmware determine if debugger connected , if connected, you force a watchdog reset.
b. if debugger was not connected. you configure the watchdog and feed it normally.
c. you need some RAM or register to different these 2 reset (you write value before watchdog fire in your code). the content of the RAM (or other) need unchanged after watchdog reset.
I don't encourage you implement this, but you may take a look at below KBA, see if it works (determine debugger connect) and try if you could have other options/solution to enter real EM2.