GENERAL: XMC4000 execution halts when the controller is reset
Information in this knowledgebase article applies to:
When testing the effect of the watchdog on the system based on a XMC4000 device, I noticed during a debug session that the program halts at the reset vector after the watchdog did perform a reset. Execution has then to be restarted manually. Why does the program execution not just continue, as it does without the debugger connected?
This behaviour does not depend on a certain debug adapter. It is actually the chip's own internal Startup Software (SSW), that under certain conditions will configure a breakpoint on the first user instruction. The chip manual describes this as the Halt After Reset (HAR) feature, which is applicable only for a Power On Reset (PORST) case.
The SSW seems to also determine the reset source via bits in the SCU_RESET->RSTSTAT register. This are sticky bits, causing the initial PORST bit to prevail a reset, like one triggered by the watchdog. As also the SSW sees the PORST again, it obviously handles HAR as well, which results in the breakpioint at the reset vector of the application.
After the user program has handled the the reset sources itself, it needs to clear them by executing:
SCU_RESET->RSTCLR = SCU_RESET_RSTCLR_RSCLR_Msk ;
before the next reset. This will clear also the PORST bit. And if the next reset is no Power On Reset, the SSW will also not do HAR.
Last Reviewed: Wednesday, August 14, 2019
of your data.