How in-accuracy of SYSCLK affects the HAL_GetTick?

[HSing]

I have observed, using a frequency counter, that the HSE clock on Nucleo board (after using the calibration value in the OTP memory) is off by around 20ppm. I have configured the SYSCLK to HSE_SYS. Now, HAL_GetTick counts the tick from the derived clock. So, it will go (in ms) off after certain time. right?. Could we correct such error.

My application requires precise timekeeping. I see similar issue in the RTC source clock. it's deviated from the actual frequency of 32768Hz. Is there any procedure to correct the deviation.If someone could point to any literature on how to do precise timekeeping in embedded systems considering different latencies and physical errors.

[Tesla DeLorean · Accepted solution]

Problem is all these things are impacted by multiple variables, like aging, voltage and temperature. You can't just stick in one fixed calibration value and hope.

ST has different methods to trim, and add/remove clocks in short/long term, to accommodate more fractional error.

For radio applications with tight timing requirements, people frequently use TCXO sources.

Time keeping and frequency applications often use GPS/GNSS.

Some of the Ethernet parts have PTP/IEEE1588 "support", but it would take some work to understand.

[HSing]

Thank you Clive for the quick reply and the information. I'll look into the TCXO sources and GPS based timekeeping.

Could you elaborate on ST's different method on accommodating the errors.

[Tesla DeLorean]

You'd need to review the technical docs for the parts, I can't provide training on these materials/methods.

[HSing]

I understand. Thank you for the direction. 🙂