Please provide the following info (tick the boxes after creating this topic):
DRIVE OS 22.214.171.124
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
Target Operating System
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
SDK Manager Version
Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
This is my understanding of how the timing mechanisims on the AGX work when PTP is enabled (and please correct me where I am wrong or misunderstand anything)
- TSC clock kicks off 7 seconds before kernel is loaded and runs at 31.25 Mhz - which I believe is a resolution of 32 ns per tick.
- Kernel loads, eventually NVPPS module syncs the frequency (syntonize - very important distinction I have found - might want to clarify that in your documents) to the PTP hardware clock of the client interface (usually mgbe0_2)
This is where things get fuzzy - I think that ioctl calls to nvpps using NVPPS_GETEVENT still indicate that the tsc resolution is 32 ns - but if there is sycning with the PTP clock - would that not change? (I can also double check this later).
Now - the fsync generators can either be configured to be programmed at a point in the future in TSC ticks or they start up at sometime in the boot sequence if prgramming is not selected.
If the fsync generators are not configured to be programmed - at what point in the boot sequence do they start when PTP is enabled? Are they at all coordinated with say top of a second as well - are there any kind of guarantess as to when they start - or is just right after something happens in the boot sequence?
If PTP and TSC are locked, but there is a constant drift getting corrected by whatever code obeys this parameter:
PTP_TSC sync LOCK_THRESHOLD - how would a person go about determining the time in the future to program the fsync to start in ticks. As I have pointed out in another thread here - my approach is to compute the average PTP-TSC offset using NVPPS_GETEVENT calls. Then, pick a time in the future and:
Convert to ns since epoch
Subtract PTP-TSC offset
Divide by 32 ns per tick
Use the program_fsync_start_time() call.
Aside from trying to clarify the highlevel view of how these things fit together, my other question is how would a person get the fsync generator across 2 ECUs to be in phase? Right now - telling each ECU the time in the future you want it to start and having them convert the time to TSC ticks individually (because TSC-PTP offset depends on boot time of device) is the only method I see.