• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 256 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

MCU-PLUS-SDK-AM243X: LWIP CPSW Example - How to read Timestamp after DP83869 trigger?

MCU-PLUS-SDK-AM243X: Question on CPSW CPTS for Ethernet Tx/Rx Timestamps

Keito Katafuchi
Intellectual 255 points
Part Number: MCU-PLUS-SDK-AM243X

I am reading through the TRM and trying to understand how to manage Tx/Rx timestamps with the CPTS module.

It looks like for an Ethernet Tx/Rx triggered CPTS Timestamp to pass to the Event FIFO (to be read by SW),
the Ethernet packet needs to be a valid TimeSync packet, as defined by criteria in:

12.2.1.4.7.13.5.1 Ethernet Port Receive Event
12.2.1.4.7.13.5.2 Ethernet Port Transmit Event

"The CPTS hardware will decode each packet to determine if it is a valid CPTS time sync event..."
"...Once a transmitted or received packet is determined to be a valid time sync packet, the Ethernet Transmit Event or Ethernet Receive Event is loaded onto the Event FIFO."

I was hoping the CPTS timestamp capability wouldn't be limited to TimeSync packets...is it possible to change the packet types that trigger the CPTS capture?
I noticed the following...

12.2.1.4.7.15 Host Transmit Event

The host can send a packet to be transmitted on an Ethernet port that will generate a time synchronization event. The host sets the TSTAMP_EN bit and sends the DOMAIN, MESSAGE_TYPE, and SEQUENCE_ID in the additional control information that resides in the protocol specific section of the descriptor that is transmitted to the CPSW_3G. An event is then generated and placed on the event FIFO once the packet is transmitted. Host events allow the user to timestamp exactly when a software generated packet exits the device.

  • 0
    TI__Mastermind 26140 points

    Hi 

    Thanks for your query.

    I will check on this and get back to you.

    Regards

    Ashwani

  • 0 in reply to Ashwani Goel
    TI__Mastermind 26140 points

    Hi ,

    Currently In our SDK example we have timeSyncMsgType only for CPSW-CPTS timestamp

    Can you please help with the use case you are working on ?

    Regards

    Ashwani

  • 0 in reply to Ashwani Goel
    Intellectual 255 points

    Hi Ashwani,

    Use case is to track the packet latency from master->slave where the medium changes.
    (ethernet packet leaves the master, gets converted to a different medium and back, finally ending up at the receiver)

    I'm currently looking at the lld_gptpnet.c source file in the SDK.
    The "process_txts()" function has "LLDTSyncGetTxTime()" and this updates &ts with the Tx timestamp.
    This is documented in the AM64x MCU SDK, but not the AM243x SDK?

    I noticed for the Rx timestamp, which is LLDPSyncGetRxTime(), that there is also a way to get the Rx timestamp.

    But what I'm not able to figure out, is if the limitation on "CPTS only capturing PTP Ethernet Packets" is because the driver filters out timestamps, or if that filtering is done by CPTS hardware?

    Specifically, line#445 in lld_gptpnet.c states if the EtherType isn't 0x88F7 (PTPv2 packet), then don't process the Rx timestamp.
    But I'm led to believe the CPTS is then capturing timestamps for all Ethernet packets, and it is the driver doing the filtering...?

    Fullscreen
    1
    2
    /* Do not handle non PTP packets */
    if(ntohs(*(uint16_t *)(buf + 12))!=ETH_P_1588){...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    EDIT: Sorry, I see what you mean. The driver takes msgType and uses this to decide which TImeSync packets to process.
    But does that mean the hardware is limited to TimeSync packets only, or it is only limited because of how the driver behaves?

  • +1 in reply to Keito Katafuchi
    TI__Mastermind 26140 points
    Keito Katafuchi said:
    But does that mean the hardware is limited to TimeSync packets only

    I have added HW expert to answer this question.

    Keito Katafuchi said:
    Use case is to track the packet latency from master->slave

    Can you not use gPTP packets for this purpose ?

    Enabling CPTS for other types of frames involved much SW effort.

    We do not have a valid business justification for this change.

    Regards

    Ashwani

  • 0 in reply to Ashwani Goel
    Intellectual 255 points

    Hi Ashwani,

    Understood. So, does CPTS module (hardware) allow triggering on Ethernet packets besides EtherType=0x88F7?
    (the TRM actually seems to indicate EtherType=0x0800 packets trigger it? Looking at Annex D on P7016)

  • 0 in reply to Keito Katafuchi
    TI__Mastermind 26140 points

    Hi ,

    Thanks for having patience.

    Working with HW expert on this to get back to you.

    Regards

    Ashwani