STM32F0 factory HSICAL values wiped after resetting RDP Level 1

[limcb]

Hi, I have 3 STM32F091 chips that have their factory HSICAL defaulting to 0x0F as opposed to HSICAL = 0x5C/0x60 on working units.
I'm using STM32CubeProgrammer.
I suspect this happened when I had enabled RDP Level 1 / BB, then I needed to update the firmware again; wrote AA the the RDP to unlock it, flashed the new firmware. After power reset, they started clocking wrongly.

MCO pin, with prescale applied, showed 5.88MHz as compared to ~8MHz on the working units.
Plugging in the ST LINK and reading the registers from CubeProgrammer, this is what I got, as mentioned in the beginning;

How do I restore or recalibrate back RCC HSICAL ?

[Amel NASRI]

Hi @limcb ,

While I don't think that RDP level change will impact the HSICAL, I suggest you calibrate your HSI.
You need to adjust the HSITRIM and you can refer to this post https://community.st.com/t5/stm32-mcu-products/mcu-internal-oscillator-is-not-16mhz-but-18mhz-on-some-mcu-why/m-p/216548 for a similar case with a solution by @TDK .
The Application note suggested in the solution should be helpful.

-Amel

 

[Piranha]

So was it ST's fault in that case or not? If yes, then why isn't it added to the errata?

To the author... Are you sure the MCUs are genuine? Also don't trust the CubeProgrammer. Read those values with your code. Check whether the register address and bit field definitions are correct. Check the respective descriptions in SVD file.

[waclawek.jan]

Hi Amel,

Is it *possible* that CubeProgrammer - or a runaway or incorrectly written user program - reprograms HSICAL? In other words, is there an unpublished sequence which could've been invoked by mistake/error/coincidence which enables to overwrite HSICAL, or is it impossible e.g. due to factory-set locks?

JW

@Amel NASRI 

[Tesla DeLorean]

The inference I'd take from this is that the "mass erase" has broader scope than anticipated / documented.

[waclawek.jan]

I would very much like not to take this inference.

I'd very much like to hear an answer based on deep knowledge of the chips' internal programming mechanisms. Because, let's face it, the vast majority of answers we have here from our Moderators, FAEs and other ST Employees is based on the very same public documentation we already have.

And I'd very much like ST taking us seriously, for once. And by "us", I mean also our Moderators and FAEs.

JW

 

[Antoine Odonne]

Dear community members,

No erase operation or RDP activation, regression should have impact on your HSI calibrated value. This calibration value is evaluated during production and stored internally on a (system) read only memory location, it is then added to HSITRIM in order to create the HSICAL field applied to the oscillator to tune its frequency. 

By applying "0x00" or "0x1F" to HSITRIM on your faulty parts, which frequency and HSICAL value can you observe ? 

You observed this behavior on 3 samples out of which quantity ? 

It seems challenging to get back to 8MHz with the HSITRIM in your case starting from 5.3MHz and in regards of the excursion of the TRIM field. You must then try to get in touch with your distributor or sales contact in order to open a failure analyzis request (the sample being clearly out of specification). 

Thank you and regards,

Antoine

[waclawek.jan]

> By applying "0x00" or "0x1F" to HSITRIM on your faulty parts, which frequency and HSICAL value can you observe ?

+1

Also, what value has RCC_CR2 (i.e. HSI14CAL and HSI48CAL)?

JW