Previous post: Debian for STM32MP1

NIC Hardware Timestamps

First step: enable hardware timestamps in chrony.conf:

chrony configuration for hardware timestamps

Next, enable chrony's measurements log, and verify it's using hardware timestamps (H) not kernel timestamps (K):

it's using kernel timestamps

Looking into why it wasn't using the hardware timestamps, I found that the STM32MP1's device tree does not enable the clock to the NIC's timestamping system.  I opened a github PR for that.

After switching to the new device tree, chrony picks up the timestamps:

hardware timestamps

The peer delay column shows one source with 236us round trip time (not using hardware timestamps on the other end), and two polls of another source with a 6.7us round trip time.

PPS Hardware Timestamps

There's a base driver for the stm32 timer hardware, so I built on that.  I created a "clocksource" and a pps driver https://github.com/ddrown/stm32-timer-drivers

The default linux kernel clocksource is the arm arch timer running at 24MHz.  Switching to the TIM5 timer clocksource provides more precision at 209MHz.

Results

Unfortunately, there's a problem with the stability of this system's clock.  Perhaps it's a similar PLL issue that I ran into before.

Taking the system's frequency data over a week and overlapping every 1,089 second time period shows the pattern is pretty regular.

This limits the time accuracy of this system. The rapid frequency change results in a larger clock offset till the system catches back up again.  It settles back down for awhile till the frequency jumps again.

Next Step

Adding a TCXO and fixing the offset problem