cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 RCC->RSR register does not hold reset cause

Olaf
Visitor

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.

    Olaf_3-1753867346347.png

     

  • 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.

    Olaf_4-1753867387445.png

     

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

4 REPLIES 4
Andrew Neil
Super User

@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?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

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.

 

 


@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?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
AScha.3
Super User

Hi,

 

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

zero---mmm ? from rm :

 

AScha3_0-1753872419067.png

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...

If you feel a post has answered your question, please click "Accept as Solution".