"Reset value" does not correspond to the register value in debugging.

[JSmit.19]

Hello,

I am using a STM32L471QGI6 MCU and its reference manual (RM0351) is:

https://www.st.com/resource/en/reference_manual/dm00083560-stm32l47xxx-stm32l48xxx-stm32l49xxx-and-stm32l4axxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

Regards the "Reset value:" written in the RM0351 document I have a specific question:

Let's take this example:

8.5.3 GPIO port output speed register (GPIOx_OSPEEDR)

(x = A to I)

Address offset: 0x08

Reset value: 0x0C00 0000 (for port A)

Reset value: 0x0000 0000 (for the other ports)

My question is:

I assume I have to expect the "Reset value" for the GPIOx_OSPEEDR register at the start of the MCU and before the initialization of the GPIOx? Is that right? Well, this is not what happens! I use IAR Embedded Workbench and when I go into debug I find another value that is 0x000000C0, my question is why?! I emphasize that this is before any initialization in the C program.

Could it be the document is wrong ?!

Thanks

[JSmit.19]

Any idea is appreciated @Tilen MAJERLE​  @Jocelyn RICARD​ 

[Uwe Bonnes]

Did you really set a breakpoint on the very first instruction? If you break in main(), a lot may have happend!

[JSmit.19]

Indeed I break before the main(), I just miss some inits by assembly file (like a startup.s) which should not initialize the GPIO. May I ask what is your approach to put a breakpoint at the very first instruction?

[Tilen MAJERLE]

Just to be sure, did you enable GPIOA clock in RCC before reading registers? If not, you are not reading valid values.

[JSmit.19]

@Tilen MAJERLE​ Yes it is

[Uwe Bonnes]

If you do not know your startup entry, read it at 0x08000002 and set a breakpoint at that address. But better look at the label given in your startup file. And startup may already set up things with regard to GPIO.

[JSmit.19]

@Tilen MAJERLE​ Well I break during the configuration of the GPIO and clock is enabled before that.

[JSmit.19]

@Tilen MAJERLE​ I edited the last part of the question the problem is only with the GPIOx_OSPEEDR register for GPIOB. (I had done some modifications to understand why the problem happens and some other values were wrong due to that but that was originally the problem and still is)

I also noticed that also the reset values of the USART_ISR register do not correspond to the RF, however, unlike GPIO here (for USART) the reset values do not dependent on enabling clock, meaning that before or after enabling the RCC the USART registers have the reset values (except USART_ISR of course! )

could you explain this, please?

[JSmit.19]

Thanks, I tried putting a breakpoint where the initialization starts, same results! So the place of the breakpoint should not be the issue.