• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 3580 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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

Eric Jonardi
Intellectual 305 points
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?

  • 0
    Guru 58965 points

    Your understanding is correct.

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

    -- OCY

  • 0 in reply to old_cow_yellow
    Intellectual 305 points

    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)

  • 0 in reply to Eric Jonardi
    Guru 58965 points

    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.

  • 0 in reply to old_cow_yellow
    Intellectual 305 points

    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

  • 0 in reply to Eric Jonardi
    Guru 227245 points

    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).

**Attention** This is a public forum