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

[LPetr.1]

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? 

[Imen.D]

Hello ​@LPetr.1 

I escalated your request internally for further review (internal ticket number: CDM0066737). 

 We will give you an update as soon as possible.

[Imen.D]

Hello ​@LPetr.1 ,

I've heard back from the team and here is the answer :

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.

The latency from the EEV7 edge to Timer B counter reset is 5 to 6. It breaks down into 2 to 3 cycles of input resynchronization plus 3 cycles until the counter reads 0. The 1-cycle spread comes from the asynchronous edge being sampled by the clock.
The timing starts when the external event reaches the HRTIM input (the internal hrtim_eev7 signal). These figures do not include the propagation through the GPIO and input path, which RM0440 doesn't specify separately.
For a pin-to-pin figure, the datasheet gives 56 ns typical and 66 ns max at 170 MHz. Those values come from characterization only, not from production tests.

 

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?

I need to check this point with the architecture and design team and I will be back to you with updates.

 

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?

The counter reads 0 on the same fHRTIM edge where the output is set. The 5–6 cycles are therefore already over when Timer B starts counting, so they never appear in the capture for another capture timer unit.

 

4-Do these timings depend on the external-event channel, rising versus falling edge, or silicon revision? 

Here is the dependencies:

==> Fast mode, on EEV1–5 only
==> The digital filter, on EEV6–10 only
==> Rising vs falling edge: no difference 
==> Revision: it should be no dependencies.