"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]

May I ask @waclawek.jan if you have any idea? thanks

[Tilen MAJERLE]

If the clock is not enabled in the RCC for specific GPIO or peripheral IP, debugger or other interfaces do not have access to the registers, so it won't be possible to read valid reset value.

[JSmit.19]

@Tilen MAJERLE​ Thanks well as I said the clock is enabled in RCC, there are two different things:

1. For USART it seems that even before enabling the clock the register values are correct (wrt reset values), how come?
2. Secondly and most importantly which is the subject of this post RIGHT AFTER ENABLING the RCC clock and before any other initialization some registers (like GPIOB_OSPEEDR) do not correspond to the reset value, any idea why is that?

[waclawek.jan]

Maybe IAR is set to Big Endian display. In some IDEs this is switched in context menu (right-click). I don't use IAR; you may want to read its manual or ask for help at IAR.

JW

[JSmit.19]

@Community member​ Thanks, good idea but I don't think Endianness is the case for two reasons:

1. The other registers are correct
2. I see this inconsistency also for the USART_ISR register for which I get  0x000000C0 while the reference manual says Reset value: 0x020000C0

This should not be IAR specific or at least I hope so 🙂

[Uwe Bonnes]

What about the remark in RM0392 rev2 p 1160 in the register description for Bit 25 TCBGT: "Note: If the USART does not support the Smartcard mode, this bit is reserved and forced by hardware to `0'. If the USART supports the Smartcard mode and the Smartcard mode is enabled, the TCBGT reset value is 1."

[JSmit.19]

@Uwe Bonnes​ Thank you! well, it sounds like a great explanation! However, the datasheet states that:

"USART1, USART2, and USART3 also provide Smart Card mode (ISO 7816 compliant) and SPI-like communication capability."

and I am getting this value both for USART1 and USART3 (have not tried USART2)

As I wrote for @Tilen MAJERLE also for USART it seems that even before enabling the clock the register values are correct (wrt reset values), this has become another mystery for me! Along with inconsistent reset values for GPIOx_OSPEEDR and USART_ISR

Is this reset value independent of the electrical connections (pull-up ...)?

[waclawek.jan]

Avoid the debugger.

Write a simple program, which avoids the default startup code (write a simplified one with no calls, just the RAM clear), enables clock, reads out the given register and outputs it in a way you can observe (e.g. to an USART connected to PC).

The reset values in RM are sometimes wrong, especially in cases where the register is not a simple readable/writable flip/flop, but where its value is controlled by some other hardware (i.e. the reset value may be correct but as soon as you leave reset it might have changed "automatically").

This said, GPIOA->OSPEEDR should be correct because it determines the speed of SWDIO pin.

JW

[JSmit.19]

@Community member​ Thanks, out of curiosity

Could you please tell me if a pin is connected to a device or resistor, and after enabling clock and before configurations of a peripheral should we still get the reset values? if no the transition can be detected in debugging?

[waclawek.jan]

The value of GPIO_OSPEEDR is not dependent on external connections.

JW