How does HSI48CAL get loaded into RCC_CRRCR

[TKoja.2]

Hi ST Community,

Does anyone know how the HSICAL48 value gets loaded into RCC_CRRCR? The RM says "These bits are initialized at startup with the factory-programmed HSI48 calibration trim value", so I assume the trim value is stored somewhere in system FLASH and it gets loaded into the register by hardware. If this is the case, does this happen at every system reset or only for power-on-reset?

Asking because I've seen seen the calibration value be substantially off (i.e. 0xa when it should be 0x12a) and cause the HSI48 to run at ~33 MHz instead of 48 MHz.

Thanks

[TDK]

HSI48CAL is read-only. You're saying this value changes? It should have the correct value after any type of reset.

[TKoja.2]

Thanks for the response! Yes, when looking at the register values through CubeIDE after a reset, I've seen two different values for HSI48CAL on the same device. 

This one, which gives me 48 MHz (confirmed by outputting HSI48 to the MCO pin)

and this one which gives me 33 MHz (confirmed by outputting HSI48 to the MCO pin)

Also, I'm currently talking with ST customer support to diagnose an issue with my device locking up when an EXTI interrupt comes in quickly after entering STOP 2. It's usually when I reset after this issue that I will see the incorrect HSI48CAL value. I can recover from the incorrect value by power cycling the device or by doing an Option Byte Launch (w/o changing any of the option bytes).

[TDK]

Interesting.

Barring an error in the clock scheme you have set up, seems like you have stumbled upon the rarely found silicon issue. Please keep us posted as you work with ST support. A lot of us find this stuff interesting. Could always be something else though.

Nothing in the errata sheet about this.

[TKoja.2]

Appreciate the help!

I'm going to do my due diligence confirming that the clock scheme is error free and mill over my code a bit more, to be sure. Once I hear more from ST support, I'll follow up on this thread with any information related to these issues.

[pscheidler]

Can we get a response from STM on this? I really worry about this type of fundamental instability on a chip