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.

Manual modification of USCI interrupt flags

Other Parts Discussed in Thread: MSP430F5528

This is a general question about USCI modules in MSP430s, but I am working with the MSP430F5528.

After receiving junk data (e.g. from a SPI transfer), I have always cleared the UCRXIFG flag by performing a dummy read of the UCAxRXBUF register, instead of manually resetting the flag with an instruction like "UCAxIFG &= ~UCRXIFG". Someone questioned me about this and I went looking in the user's guide for a note about not manually modifying the USCI interrupt flags. However, I could not find anything about this in the user's guide or after several google searches.

Is it safe to write to the UCAxIFG register (i.e. writing to the register won't prevent the hardware from updating it correctly)? Does anyone remember seeing a note from TI about this? Performing a dummy read seems to be the more common way to clear UCRXIFG. Why?

Thanks,
Austin

  • more of all MSP430 interrupts flag are cleared automatically,
    why, because user mustn't do that alone and he has less work to do :)

    if somebody use uart, usually he want read incoming data :)
    if you want test hypothetical situation you can clear RX interrupt flag manually, in my opinion msp will be working correctly,

    acces into UCAxIFG register isn't forbidden,
    many times when I worked with uart I set manually TX interrupt flag, this operations triggered TX interrupt routine, and I could send data using interrupts
    it worked like a dream,

  • It's perfectly fine to directly clear or set the MSPs IFG flags. However, in some cases there might be (welcome or not welcome) side-effects.

    DMA, for example, works edge sensitive for internal modules. (level-sensitive won't work reliably). Clearing and setting an IFG bit may trigger a DMA transfer.
    Clearing an RXIFG bit manually causes the bit to never come up again by its own. You'll have to reset the USCI or write to TXBUF without TXIFG set (which is a condition most software explicitly won't allow) Or to manually set it again.

    Also, changing an IFG bit in an IFG register (multiple IFG bits, like P1IFG) may cause lost interrupts if the interrupt is triggered after the CPU has read the register and before it has written the changed content back. You may accidentally clear IFGs that would have been set just this moment. That's why the IV registers exist for reading and at the same time clearing IFG bits.

    A dummy read is faster than clearing the IFG bit. You don't have to specify the bit (well, usually, it is generated by the constant generator, so it won't take a clock cycle/instruction word), but you also don't need to write back (one cycle) after reading.
    And it implicitly 'documents' what you're doing :)

  • Jens-Michael Gross,

    Thanks for your reply. The side effects were what I was worried about. In particular, that clearing the RXIFG bit causes the bit to never become set again.

    However, good to know that clearing TXIFG does not have that same issue, as I am actually using it to kick-off the DMA without having to write the first byte of my transfer.

    (to be picky)
    For clearing RXIFG, I agree that doing the dummy read is preferred for readability and is faster if the bit has to be cleared and then set. However, the single bit clear of RXIFG is faster than a dummy read.

    UCA0IFG &= ~(UCRXIFG);  ->  BIC.B #1,&UCA0ICTL_H+0 (3 clock cycles)
    volatile uint8_t junk = UCA0RXBUF;  ->  MOV.B &UCA0RXBUF+0,0(SP) (5 clock cycles)

    Thanks again,
    Austin

  • A. Kirchhoff said:
    However, the single bit clear of RXIFG is faster than a dummy read.

    No. To make a dummy read, you have two words instruction (a MOV instruction and the RXBUF address) and then one read access to RXBUF. Three clock cycles.

    To clear the bit, you have a BIC instruction, the bit value to clear (if it is one of the lower 4 bits that can be addressed with the constant generator) and the UCA0IFG address, then a read from UCA0IFG and a write to UCA0IFG.
    Thus at least one cycle more, perhaps two cycles and one word more.

    Of course, if you assign the dummy read result to a global variable, then it is slower and longer, as you need the variable address and the write to it. But you don't need to. See what happens when you replace the assignment to junk by a simple "(UCA0RXBUF);"

    The BIC.B instruction, however, needs 4 cycles. Because it needs to do 4 memory accesses which each take 1 MCLK cycle.

    Not to mention that between reading UCA0IFG and writing back on the next MCLK cycle, one of the other bits might become set, and the writeback will silently clear it again. (can happen if the USCI clock is asynchronous to MCLK, same for the timers or the port interrupts). So manually clearing or setting IFG bits can be risky, if the register contains more than one IFG bit and the events setting them are not synchronized to MCLK.

**Attention** This is a public forum