2021-06-17 05:34 AM
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:
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
Solved! Go to Solution.
2021-06-18 07:58 AM
Hi,
I'm not specialist of PTP nor Timers. I got feedback from experts I tried to summarize below.
From RefMan,
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:
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:
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,
2021-06-17 05:46 AM
Hi @thomas987
I understand that following old post answer your need :
Please consider the solution based on STGEN.
Olivier
2021-06-17 08:40 AM
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:
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
2021-06-18 07:58 AM
Hi,
I'm not specialist of PTP nor Timers. I got feedback from experts I tried to summarize below.
From RefMan,
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:
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:
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,
2021-06-18 08:18 AM
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
2021-06-18 09:21 AM
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'