Master TIMER3 -> Slave TIMER1 Synchronization: Slave Timer ETR pulse counting

[BrMel10]

APPLICATION OBJECTIVE:

• The objective is to monitor a high-frequency signal in the range of 0 to 50 MHz from an external device and count the signal pulses every 10 microseconds windows/bins.

Platform:

• STM32F7

APPROACH:

The current approach is to configure the MCU HW peripherals as follows:

• External signal connected to Timer1 ETR. 
  • TIMER1:
    • Configured as SLAVE of TIMER3 (SMCR:TS)
    • Slave in external clock mode 2 + trigger mode
    • DMA configured to copy the CNT register to a memory buffer  
  •  
  •  TIMER3:
    • Used as timer to generate the window (10 microseconds) duration
      Configured as MASTER of TIMER1.
• In a nutshell, when TIMER3 master toggles its TRGO every 10 microseconds, the TIMER1 slave senses it in its TRGI and the current TIMER1 CNT value is saved in memory.

EXPECTED RESULTS:

When using a signal generator with a stable and known frequency signal as TIMER1 ETR input, the expected pulse counts over the measurement window should look stable and repeatable.
For example, with a input signal of 4MHz connected on TIMER1 ETR being measured every 10 microseconds window, each measurement should result in 40 pulses counted per window.

CURRENT RESULTS / PROBLEM:

Overall the approach seems to work.
I.e., considering the above example "signal of 4MHz and being measured every 10 microseconds window" the 40 pulse counts are observed most of the time
However, sporadically, we observe a stream of 10 microseconds window measurement readings set to 0 or 1 followed by results stabilization and resuming the expected 40 pulses counted.
(See attached RealTerm_Ccapture.txt file... expected results stabilize at line 254)

PROBLEM OCCURENCE FREQUENCY:

Issue is observed randomly but typically always on the initial windows. So far no issues have been observed in the "middle" of a measurement stream after correct results are observed.

INVESTIGATION OBJECTIVE:

Considering the issue occurs sporadically, fiddling with register settings in a trial and error debug approach is not really suitable since we never know if the issue might still occur.

The objective of this ticket is to:

• Understand the reason of this behaviour.
• Fix the issue if possible.
• If such behaviour is expected considering the timers interconnect design/synchronization, and fixing it is not possible, then can it at least be detected "hardwarewise" (MCU registers, interrupts, whatever visibility the MCU grants us) so that the measurement can be marked as invalid.
  Emphasis on "hardwarewise" meaning: without looking at the final data stream. Reason being that because later, in the final application, the signal generator currently used during development will be replaced by an optical sensor whose output signal varies considerably and a sequence of 0 counts may actually be a valid measurement.
• Get some ideas on how to proceed with the investigation.
• Suggestions for alternative approach/implementation besides the one currently adopted?

Any suggestion or input would be extremely welcome?

Kind regards.

[BrMel10]

SOME RANDOM THOUGHTS (even if true not sure how to debug them):

• Could TIM3 for whatever reason generate a fast stream of TRGO events which TIM1 senses in its ITR and its DMA transfer is triggered.
• Could this be due to the fact that Timers1 and Timer3 are connected to different APB busses (APB2 and APB1 respectively).
• Could it have something to do with:

SMCR :: Bit 7 MSM: Master/slave mode
0: No action
1: The effect of an event on the trigger input (TRGI) is delayed to allow a perfect
synchronization between the current timer and its slaves (through

SMCR::MSM is Currently set to 1.