I want to improve the accuracy of the microcontroller's tick.

[delta_s]

Hi.
The cause of the issue being inquired about below might be due to tick precision, so I am making an additional post

https://community.st.com/t5/stm32-mcus-products/the-microcontroller-sometimes-cannot-receive-tcp-data/td-p/729099

 

In my system, the microcontroller and the counterpart device are sending and receiving TCP/UDP packets at a 20ms interval.
The microcontroller uses osDelayUntil() and the counterpart uses ROS2's Timer to perform processing at 20ms intervals.

However, when checking the tcpdump on the counterpart device,
the interval between packets received from the microcontroller is slightly shorter than 20ms,
and the reception time gradually becomes earlier than expected by 1ms, 2ms, and so on.
(The pace increases by 1ms every 40s.)

If the accuracy of the microcontroller's tick is improved,
the tick progression will be synchronized with the counterpart device,
and the discrepancy in the reception time will be eliminated.
How can the accuracy of the microcontroller's tick be improved?

I tried changing each of the following IOC file settings one by one, but the issue was not resolved.
Pinout & Configuration
・Timebase Source：TIM5 → TIM1
Clock Configuration
・HCLK(MHz)：168 → 216
・PLL Source Mux：HSE → HSI

Test environment:
Microcontroller : STM32 NUCLEO-F767ZI
Counterpart device : Ubuntu 22.04, ROS2 (C++)
STM32Cube IDE : 1.15.0
STM32 Firmware : STM32_Cube FW_F7 V1.17.1
STM32Cube MX : 6.11.0

Best regards.

[Tesla DeLorean]

For TIM5 or TIM2, which are 32-bit here, you could clock at maximal frequency, ie PSC=0, and adjust the interrupt periodicity via ARR to a few hundred nanoseconds. 

If you have GPS, you can use the 1PPS to latch/measure cycles per second via you clocks, and synchronize to UTC top-of-second. The ETH also has a PTP 64-bit clock/latch as I recall 

[LCE]

> Clock Configuration
>・HCLK(MHz)：168 → 216
>・PLL Source Mux：HSE → HSI

What do you mean by that? That you switched clock source from HSE to HSI?

That should make timing actually worse...

Keep it at HSE, no matter what.

> The pace increases by 1ms every 40s

That's about 25 ppm, absolutely normal values for any crystals / oscillators, and does not look bad to me.

So what you see is typical drift between 2 unsynced devices.

If you want to keep them synced, you either need to provide the same clock to both, or implement PTP.

PTP is possible on the STM32F7 - just lots of work... and no HAL support.