2025-11-03 2:28 AM
Affected doc / section
RM0492 (STM32H503) → General-purpose timers → Master mode selection (MMS) (TIMx_CR2.MMS = 0000 “Reset”)
Current wording (verbatim)
“MMS = 0000 – Reset: the UG bit from the TIMx_EGR register is used as trigger output (tim_trgo). If the reset is generated by the trigger input (slave mode controller configured in reset mode) then the signal on tim_trgo is delayed compared to the actual reset.”
Why this is confusing / misleading
The sentence suggests TRGO is tied to the EGR.UG bit. In reality, EGR.UG is software-only; hardware reset does not set EGR.UG. TRGO is driven by the update-generation path (UEV/UG-equivalent internal signal), not by the literal EGR bit.
It does not state that with URS=1 (CR1.UPDATE REQUEST SOURCE), a reset from TRGI/ETR does not generate a UEV. Therefore, with MMS=Reset, TRGO is not emitted at the moment of reset; it only appears on a later UEV (e.g., overflow) — or never if the counter is reset before reaching ARR.
The phrase “delayed compared to the actual reset” lacks magnitude or conditions, while after days of searching one can leanr it is a 1-cycle delay, and cycle is accoring to TIM clk.
Minimal reproducible setup (H503 example)
HCLK: 210MHz
TIM1: PSC=20 (10 MHz), ARR=9999, SMCR.SMS=100 (Slave Reset), SMCR.TS=ETRF, CR1.URS=1, CR2.MMS=0000 (Reset), MSM=1, TIM1_ETR connected to GPS 1PPS.
TIM2: PSC=0, ARR=210021000, SMCR.SMS=100 (Slave Reset), SMCR.TS=0 (TIM1_TRGO), CR2.MMS=0000 (Reset), MSM=1.
DMA CH triggered by TIM2_TRGO sends datagram over USART every second.
Observation: The falling edge of the first start bit on the USART TX broadcast is delayed by several microseconds relative to the rising edge of the 1PPS signal (used to trigger the DMA transfer and timer reset).
CH1 is 1PPS from GPS
CH2 is USART TX pin
Delay is 56us
2025-11-03 3:37 AM
This is a too long chain to draw conclusions. Set up TIM1 and TIM2 to output PWM and add to your observation. I also don't see how would it result in 56us delay, wouldn't DMA and UART be involved.
JW
2025-11-03 4:09 AM
Hi
One thing is documentation itself. To me it shall be improved.
Other thing is 56us delay which I can not explain.
The reason for this configuration is:
- I need TIM1 TRG interrupt to monitor 1PPS
- I need TIM1 UP to count milliseconds
- TIM2 is used to calibrate HCLK (must not use ETR directly) thus is using TIM1 TRGO
- TIM2 is the only one that can trigger DMA.
Alternative setup would need EXTI configured for ETR pin that will trigger DMA.
The purpose is to use start bit falling edge as ETR in other device thus propagating 1PPS over the serial link.
2025-11-03 4:41 AM
> One thing is documentation itself. To me it shall be improved.
Agreed, but I wouldn't hold my breath.
I'm not sure what exactly do you want to achieve - maybe drawing a timing diagram highlighting the expected events in the timers at various starting conditions would help - but I would doubt the DMA-UART mechanism at the first place. You may want to start by characterizing this, e.g. by outputting a PWM waveform from a free-running timer, which simultaneously triggers the DMA-UART mechanism. Divide et impera.
And, as I've said, if you want to draw conclusions from the timers' setup, output PWM from the timers in order to visualize their state. This may be easier to do using something like a Nucleo (and perhaps a pulse generator instead of the GPS, to be able to simulate various mutual speed relationships), rather than some dedicated hardware.
JW