Skip to main content
LPetr.1
Senior
October 15, 2026
Question

STM32G484 HRTIM: external-event-to-counter-reset latency and conflicting RM0440 timing values

Hello,

I am using an STM32G484RE with HRTIM running at 160 MHz, configured as follows:

  • Timer B runs continuously with prescaler HRTIM_PRESCALERRATIO_MUL32.
  • External event EEV7 comes from GPIO PB4.
  • EEV7 uses rising-edge detection, with digital filtering disabled.
  • EEV7 resets Timer B’s counter.
  • The same EEV7 event sets Timer C’s output TC1.
  • TC1 SET triggers Timer B capture 1.

I need to understand the timing between the external GPIO edge, Timer B counter reset, and TC1 SET/capture.

I found the following differences in RM0440:

  1. The older timing diagram, Figure 217 in the edition corresponding to English Rev 7, shows 2–3 HRTIM clock cycles for input resynchronization/counter reset, followed by 3 additional cycles before the output changes.

     
  2. In RM0440 Rev 9, Table 241 on page 928 lists 5–6 cycles for synchronous output response.

     
  3. Figures 244–245 on page 929 instead show 6–7 cycles and no longer show the intermediate counter-reset timing.
  1.  

Could you clarify

  1. What is the minimum/maximum latency from the EEV7 GPIO rising edge to Timer B’s counter resetting, for the configuration above? Please specify the timing reference points and whether GPIO/input-path propagation is included.
  2. Which synchronous output-response value is correct: 5–6 cycles or 6–7 cycles? What accounts for the difference between Table 241 and Figures 244–245?
  3. Where is the TC1 SET event used by another timer’s capture logic taken from? Is it before or after the output-processing latency shown in Figure 244? Is there additional latency before the receiving timer samples its counter?
  4. Do these timings depend on the external-event channel, rising versus falling edge, or silicon revision?