STM32H7 RCC->RSR register does not hold reset cause

[Olaf]

Hi everyone,

I'm encountering an issue with the reset cause on my STM32H723VE microcontroller.

Whenever I perform either a software or hardware reset, the RCC->RSR register does not retain any value—it always reads as zero.

Here’s what I’ve observed using Ozone:

• If I set a reset breakpoint, execution halts immediately after the reset, as shown in the image below.

  

   

• However, if I set a breakpoint at the first instruction of the Reset_Handler, and then press "Run", execution stops correctly—but by that point, the RCC->RSR register has already been cleared and reads all zeros.

  

   

Has anyone else encountered this behavior? Could something be clearing the RSR register very early in the boot process, even before entering main?

Any insights would be appreciated.

Best 

Olaf

[Andrew Neil]

---

@Olaf wrote:

observed using Ozone:

---

You mean this: https://www.segger.com/products/development-tools/ozone-j-link-debugger/ - by Segger?

 

---

@Olaf wrote:

Could something be clearing the RSR register very early in the boot process, even before entering main?

---

Possibly - would be worth asking Segger: 

https://www.segger.com/support/technical-support/

https://forum.segger.com/board/14-ozone-related/

 

Does the same happen under other debugger(s); eg, STM32CubeIDE ?

Or if you run without a debugger and, say, just output to UART?

[Olaf]

Hi Andrwe Neil,

thanks for your reply!

 

---

@Andrew Neil wrote:

 You mean this: https://www.segger.com/products/development-tools/ozone-j-link-debugger/ - by Segger?

Yes, this one. --> Ozone Debugger and performance analyzer

 

---

@Andrew Neil wrote:

---

Does the same happen under other debugger(s); eg, STM32CubeIDE ?

Or if you run without a debugger and, say, just output to UART?

---

I haven't tested with other debuggers yet, but it doesn't seem to be a debugger-related issue.

Update:

The issue appears to be related to the compilation mode. I have different build configurations depending on whether the .bin file includes the bootloader sector, is intended for production, for debugging, etc.

It seems that the problem is specifically related to the use of the .noinit RAM section in some of these configurations.

In the builds where I'm not using the .noinit section, the RCC->RSR register is preserved correctly and I can read its value after a reset—so the issue only occurs in configurations that include .noinit.

 

 

[Andrew Neil]

---

@Olaf wrote:

I have different build configurations depending on whether the .bin file includes the bootloader

---

I think it's very likely that a bootloader could clear these bits?

[AScha.3]

Hi,

 

>the RCC->RSR register does not retain any value—it always reads as zero.

zero---mmm ? from rm :

 

SO if at reset/after reset state , it reads: FE0000 .

You "read" at what address ??

Just look in IDE in the SFR tab...right side...

[Olaf]

Hi,
Thanks everyone for the responses.
I finally realized that the issue was caused by my bootloader.
That is, when the microcontroller is powered, it always enters the bootloader application first (if it has nothing to do, it jumps straight to the main application).
The RCC->RSR register was being cleared by the bootloader, so by the time the main application started, the register had already been cleared.

[Andrew Neil]

So my guess was good ?

Now please mark the solution.