arch/arm/stm32h7: fix the period of the PPS output - #20236
Merged
acassis merged 1 commit intoSep 22, 2026
Merged
Conversation
The interval and the width of the pulse train of the PPS output were programmed as the number of increments of the system time minus one, but the MAC takes them as they are. Each period was one increment (10 ns with HCLK at 200 MHz) shorter than a second, so the pulses came 10 ns early each second, about 36 us in an hour, and the output drifted away from the system time. Program the interval and the width without subtracting one. On a run of 8.2 hours against a grandmaster clock the pulse moved 0.29 ms ahead of the system time, which is 10 ns per second, while the system time stayed within 1 us of the grandmaster. With the change, a run of 11 hours showed no drift of the pulse against the system time, within 3 us per hour on samples of 1 ms of resolution. Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com> Assisted-by: Claude:claude-sonnet-5
daniel-p-carvalho
requested review from
davids5 and
xiaoxiang781216
as code owners
September 21, 2026 21:49
github-actions
Bot
added
Arch: arm
|
xiaoxiang781216
approved these changes
Sep 22, 2026
acassis
approved these changes
Sep 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The pulse-per-second output of the STM32H7 Ethernet MAC (
STM32_ETH_PTP_GPIO, added in #20212) is a pulse train with a period of one second, started at a whole second of the system time. The driver programmed the interval and the width of the train as the number of increments of the system time minus one, but the MAC takes the values as they are. Each period was one increment (10 ns withHCLKat 200 MHz) shorter than a second, so the pulses came 10 ns early each second, about 36 us in an hour, and the output drifted away from the system time that the PTP daemon steers.This PR programs the interval and the width without subtracting one.
Impact
STM32_ETH_PTP_GPIO, which no board of the tree selects yet, so no existing configuration changes.Testing
Built for a custom board with an STM32H753 and a DP83848 PHY, with
STM32_ETH_PTP,STM32_ETH_PTP_GPIOandPTP_CLOCK, on the currentmaster, without errors or warnings../tools/checkpatch.sh -g upstream/master..HEADpasses.On hardware, against a GNSS-referenced
ptp4lgrandmaster, withptpdfrom apache/nuttx-apps#3782 steering the system time of the MAC (the phase difference measured by the daemon was 0.9 to 1.0 us on average, without a trend, in both runs). The phase of the PPS edge against the system time was sampled every minute: