3 ms·
I couldn’t find anything in the docs or on the Internet about why this might happen with the autocal, and there’s nothing that details exactly how it works eith
by userbinator 2y ago
I couldn’t find anything in the docs or on the Internet about why this might happen with the autocal, and there’s nothing that details exactly how it works either.
A quick search found this document on the internal RC oscillator calibration, which explains all you need to know: http://nic.vajn.icu/PDF/STMicro/ARM/STM32F0/STM32F0xx_internal_RC_osc.pdf http://nic.vajn.icu/PDF/STMicro/ARM/STM32F0/STM32F0xx_intern...
It is recommended to stop all application activities before the calibration process, and to restart them after calling the calibration functions. Therefore, the application has to stop the communications, the ADC measurements
and any other processes (except when using the ADC for the calibration, refer to Step 5. below). These processes normally use clock configurations that are different from those used in the calibration process. Otherwise, errors might be introduced in the application: errors while reading/sending frames, ADC reading errors since the sampling time has changed, and so on.
- readmodifywrite 2y agoThis is a good resource, however, it didn't apply in my situation because it describes the manual calibration process, not the auto-cal (which the F0 probably doesn't even have). I still haven't come across anything that explains in detail how the auto-cal works and precautions one needs to take when it is running. The reference manual section is something like one paragraph and can be summarized as: "You can turn this on and it will calibrate your clock. You can also turn it off." If I had to guess, it probably does something similar to the manual process, but just in the MCU logic. It's the lack of detail that got me: I basically ran out of things to try on the UART itself and started looking around at other parts of the chip to see what could at least be indirectly related.