• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 902 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.

Use of XINTnCTR on F2803x

Angelo Caruso68686
Intellectual 395 points

Hi,

Can anyone point me to an example of how to actually use the XINTnCTR to accurately time stamp a GPIO edge?  According to the description in SPRUGL8B, the counter is reset to zero when a qualifying edge is detected.  How then, can one actually snapshot the value of the counter before it gets reset???

Thanks,

Angelo

  • 0
    TI__Guru 62975 points

    Angelo,

    The XINTnCTR register is a read-only counter that is useful for determining how far into the past the interrupt was triggered.  The register can be read while servicing the XINT interrupt.

    ECAP may be a useful option for time stamping between events.

    -Tommy

  • 0 in reply to tlee
    Intellectual 395 points

    Tommy,

    Thanks for verifying that.  I agree that eCAP is a much better way to do what I need, but I am trying to find a firmware-only solution at this point and the GPIOs I am interested in are not presently connected to eCAP inputs.  I am planning to snapshot a free running CPU timer from the XINT ISR, and hopefully this will provide sufficient resolution and accuracy for the application.   Sounds like I can use the XINTnCTR to account for interrupt handling latency, if I need more accuracy.  Worst case scenario, we will simply reconnect the signals to eCAP inputs.

    Regards,

    Angelo

  • 0 in reply to Angelo Caruso68686
    Mastermind 7585 points

    Angelo,

    I have attached one of my student labs. The Lab uses GPIO2 as external interrupt source (falling edge), the ISR will copy the XINTCTR to "counter". The value in counter is usually a number between 18 and 22 (clock cycles) . 14 clocks caused by hardware context save and the rest by the first assembly instructions at the beginning of the ISR, before the copy instruction.

    Regards

     

     

    28035_Lab1_4.pdf
  • 0 in reply to Frank Bormann
    Intellectual 395 points

    Frank,

    Thank you.  A very well written lab - simple, and to the point.

    Regards,

    Angelo

  • 0 in reply to Frank Bormann
    Expert 1685 points

    Please help me understand the counter value. The XINT1CTR increments at SYSCLKOUT rate, which was 60MHz in your case. Was the perid between XINT1 events only 18-22 clocks (0.3 usec - 0.36 usec) or the counter has overflown?

    Maybe understanding this way, the XINT1CTR has been reset to zero when the event occurs, the counter value records only the delay from the event and the reading of XINT1CTR. If this is true, the CTR is useless.

    Thank you very much!

  • 0 in reply to Louis Zhu
    Mastermind 7585 points

    Please help me understand the counter value. The XINT1CTR increments at SYSCLKOUT rate, which was 60MHz in your case. Was the perid between XINT1 events only 18-22 clocks (0.3 usec - 0.36 usec) or the counter has overflown?

    Answer: No, the counter has not overflown, the time delay is 18-22 clocks.

    Maybe understanding this way, the XINT1CTR has been reset to zero when the event occurs, the counter value records only the delay from the event and the reading of XINT1CTR. If this is true, the CTR is useless.

    Answer: Yes, the counter records the time delay between the hardware signal and the time, when you start prcessing the corresponding interrupt code. CTR is not useless at all, because it gives you the 'age' of an interrupt signal. If you have to process multiple different interrupt sources, CTR can become very helpful..