TJA1103 HW timestamp issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

TJA1103 HW timestamp issue

Jump to solution
344 Views
FabioDb
Contributor I

I am working with an MR-CANHUBK334 where I integratd a gPTP stack configured to take the timestamp from the HW timestamp module of the TJA1103. That node is configutred as Gran Master. My problem is that sometimes the timestamp acquired on the ingress/egress ring buffers is not consistent with the LTC timer used by the PHY as a reference for the timestamp. Specifically, the time read from the top buffer, each time a message is received, sometimes goes back in time and then continues counting from that moment onwards, but the LTC remains always correct.
This happens arbitrarily and without any kind of fixed pattern. Has anyone else encountered this problem?

0 Kudos
Reply
1 Solution
308 Views
PavelL
NXP Employee
NXP Employee

Hello @FabioDb ,

Your issue is very specific. If the LTC remains stable and correct, but the timestamps retrieved from the FIFO or ring buffer occasionally jump backwards in time, the issue is likely not in the LTC itself, but in the timestamp acquisition or interpretation path.

Could you share all TJA1103's registry settings (relate to PPS) that you have done?

I forwarded your issue to the application team for further investigation. I will keep you updated on any progress.

In the meantime, please kindly review general hints:

 

  • Log both the timestamp and LTC value at the moment of frame reception. This will help determine whether the inconsistency is due to FIFO corruption, misalignment, or software interpretation.
  • Check for link status changes or PHY resets. Timestamp FIFO may contain stale or invalid entries if the PHY experiences a brief reset or link renegotiation.
  • Validate the timestamp reading logic in your driver or HAL. Ensure correct endian handling, bit shifts, and that the timestamp is read only after it is fully latched.
  • Monitor FIFO overflow or underrun conditions. If the timestamp FIFO is not drained fast enough, older entries may be overwritten or misaligned.
  • Confirm that PPS_SYNC signals from S32K344 are stable and correctly aligned with the LTC update cycle in the PHY. Any jitter or misalignment could cause timestamp inconsistencies.
  • Ensure the gPTP stack properly handles timestamp offsets and does not apply incorrect corrections based on assumptions about PHY behavior.

 

Best regards,

Pavel

View solution in original post

0 Kudos
Reply
1 Reply
309 Views
PavelL
NXP Employee
NXP Employee

Hello @FabioDb ,

Your issue is very specific. If the LTC remains stable and correct, but the timestamps retrieved from the FIFO or ring buffer occasionally jump backwards in time, the issue is likely not in the LTC itself, but in the timestamp acquisition or interpretation path.

Could you share all TJA1103's registry settings (relate to PPS) that you have done?

I forwarded your issue to the application team for further investigation. I will keep you updated on any progress.

In the meantime, please kindly review general hints:

 

  • Log both the timestamp and LTC value at the moment of frame reception. This will help determine whether the inconsistency is due to FIFO corruption, misalignment, or software interpretation.
  • Check for link status changes or PHY resets. Timestamp FIFO may contain stale or invalid entries if the PHY experiences a brief reset or link renegotiation.
  • Validate the timestamp reading logic in your driver or HAL. Ensure correct endian handling, bit shifts, and that the timestamp is read only after it is fully latched.
  • Monitor FIFO overflow or underrun conditions. If the timestamp FIFO is not drained fast enough, older entries may be overwritten or misaligned.
  • Confirm that PPS_SYNC signals from S32K344 are stable and correctly aligned with the LTC update cycle in the PHY. Any jitter or misalignment could cause timestamp inconsistencies.
  • Ensure the gPTP stack properly handles timestamp offsets and does not apply incorrect corrections based on assumptions about PHY behavior.

 

Best regards,

Pavel

0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2185806%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ETJA1103%20HW%20timestamp%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2185806%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EI%20am%20working%20with%20an%20MR-CANHUBK334%20where%20I%20integratd%20a%20gPTP%20stack%20configured%20to%20take%20the%20timestamp%20from%20the%20HW%20timestamp%20module%20of%20the%20TJA1103.%20That%20node%20is%20configutred%20as%20Gran%20Master.%20My%20problem%20is%20that%20sometimes%20the%20timestamp%20acquired%20on%20the%20ingress%2Fegress%20ring%20buffers%20is%20not%20consistent%20with%20the%20LTC%20timer%20used%20by%20the%20PHY%20as%20a%20reference%20for%20the%20timestamp.%20Specifically%2C%20the%20time%20read%20from%20the%20top%20buffer%2C%20each%20time%20a%20message%20is%20received%2C%20sometimes%20goes%20back%20in%20time%20and%20then%20continues%20counting%20from%20that%20moment%20onwards%2C%20but%20the%20LTC%20remains%20always%20correct.%3CBR%20%2F%3EThis%20happens%20arbitrarily%20and%20without%20any%20kind%20of%20fixed%20pattern.%20Has%20anyone%20else%20encountered%20this%20problem%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2186473%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20TJA1103%20HW%20timestamp%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2186473%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHello%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F252303%22%20target%3D%22_blank%22%3E%40FabioDb%3C%2FA%3E%26nbsp%3B%2C%3C%2FP%3E%0A%3CP%3EYour%20issue%20is%20very%20specific.%26nbsp%3BIf%20the%20LTC%20remains%20stable%20and%20correct%2C%20but%20the%20timestamps%20retrieved%20from%20the%20FIFO%20or%20ring%20buffer%20occasionally%20jump%20backwards%20in%20time%2C%20the%20issue%20is%20likely%20not%20in%20the%20LTC%20itself%2C%20but%20in%20the%20timestamp%20acquisition%20or%20interpretation%20path.%3C%2FP%3E%0A%3CP%3ECould%20you%20share%20all%20TJA1103's%20registry%20settings%20(relate%20to%20PPS)%20that%20you%20have%20done%3F%3C%2FP%3E%0A%3CP%3EI%20forwarded%20your%20issue%20to%20the%20application%20team%26nbsp%3Bfor%20further%20investigation.%20I%20will%20keep%20you%20updated%20on%20any%20progress.%3C%2FP%3E%0A%3CP%3EIn%20the%20meantime%2C%20please%20kindly%20review%20general%20hints%3A%3C%2FP%3E%0A%3CBR%20%2F%3E%0A%3CUL%3E%0A%3CLI%3ELog%20both%20the%20timestamp%20and%20LTC%20value%20at%20the%20moment%20of%20frame%20reception.%20This%20will%20help%20determine%20whether%20the%20inconsistency%20is%20due%20to%20FIFO%20corruption%2C%20misalignment%2C%20or%20software%20interpretation.%3C%2FLI%3E%0A%3CLI%3ECheck%20for%20link%20status%20changes%20or%20PHY%20resets.%20Timestamp%20FIFO%20may%20contain%20stale%20or%20invalid%20entries%20if%20the%20PHY%20experiences%20a%20brief%20reset%20or%20link%20renegotiation.%3C%2FLI%3E%0A%3CLI%3EValidate%20the%20timestamp%20reading%20logic%20in%20your%20driver%20or%20HAL.%20Ensure%20correct%20endian%20handling%2C%20bit%20shifts%2C%20and%20that%20the%20timestamp%20is%20read%20only%20after%20it%20is%20fully%20latched.%3C%2FLI%3E%0A%3CLI%3EMonitor%20FIFO%20overflow%20or%20underrun%20conditions.%20If%20the%20timestamp%20FIFO%20is%20not%20drained%20fast%20enough%2C%20older%20entries%20may%20be%20overwritten%20or%20misaligned.%3C%2FLI%3E%0A%3CLI%3EConfirm%20that%20PPS_SYNC%20signals%20from%20S32K344%20are%20stable%20and%20correctly%20aligned%20with%20the%20LTC%20update%20cycle%20in%20the%20PHY.%20Any%20jitter%20or%20misalignment%20could%20cause%20timestamp%20inconsistencies.%3C%2FLI%3E%0A%3CLI%3EEnsure%20the%20gPTP%20stack%20properly%20handles%20timestamp%20offsets%20and%20does%20not%20apply%20incorrect%20corrections%20based%20on%20assumptions%20about%20PHY%20behavior.%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CBR%20%2F%3E%0A%3CP%3EBest%20regards%2C%3C%2FP%3E%0A%3CP%3EPavel%3C%2FP%3E%3C%2FLINGO-BODY%3E