• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 78 subscribers
  • Views 926 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.

TI MSP430 5522 SPI SLAVE mode sometimes gets hung up on while (!(UCB0IFG&UCTXIFG)); in ISR

Brent Williams
Expert 1065 points

I have a MSP430 5522 and am using the SPI in SLAVE Mode.

Everything works well for quite a while.  Occasionally the SPI gets stuck in the ISR on the

while (!(UCB0IFG&UCTXIFG));

Any ideas as to why this is happening?  Or what I can do to fix or get around this problem?

Thanks,

Brent

  • 0
    TI__Genius 16740 points

    Hi Brent,

    I'm not aware of any particular device issue that could be causing this problem.

    The TXIFG will set when the TX buffer is ready to accept new data. If you write the TXBUF and the master doesn't send a new byte, the flag won't get set again. Is your device stuck even when the master sends a new byte? Are you writing TXBUF in the TX ISR, in the RX ISR, or somewhere else? 

    Do you see any errors in the Status register?

    I recommend you to use a logic analyzer to check for irregularities on the bus, and check when you are reading the buffers and clearing the flags, perhaps by toggling some GPIOs in the ISRs or when the buffers are read/written.

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Expert 1065 points

    Thanks for the response Luis.

    The device is stuck even when the master sends a new byte.  I am writing the TXBUF from the RX ISR.

    I will take a look at the status register and look on a scope.

    Brent

  • 0 in reply to Brent Williams
    Expert 1065 points
    Hi Luis looks like the status register has a value of 0x21 => BUSY flag and OVERRUN Error flag.

    So with the overflow flag:

    Overrun error flag. This bit is set when a character is transferred into UCxRXBUF before the previous character was read. UCOE is cleared automatically when UCxRXBUF is read, and must not be cleared by software.

    It looks like the master is sending characters to fast for the MSP430 to handle?

    I have lowered the SPI clock speed on the master side from 1MHZ to 300KHZ to see if that would help and it did not.

    Could a higher order interrupt be holding the SPI interrupt off long enough for it to cause this error?

    Thanks,

    Brent
  • 0 in reply to Brent Williams
    TI__Genius 16740 points
    Hi Brent,

    That depends on your application, I'm not sure how much latency you have.
    But MSP430 doesn't have programmable priority of interrupts and nesting is not automatically supported.

    When you attend an interrupt, MSP430 will mask all the other interrupts (with GIE bit), which means that ANY interrupt will add latency. The SPI ISR can't execute until the other ISR is done, unless you manually re-enable interrupts inside the ISR in order to allow nested interrupts.

    I'm not sure if that explains the fact that the device doesn't get out when new packets are received, though. Does the rest of the configuration look OK, including the GPIOs?
    Is the problem fixed by forcing a Reset of the USCI? Are you using 3-wire mode and is this the only device on the bus?

    Regards,
    Luis R
  • 0 in reply to Luis RC
    Expert 1065 points

    Hi Luis,

    Thanks for the response.  I removed all other functionality (i.e. other interrupts in the system) and I do not see the problem.  The other interrupts in the system are pretty low latency (i.e. very small and not much done in them).  My assumption at this point is that some of the higher priority interrupts are holding off the SPI ISR just enough (again this happens about 2% of the SPI messages).

    Since like you mention, priorities are set, I slowed the SPI clock speed down and I am not seeing the error so far in my testing.  And in the event I do get some SPI "error", what I was doing before slowing down the SPI clock was what you had suggested - resetting the peripheral.  And that does "reset" things to a good state.

    Thanks again for your help,

    Brent

**Attention** This is a public forum