2020-12-05 06:17 AM
Hi, I have a project using STM32F407 micro. Every few days I get a reset on the device even though there is no interaction with the device. I have it running on the debugger with ST-Link connected and when this reset occurs I inspect the CSR register and the RCC_FLAG_PINRST flag is set but none of the other reset flags.
From the datasheets it seems that this RCC_FLAG_PINRST means that the external NRST pin has been pulled low. Is there anything else that could trigger this flag (without any others set). Can something go wrong in code that could cause this?
2020-12-06 01:17 PM
The "Getting started with STM32Fxxxx MCU hardware development" app notes recommend a 100nF C between NRST and GND to prevent spurious resets.
2020-12-07 02:43 AM
Thanks KnarfB. I do have this 100nF capacitor. So I was just wondering if there could be any hardfault or stack overrun situation that could cause this type of reset, or would the RCC_FLAG_SFTRST flag be also set in this scenario?
2020-12-07 06:28 AM
No, I don't think so. The flag is exclusively used for what it says.
HardFault ends up in a handler, you could set a breakpoint, flash a LED etc.. from there to exclude that. And/or connect NRST IO to a scope and set a trigger to catch a possible internal reset.
Stack overflow can cause anything. There are some means helping to detect this (e.g. in FreeRTOS) see also https://barrgroup.com/embedded-systems/how-to/prevent-detect-stack-overflow
In a production szenario the hard fault handler might log something and issue a software reset (RCC_FLAG_SFTRST). In addition, a watchog is running and might cause a watchdog reset (RCC_FLAG_IWDGRST, RCC_FLAG_WWDGRST,) when the prog gets stuck.
Power loss (RCC_FLAG_PORRST) or ditch (RCC_FLAG_BORRST) have their own flags too. Brown-out can be really usefull but must be enabled and is not avail in all chips.
hth
KnarfB
2020-12-07 02:48 PM
Thanks again KnarfB. Yeah, so if I get RCC_FLAG_PINRST on it's own then that would mean the NRST got pulled down.
I will try a scope to catch this. Also, great advice on the HardFault Handler. Would it be a good idea to also create handlers for the below:
MemManage_Handler ; MPU Fault Handler
BusFault_Handler ; Bus Fault Handler
UsageFault_Handler ; Usage Fault Handler
My project is bare metal but the Stack overflow link has some good tips that I could borrow from :) Cheers