• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 839 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.

TM4C129XNCZAD: EMACTIMSTCTRL.TSUPDT update limited range

Leo Bredehoft58
Expert 1260 points
Part Number: TM4C129XNCZAD

Use of EMACTimestampSysTimeUpdate() to add/subtract an offset to/from the hardware timestamp registers appears to be limited in the range over which it operates without EMAC interface failure.  If

1) adding,      the update seen as a 64-bit number is more than 0x00000000001fffffll, or
2) subtracting, the update seen as a 64-bit number is more than 0x001fffffffffffffll,

the update operation causes the EMAC interface to lock up.

If it this information is helpful, EMACTimestampSysTimeSet() shows lock-up sensitivity for arguments greater than 0x3fffffffffffffffll.

Proper function of EMACTimestampSysTimeUpdate() is essential to this design, so I'm looking for a workaround.  Specifically, I would like to know if there is some sort of interdependency between timestamp update and the EMAC hardware itself.  Perhaps the EMAC needs to be momentarily frozen when the timestamp is being updated?  Are there known bugs in the timestamp logic?

For the record, here is the update code:

            uint64_t t = ...

            EMACTimestampSysTimeUpdate(
              EMAC0_BASE,
              (uint32_t)(t >> 31),
              (uint32_t)(t & EMAC_TIMNANO_TSSS_M),
              false // t: subtract, f: add
            );

  • 0
    TI__Guru 72500 points
    Hi Leo,
    Unfortunately the EMAC is the peripheral I know the least about and Charles is out of the office today. I will ask him to help me on your question when he returns tomorrow. In the meantime, did you use EMAC_TS_DIGITAL_ROLLOVER, or EMAC_TS_BINARY_ROLLOVER in your call to EMACTimestampConfigSet()?
  • 0 in reply to Bob Crosby
    Expert 1260 points
    Hi Bob:

    Thanks for the quick response! I use EMAC_TS_BINARY_ROLLOVER.

    Best Regards,
    Leo
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points

    I modified my application to avoid update for the empirically-determined ranges mentioned above.  When the adjustment is out of range, I do a direct write of the timestamp using EMACTimestampSysTimeSet().  This coarse adjustment reduces the error to the point where successive updates may be performed using EMACTimestampSysTimeUpdate().  My application should be able to tolerate this kind of operation.  We will see.

  • 0 in reply to Leo Bredehoft58
    Expert 1260 points

    The problem described above may be due to a false assumption on my part.  Ideally, my system would produce raw hardware timestamps as a binary 63-bit count in one-nanosecond units.  Accordingly, I called EMACTimestampConfigSet() with arguments of 40 ns and EMAC_TS_BINARY_ROLLOVER.  On looking closer in the TM4C129XNCZAD datasheet, however, I see that the description for EMACSUBSECINC.SSINC does not offer that alternative.  In binary mode, only a resolution of "~0.465ns" is described in binary mode.

    I'm assuming here that, in the proscribed binary mode, 0.465 ~= 40/86 = 0.465116279069767441860...  Guessing past the datasheet to a reasonable logic implementation on the chip, it looks like timestamp increments from EMACSUBSECINC.SSINC happen once every 40 ns.  For a reason not obvious to me, the remainder of the EMAC timestamp unit expects ~0.465ns resolution for proper operation.

    This is undesirable in my application because of the required 64-bit division by 86 and multiplication by 40 to accurately convert these timestamps into binary nanoseconds.  Timestamps captured by DMA at a rate of 250 KHz must be converted into nanoseconds, amounting to a significant processor load.  I also have the requirements to adjust the timestamp to synchronize with a master timebase and generate a PPS output which is a copy of bit 19 of a binary count of 40-nanosecond intervals in that timebase.  If the update hardware works, as it might be doing with the workaround above, the synchronization requirement should be achievable, and if the PPS hardware works properly, then, after each synchronization adjustment, I should be able to calculate the instant at which the PPS train should restart, then set the PPS hardware appropriately.  In the current scheme, I don't see PPS synchronization requests synchronizing PPS as required.

    If a solution where EMACSUBSECINC.SSINC=40 is not possible in binary mode, I can envision two possible approaches to address requirements and hardware constraints:

    1) Set EMACSUBSECINC.SSINC to 1 in binary mode, and perform timestamp conversions by multiplying by 40.  This multiplication can be done with two shifts and an add: x*40 = (x+(x<<2))<<3, which is cheap in 64-bit math.  PPS target computation is simple also.  This undocumented alternative is the least computationally expensive of the two.

    2) Set EMACSUBSECINC.SSINC to 40 in digital mode, and perform timestamp conversions by 32-bit multiplication and 64-bit addition to splice the two 32-bit pieces of the timestamp into a binary result.  PPS target computation would be more complex, but doable.  This documented alternative is more expensive, but at least the datasheet indicates that it should work.

    Will alternative 1 work?

    Thanks,

    Leo