• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 458 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM6442: MCAN timestamp counter, external timestamp counter, cross-timestamping support

Dominic Rath
Mastermind 7410 points
Part Number: AM6442

Dear TI team,

we're looking for ways to implement synchronization over CAN networks.

CANopen for example has a "SYNC" object that would allow multiple nodes to be synchronized relative to that SYNC message. There are of course limits to the precision because CAN nodes don't "know" about the cable transmission delays but instead rely on compensating that with slower baud rates at larger distances, but we need to at least aim for something that is "as good as possible".

According to the TRM, the MCAN controller in the AM64x supports timestamping of messages, either using an internal timestamp counter that is clocked at a multiple (1-16) of the CAN bit rate or using an "external" timestamp counter, where "external" appears to mean "external to the MCAN IP re-used in the AM64x". On the AM64x the TRM explains that this "external timestamp counter" is clocked by ICLK (MAIN_SYSCLK0 / 4) divided by a 24-bit prescaler.

Unfortunately I couldn't find any means to generate cross-timestamps between either the MCAN's internal timestamp counter or the external timestamp counter and any of the other "timesync" hardware in the AM64x.

Is there any way to correlate the MCAN timestamp with e.g. one of the CPTS instances or the GTC, apart from "software" synchronization, where I read both the MCAN timestamp counter and "the other" timestamp "close enough" to each other?

Regards,

Dominic

  • 0
    TI__Guru**** 188619 points

    Hello Dominic, 

    Thank you for the query.

    Let me review the inputs and comeback.

    Any thoughts if a similar implementation been done previously using any of the TI processors.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Mastermind 7410 points

    Hello Sreenivasa,

    Kallikuppa Sreenivasa said:
    Any thoughts if a similar implementation been done previously using any of the TI processors.

    I don't think previous TI processors had as much time sync infrastructure as the AM6/K3 line. From what I've seen e.g. the AM5x had a CPTS integrated into the CPSW, but nothing at SoC level.

    The AM6x is already very good in that regard and ahead of competitor solutions that seem to neglect the need for SoC level time synchronization (so far), but there are several areas that were probably overlooked, e.g. MCAN. With regard to CAN one could argue that there's less of a need, since CAN is by itself "slower" and is never going to achieve the <100ns synch that the AM6x offers in other subsystems, but even there every bit that works "in hardware" helps improve accuracy.

    It would of course be great if you found that I simply missed some way, which is why I'm asking here.

    Regards,

    Dominic

  • +1 in reply to Dominic Rath
    TI__Mastermind 27050 points

    Dominic,

    Unfortunately we did not tie in the MCAN counter to the general time sync architecture and time sync router, looking back this would have made sense. Trying to come up with an alternative could you use MAIN_SYSCLK0 for both the CPTS/GTC/IEP and the MCAN to cover the rate synchronization part. Then just a some amount of reads of both counters to narrow down the offset?

      Pekka

  • 0 in reply to Pekka Varis
    Mastermind 7410 points

    Hello Pekka,

    thanks for you reply. Yeah, having the same clock source for the "rest of timesync" and the MCAN timestamp makes sense. Determining the offset is then up to software.

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    TI__Guru**** 188619 points

    Hello Domnic, 

    Thank you for the inputs and noted.

    Regards,

    Sreenivasa