STM32H563: PINRST not set after NVIC_SystemReset() used to reset the MCU

[mccabehm]

STM32H563 on custom board. Using NVIC_SystemReset() to reset. It resets consistently.

I expect LL_RCC_IsActiveFlag_PINRST() to return true after the MCU comes out of reset. It consistently returns false.

NVIC_SystemReset() should result in pin reset, yes?

LL_RCC_IsActiveFlag_PINRST() returns false after a restart with STM32CubeIDE debugger also.

Could something on the board hold NRST high?

[TDK]

If NRST is held high, the chip won't reset, so that's not it.

Something is probably clearing the flag before you get to it. PINRSTF is always set on reset, no matter the type.

Search RCC->CSR in your code, or the equivalent LL statements. Something probably uses it.

[mƎALLEm]

Hello,

---

@mccabehm wrote:

STM32H563 on custom board. Using NVIC_SystemReset() to reset. It resets consistently.

---

1- Watchdog timer is enabled?

2- NVIC_SystemReset() called without any condition in your application? 

 

[mccabehm]

Clarification:

• NVIC_SystemReset() is called as a result of an external CAN command. This consistently resets the MCU. A reset switch on the board also consistently resets the MCU. The IDE debugger also consistently resets the MCU.
• Coming out of reset, LL_RCC_IsActiveFlag_PINRST() sometimes detects reset cause. Less than 20% of the time it correctly detects the reset cause.

TDK's response reminded me: between the NVIC_SystemReset() call and LL_RCC_IsActiveFlag_PINRST() -- I have a custom bootloader in place. This could be clearing the RCC RSR before LL_RCC_IsActiveFlag_PINRST() runs. I will investigate.

[mccabehm]

I verified that the custom bootloader is responsible for clearing RCC RSR (reset status register). Verified with pin and software resets. So when my application runs and checks for reset cause, it will usually see no reset cause. Not sure why < 20% of the time the resets are not cleared. But sufficient to consider the mystery solved.