Unexpected Behavior in RCC->CSR Register and Processor Exit from While Loop (STM32F765VGT6)

[athulya]

Dear STM32 Community,

PFA for your reference.

I am working with an STM32F765 on a customized board, using STM32CubeIDE version 1.17.0. I am facing an issue related to the RCC->CSR register and processor behavior.

Issue with RCC->CSR: At the beginning of execution, `RCC->CSR = 0x14000000`, which indicates a normal power-on reset. However, when I run the program without breakpoints, `RCC->CSR` shows `0x00000000` after the first loop, which seems incorrect.
Breakpoint Behavior: When I set a breakpoint and step through the code, `RCC->CSR` shows `0x14000000` only during the first loop, and after that, it becomes `0x00000000`(cleared RCC->CSR manually after reading). PFA for your reference.
Processor Exit from While Loop: Additionally, when running without a breakpoint, the processor is unexpectedly exiting the while loop. I am unable to identify why it is going outside the loop.(with RCC->CSR value 0xd50106d2)

Steps Taken:
1. Printed the value of `RCC->CSR` at different stages and confirmed the unexpected change.
2. Cleared reset flags using `RCC->CSR |= RCC_CSR_RMVF;`, but the issue persists.
3. Verified that watchdog resets (`IWDG/WWDG`) are not enabled.
4. Observed that adding a breakpoint seems to affect the execution flow, keeping `RCC->CSR` valid only in the first loop.

Request for Help:
Could you please suggest a solution to address the following:
1. Why does `RCC->CSR` change unexpectedly after the first loop when running without breakpoints?
2. Could this issue be caused by memory corruption or an unintended reset?
3. Why is the processor unexpectedly exiting the while loop?
4. Any suggestions or solutions to fix this issue?

Your assistance and suggestions will be highly appreciated, and I would be grateful for a prompt response.

Thank you for your support!

[TDK]

RCC_CSR is meant to be read once after powerup. After you clear it, it will be zero until the next reset happens. Doesn't make sense to read it in a loop.

Your second screenshot shows you are in 0x1FFFxxxx which is system memory, so probably you're in the bootloader. Is BOOT0 pulled down? You're not running the main flash code so the "reset_cause" variable is irrelevant here. It was never set.