The WTCSR.IOVF bit inside the watchdog will not be initialized by POR, so with this you can distinguish between a POR and a WD reset. Also, the WDTOVF hardware signal can be output on a WD overflow event, if this is useful. This shall be sufficient to determine the reset cause, if you do not use the WD in the application besides from generating a CPU sw reset. Otherwise, a mirrored status variable for the application-triggered WD reset could be saved, for example a status flag on one RAM retention bank, and its complementary value on a different bank. On the compiler side, IAR provides an intrinsic __no_init pragma to avoid initialization of the variables by its startup routine. (alternatively, you can pass a 0 back from __low_level_init, and do the initialization of the variables yourself) GCC does not have similar, however you can place the variable yourself in any section, for example called .noinit, in this way: __attribute__ ((section (".noinit"))) (or call the section the way you want) and place the section somewhere in RAM via the linker script, for example .noinit_section : { *(.noinit) } RAM In GCC you would typically want to zero out .bss and initialize .data yourself at startup. So everything inside your ".noint" section will not be touched by your initialization routine, and retain its value.
↧