Correction Request: Internal RC Oscillator accuracy specs For STM32F4 (possibly others)

[BarryWhit]

Please see this thread from 2018

https://community.st.com/t5/stm32-mcus-products/stm32f4-hsi-accuracy-drift/td-p/360021

The poster complains that the datasheet claims 1% accuracy for the RC oscillator over full temperature range,

but other sources (such as the intro to AN4067 - Calibrating internal RC oscillators) suggest that  the 1% accuracy is at 25C only (and that this perhaps is only "typical" accuracy).

The claim still appears in in the STM32F4 datasheet when I checked today. I believe this error may has been copy-pasted to the documentation for other product lines. 

Also, there doesn't seem to be a dedicated forum label for such reports (I'm assuming "Error" is more about software issues, then "mistakes" in documentation).

(This post moved here since @STTwo-32 suggested this is the proper place to post about errors in documentation.)

[AScha.3]

Hi,

>I believe this error may has been copy-pasted

Sorry, which "error" ? 

As from ds (F411) , states: "16 MHz internal RC oscillator is factory-trimmed to offer 1% accuracy at 25 °C.

And in data :

see footnote 4 :

You ever got a chip mounted without soldering ? :)

So its just : +/- 4% , "maybe" better, up to 1%, as calibrated in fab, if you can solder very cool ... :)

And the "error" is ...obscured euphemistic description , that never will be reached in real use ?

[BarryWhit]

---

@AScha.3 wrote:

Hi,

>I believe this error may has been copy-pasted

Sorry, which "error" ? 

don't get snippy with me, boyo.

Which error? This error:

Which is (still) exactly where the thread I linked pointed to, in 2018. As you would have seen, if you had read the thread.

The rest of what you wrote isn't relevant.

> You ever got a chip mounted without soldering ? 

Well, When I'm feeling unsure of myself, I sometimes just put the chip on the pads and press down hard while holding the probe with my other hand. There was also the Hot-Glue/Exposed-Pad incident, but I don't really like to talk about that.

[BarryWhit]

Followup snafu from reading more about this issue (new to me, fascinating):

From AN5067: How to optimize STM32 MCUs internal RC oscillator accuracy  

but later in the document

so, you have a graphic of results showing the oscillator frequency is higher (mean of 16.1khz instead of 16Khz),

but the text states the thermal stress causes the frequency to drop. Unless I'm misunderstanding something (which happens), this is a contradiction.

[waclawek.jan]

>  but the text states the thermal stress causes the frequency to drop

...or to rise (half a sentence later).

JW

PS it's 16MHz not 16kHz

[BarryWhit]

---

@waclawek.jan wrote:

>  but the text states the thermal stress causes the frequency to drop

...or to rise (half a sentence later).

---

Come on. They say "typical effect is lower freq, and sometimes but not often higher freq" and they show 500 sample points from a test, 95% of which are higher in frequency.  There's an obvious contradiction between text and data there.

> PS it's 16MHz not 16kHz

right you are.

[STTwo-32]

Hello @BarryWhit 

I'm checking on this and I will be back to you with an action ASAP.

PS: On your Communing posts, please use this Forum to post. Sorry for this misunderstand, when I said "this Community" on your previous post I mean that you can post on the forum that you find suitable for your post on all the forums of this community depending on your product, use case,... Sorry again for this misunderstand, I will give more details (editing my previous post).

Thanks also for @Andrew Neil

Best Regards.

STTwo-32

[waclawek.jan]

> they show 500 sample points from a test, 95% of which are higher in frequency.

IMO it's not about the deviations of individual frequency readings, but the average, in one specimen. The "typical effect..." etc. means, that the temperature shock during soldering shifts the frequency irreversibly, and in most chips the HSI's average frequency is lower than it used to be before soldering. The shown example is that less common case, where the average is higher. And what.

The point is, that this effect is something ST discovered quite recently,  some10 years after the chips are in manufacture. It's quite understandable: ST does not use them soldered. So they fixed the table with the footnote,  but forgot to fix the text in narrative (which you rightly expect to be fixed, too; but there are much worse things in the docs. Doing docs properly is very hard and very expensive. I'm the last person to defend sloppiness in ST's docs, but these things have to be acknowledged, too.)

JW

PS. One thing worthy of noting on that picture is, that the HSI frequency is fluctuating. It means, the 1% is not just an "initial deviation", but also includes a certain amount of that "permanent fluctuation" (in more serious setting we would talk about jitter, although that's just a fancy yet usually very vaguely defined term, too). And that's entirely uncharacterized, and for a good reason.

[EDIT] I misinterpreted that figure [/EDIT]

[BarryWhit]

> and in most chips the HSI's average frequency is lower than it used to be before soldering

This sounds like a real stretch. So what you're saying is that when the chips come out of the factory, chips which ST engineered so that the spread is centered around the target nominal frequency of 16Mhz, 95% are even more than .1Mhz above the spec, so that soldering actually makes them better? that's a definition of "typical value" I've never heard of.

Also, look at the captioning (or is it text) right below the graph in the image i posted. "after soldering, Additional errors" and they say soldering effects are unpredictable, so I doubt they design this deviation in on-purpose so customers can dial it just so with the available calibration range. That would be mad. If that were true that would mean that if someone takes great care during assembly (as ST recommends in the text) they would get *worse* results on average without calibration.

> So they fixed the table with the footnote,  but forgot to fix the text in narrative

Hey, I'm with you. There's no way to put out tens of thousands of pages of technical documentation without tons of errors big and small. I do expect that once someone calls an issue out (and more importantly, succeeds in flagging down someone from ST), it will be corrected within a reasonable time-frame. It shouldn't languish in a thread for 6 years.

[BarryWhit]

@STTwo-32 , Thank you.

I am glad to post such issues in any forum, community, subreddit, contact form, or OLS ticket you direct me to. I just want to know what communication channel guarantees that the feedback will make its way to the proper contact inside ST.  It shouldn't depend on getting lucky and having an ST employee coming across the thread by accident. After all, the thread I linked to *was* posted on the forum (in 2018) - and nothing came of it.

Is there a particular person (or official "docs team" forum handle) we can/should ping for documentation issues?

The Gurus (and several of the lesser mortals) on this forum really have incredible depth of knowledge about ST products, and I think too often they pin down things which ST would be wise to pick up, only to have their insights lost in the noise.