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

MSP430FR5964: Where in the EUSCI interrupt cycle is UCTXIFG cleared?

Andrew McLaren
Intellectual 580 points
Part Number: MSP430FR5964


The EUSCI users guide for the FR5xx processors has a bit of an inconsistency regarding the clearing of the UCTXIFG flag.

Section 30.4.7 describing the UCAxTXBUF includes the following;

Writing to the transmit data buffer clears UCTXIFG

This is what I expected, but it's not the behaviour I'm seeing. However in an earlier section, 30.3.15.4 on the UCAxIV Interrupt Vector Generator, it includes the following;

Read access of the UCAxIV register automatically resets the highest pending interrupt and flag

This matches the behaviour I am seeing. A TX interrupt is raised, and once the handler reads the IV to determine the interrupt, the TXIFG is cleared.

I'm in the process of porting some code from the older USCI, and from what I can see reading that user guide, writing the TXBUF was the only mechanism to clear the TXIFG. The logic is erroneously assuming the TXBUF is not in a state to be written because the TXIFG is clear. Could someone confirm that what I am seeing is the way things are supposed to work - that the TXIFG is cleared immediately the IV is accessed.

Either way, the documentation should be tweaked to be clearer. I assume that writing TXBUF will still ensure the TXIFG is cleared, but if operating in an interrupt model, that will have already been done when accessing the IV.

Thanks and regards - Andrew

  • 0
    Intellectual 580 points

    After a bit more playing, I'm pretty sure the scenario above is what is happening - the read of the IV register is clearing the TXIFG flag, and effectively disconnecting it from the write of the TXBUF.

    I did find another thread in this forum which recommended using the IFG register to decode the interrupt, rather than the IV directly, specifically to avoid this disconnect. That makes sense, and its a trivial change. I can't see any other implications to doing this?

    Andrew

  • 0 in reply to Andrew McLaren
    Guru 100865 points

    I don't use the IV for the xUSCI (UART or SPI), since TXIFG is a rather precious piece of state, so it needs to be stored -- if not in the IFG register then somewhere else.

    I clear RXIFG/TXIFG only by reading/writing RXBUF/TXBUF, and if I run out of things to send I clear TXIE.

    Other people use variations of this, but they all entail saving (explicitly or implicitly) the TXIFG value somewhere.

  • 0 in reply to Andrew McLaren
    TI__Mastermind 39895 points

    Hi Andrew,

    Thank you for making detailed test and explanation. Actually, I use the IFG register to decode the interrupt, just following the example code. I haven't see any colleague or customer to use UCAxIV to check the interrupt source.

    Eason

  • 0 in reply to Eason Zhou
    Intellectual 580 points

    Thanks for the comments. I've always treated the IFG and IV registers  as pretty interchangeable (for decoding the interrupts), but this definitely makes it much more sensible to use the IFG. Having the TXIFG effectively disconnected from the state of the TXBUF is definitely not optimal. I assume they had a good reason for doing this!

    Interestingly the eUSCI users guide I have in front of me (revised April 2020), uses the IV in its example of decoding the interrupt.

    I've tweaked the code to use the IFG, and its instantly behaving.

    Thanks again, and I'll close this

    Andrew

**Attention** This is a public forum