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.

USIIFG counter interrupt enable/disabled for USI in SPI mode

Other Parts Discussed in Thread: MSP430G2221

I am using a MSP430G2221 with the USI in SPI mode, and I'm a little unclear on the operation of the USI counter interrupt (USIIFG). I am polling it in software by checking USIIFG in USICTL1, so I don't need the hardware portion of the interrupt.
 
Does disabling the counter interrupt (by clearing USIIE in USICTL1) prevent the flag from being set, or does it only prevent the hardware from running off trying to find an interrupt vector that I didn't implement?

  • Your understanding is correct.

    A few other users posted some problems with the USI counter. Please let us know your observations.

    -- OCY

  • I'm not having any problems per-se with the USI clock, this is more a theoretical question of how the inner workings of the interrupt operates, so as to better tailor my code.

    As for my understanding being correct, how do you mean? (I gave to possibilities, and I'm not sure which you're referring to)

  • Similar to most IFGs, USIIFG is set/clear independent of USIIE. If you are polling USIIFG, you should not set USIIE. Setting USIIE will cause an interrupt to be generated whenever USIIFG is set. When that happens, your polling will not be able to see USIIFG and you will need an ISR and a vector to point to that ISR.

    You were doing it correctly -- assuming that you want to use polling instead of ISR.

    The problems others have seen seem to say that the USI counter is not reliable. I have not verified it that is true or not. It may have to do with the USICLK picking up noise or when the firmware tries to read the USI counter.

  • I was actually doing both. Hopefully now I can speed up the execution of my code.

    The only actual problem with the USI that I ran into was that USICNT shifted out an extra clock pulse on the first byte after a reset, but that's addressed in the errata for the device.

    Thanks

  • Eric Jonardi said:
    The only actual problem with the USI that I ran into was that USICNT shifted out an extra clock pulse on the first byte after a reset, but that's addressed in the errata for the device.

    Yes, that's the known problem. IMHO this is caused by the USI state machine starting with an erroneous assumption about the current clock state when released from reset.

    Since the USI is usually only initialized once and then left operating, one could disable the USI output ports and initiate a dummy transfer before starting normal operation. THis wouldn't confuse any attached devices (well, if none is selected, non ewill be confused anyway).