• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 328 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.

LP-MSPM0L2228: Can Current Counter Value on TIMGx Be Read Reliably?

Larry Frederickson
Prodigy 20 points
Part Number: LP-MSPM0L2228

Tool/software:

Can the timer count register for TIMGx be read reliably while the counter is running? We often use a free-running timer for timestamps. Some timers on some MCUs do not support reading the current counter value while the timer is running.

  • 0
    TI__Genius 16000 points

    There will always be some inaccuracy as it does take some time for the CPU to read out the counter value. Depending on the accuracy you need for your application, I would not necessarily say it is unreliable, just know that there will inherently be less accuracy and the value in the counter register is likely not the same as the value that you read out with the CPU by the time it is visible, unless you are using an incredibly slow input to the counter. 

  • 0 in reply to Dylan OBrien
    Prodigy 20 points

    To clarify my concern: Some MCUs do not support reading the current timer value. The read of the timer counter value is an unbuffered, unsynchronized read of the underlying counter which in some cases is a ripple counter. In such a case, the unbuffered, unsynchronized read can return senseless values if the read occurs during a transition. This was the case of the LPIT on the S32K14x family of MCUs. My question might be better asked as: Is the read of the current counter value a buffered and/or synchronized read such that no counter transition will be read?

  • 0 in reply to Larry Frederickson
    TI__Genius 16000 points

    Understood. I have read out the timer in software before and I do not get senseless values, but I am not sure that they are buffered. I can say for certain that the counter value will continue to move forward while the read is processing so the value returned by a read does not necessarily represent the exact value in the counter register. I've just pinged our design team to check if the register is buffered, please allow a few days for a response on this question. Thanks

  • 0 in reply to Larry Frederickson
    Guru 42085 points

    The typical workaround for that is just to read it twice. If the values agree, you are good. If they don't, read it again.

  • 0 in reply to Dylan OBrien
    Prodigy 20 points

    Thanks for the feedback and pinging the design team. I ran a simple test I've used before to capture anomalous readings due to capturing counter transitions. The test caught no odd readings. That empirical evidence gives me some confidence. Be nice to get a definitive statement from the Design team.

  • 0 in reply to Keith Barkley
    Prodigy 20 points

    That's a possible fallback solution. It'll be good to hear from the Design team to know if that's necessary. The empirical evidence so far suggests it is not needed.

  • 0 in reply to Larry Frederickson
    TI__Genius 16000 points

    I've been able to get some information from the team:

    The timer CTR register is not buffered, so the register you read using that function is the same register connected to the control logic. 

    I have also not seen complete junk values when reading the register out, but I can say there will be some clock cycles difference between the CTR value and the one that is read out by the CPU. Keep this in mind and consider using Keith's suggestion moving forward with your design.

  • 0 in reply to Dylan OBrien
    Prodigy 20 points

    There must be some type of synchronization with the control logic to prevent the logic from seeing timer transitions. Otherwise there would be false compares, the logic just wouldn't work well. Thanks for your help. I'm good for now.