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.

TMS320F28335: eCAN Time Stamp Precision?

Part Number: TMS320F28335


I'm thinking about (high precision) synchronizing some DSPs (28335) via CAN. I saw the timestamp feature of the eCAN "Timer Management Unit". But I'm wondering how accurate these are, with regards to these comments of the "eCAN Reference Guide" (SPRUEU1), which tells

  • CANTSC: This is a free-running 32-bit timer which is clocked by the bit clock of the CAN bus. For example, at a bit rate of 1 Mbps, CANTSC would increment every 1 µs.
  • ..
  • This state machine has lower priority when accessing the registers than the CAN state machine has. Therefore, the time-control functions may be delayed by other ongoing actions..
  • ...
  • MOTS: This register holds the value of the TSC when the corresponding mailbox data was successfully
    transmitted or received.
  • ...
  • The TSC register can also be cleared when mailbox 16 transmitted or received

It's clear, that the resolution of the CANTSC and MOTS is 1 µs/bit (for 1 Mbit/s CAN bus), but my questions are:

  1. How accurate is CANTSC incremented, if it might be delayed by "other actions" (Jitter of wrap around)? 
  2. For transmission: When exactly is the MOTS freezed? (after successfull bus arbitration? after sending the final CRC or END bits?)
  3. For reception: When exactly is the MOTS freezed? (after MBX filter succeeded? When all bytes are copied? after final CRC or END bits?

It would be nice if anybody could share some experience about this. Thx in advance!

Ralf

  • Ralf,

                    This module is almost 25 years old now, so we do not have a whole lot of design analysis capability.

    How accurate is CANTSC incremented, if it might be delayed by "other actions" (Jitter of wrap around)? 

    This is a 32-bit counter. So, even at 1 us bit-clock, it takes about 4295 seconds to overflow.

    For transmission: When exactly is the MOTS freezed? (after successfull bus arbitration? after sending the final CRC or END bits?)

    I think it should be the ACK delimiter.

    For reception: When exactly is the MOTS freezed? (after MBX filter succeeded? When all bytes are copied? after final CRC or END bits?

    When all bytes are copied in the mailbox.

  • Thank you for your support of this old device - but it still is a powerfull machine. Perhaps my question also applies to other (newer) CPUs using the same eCAN core?

    RX and TX MOTS time stamp now is clear, thanks!

    For the TSC my question (1) perhaps was to unprecise: I'm wondering about the phrase ".. delayed by other actions.". I assume, the TSC assures to count each CAN bus bit clock (no clock missed), but:

    • What kind of delay is meant here?
      • Is the TSC counter increment delayed?
      • Or is the copy routine to MOTS delayed?
      • Or something else - irrelevant for the TSC and MOTS usage?
    • And which amount of delay may be expected here in worst case?
      • Some CPU or peripheral clock cycles only?
      • Or some CAN bus clock single microseconds?
      • Or much more? (e.g. suspended by a longer DMA transfer?)

    Sorry for these additional questions. I just want to get a feel for what order of magnitude the accuracy of synchronizing two DSPs would be, if I use this eCAN time stamp feature.

  • Thank you for your support of this old device - but it still is a powerfull machine.

    Just to clarify: This device was released to production 15 years ago. However, the eCAN module itself is about 25 years old. 

    Perhaps my question also applies to other (newer) CPUs using the same eCAN core?

    Our newer devices don't use eCAN anymore. They use DCAN, which is not code-compatible with eCAN. The last device to feature eCAN was released to production 10 years ago.

    I assume, the TSC assures to count each CAN bus bit clock (no clock missed)

    Yes.

    Or is the copy routine to MOTS delayed?

    I am pretty sure this is what gets delayed. Again, as mentioned in my first post, we don't have design analysis capability for this module, so I am unable to confirm this for sure.

    Some CPU or peripheral clock cycles only?

    It should be the above. Incrementing TSC can happen independent of everything. Even at 1 Mbps, one bit clock (1 us) equates to 30 CPU clock cycles (at 33.33ns). Updating the MOTS register should take no more than a few CPU cycles.