Shared/common time (domain) between A7 and M4

[thomas987]

Hi,

I wanted to ask if there is a possibility to have the same time domain on the M4 and A7 cores?

To be a bit more specific: my STM32MP1 board synchronises time over Ethernet using PTP (and that works great!) but now i want to timestamp a digital input pin.

The options i have seen so far are:

• using EXTINT to assign a system timestamp when the interrupt occurs (on the A7) -- this is not accurate because of kernel interrupt handling and software timestamping
• using TIMx and input capture mechanisms (on the M4) -- this would be my preferred way but there i have no information at which time TIMx value is and how to synchronise them with the A7
  • one idea i had was using the PTP_Synchro PPS_OUT [which i still couldn't activate in Cube although i enabled TIM2 as slave with ETR] and correlate input capture values from CC2 with the PPS. but there only the duration from the last PPS to the current input capture is known -- then my idea was to use the RTC values to associate whole seconds but the RTC isn't necessarily in sync with the PTP-PPS
• using TIMx and input capture (on the A7) -- has similar issues to the M4: i can't get a relation between system time and TIMx values

Do you have any ideas/inputs how i could get (preferably) hardware timestamps for digital inputs which are related to the (PTP synchronised) A7 system time?

Best Regards & Thanks a lot

Thomas

[Olivier GALLIEN]

Hi @thomas987​ 

I understand that following old post answer your need :

https://community.st.com/s/question/0D53W00000oXAqhSAG/how-can-i-get-access-to-m4-timers-from-a7-linux-is-it-possible-

Please consider the solution based on STGEN.

Olivier

[thomas987]

Hi @Community member​ ,

thanks for your quick response!

The STGEN is an additional method i haven't thought of, if i understood it correct that would imply that i would have to synchronise:

• A7 linux system time to STGEN -- do you have any hint for me where I get the correspondance between them?
• then i may use an EXTINT and read the STGEN counter upon execution -- which isn't as accurate as it would be using a TIMx input capture but possibly as good as it gets?

I also found the possibility to do "auxiliary timestamping" (p. 3391 in DM00327659, "Auxiliary snapshots with external events") with the ETH/GMAC by using the `eth_ptp_trig` signal -- is there any information on how this signal can be triggered?

Best Regards

Thomas

[PatrickF · Accepted solution]

Hi,

I'm not specialist of PTP nor Timers. I got feedback from experts I tried to summarize below.

From RefMan,

• eth_ptp_trig1 (listed as PTP0) is connected to TIM2 TRGO
• eth_ptp_trig2 (listed as PTP1) is connected to TIM3 TRGO.

I agree spec is not so clear.

TIMx TRGO could be generated by TIMx_ETR input pin when Timer is used in master/slave reset mode:

• MMS = 000: Reset mode
• SMS = 0100: Reset Mode
• TS = 00111: External Trigger input (ETRF).

Alternatively if pin TIMx_ETR is not available, TIMx_CH1 or TIMx_CH2 could be used with either TS = 00101: Filtered Timer Input 1 (TI1FP1) or 00110: Filtered Timer Input 2 (TI2FP2) respectively.

Don't know how the eth_ptp_trig signal could be used in ETH using Linux driver/framework.

In the MAC : ATSEN0=1 (or ATSEN1=1) in ETH_MACACR to enable the auxilairy timestamp inputs, the timestamp itself is in ETH_MACATSNR and ETH_MACATSSR registers.

2 points to consider for assessing timestamp accuracy:

• A delay of 1 to 2 (timer clock) cycles at TIMx_ETR input, due the resynchronization logic : static error can be compensated by removing one ck-tim period, but an average on consecutive timestamps (if they are periodic) is necessary to reduce the uncertainty due to the jitter
• A delay of 1 (timer clock) cycles, for the signal to be propagated from TRGI input to TRGO output

So a total delay of 2 to 3 cycles between the external signal and the timestamping (from the top of my head; I may be off by 1 cycle, let us know if you need cycle accurate values).

Another option would be to use the reset on capture mode in the timer: in this case, the external timestamp signal must be connected to the TIMx_CH1 or TIMx_CH2 input and the trigger selection set to 00101 or 00110. The timestamping on the MAC will behave identically, but the interest here is that it is possible to read simultaneously the interval between two timestamp, in the timer clock domain, in the TIMx_CCR1/2 capture registers. If the PTP time is very precise, this allows the application to measure precisely the MP1 timer clock, and to compensate a local crystal inaccuracy or drift.

Alternatively, as you propose, using PPS to trig TIM2 and get rough absolute time using STGEN (or RTC) might be ok.

It depend on the precision your are seeking (and the effort to setup a working solution).

Regards,

[thomas987]

Thanks for this amazing answer!

The required precision for the first prototype won't be that hard to reach i guess (talking about <~1µs), but in a later stage <100ns would be desirable.

The proposed setup with (reset on capture) + (TRGO on reset) sounds like a great idea -- then it also should allow both, timestamping in PTP domain and measuring TIMx clock drift.

Thanks again for pointing me to Table 99, also clarifying the connection between PTP & FDCAN.

Best Regards

Thomas

[PatrickF]

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question.

See also 'Best Answers'