• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 78 subscribers
  • Views 2355 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.

MSP4305438 I2C UCRXIFG flag not being set

Lorin Ting
Prodigy 20 points
Other Parts Discussed in Thread: MSP430F5438A

Using the MSP430F5438A as the only master, I am trying to consistently access various I2C slave devices on a single bus.  Occasionally an error condition will get triggered by a read transaction. The target device varies but the condition is the same regardless of the target slave.

Condtion:

I2C read of one or more bytes fails to set UXRXIFG flag upon receipt of full byte.

I can observe on the scope that the start condition is sent, Address + RD bit clocked, slave acknowledges, 8 data bits are clocked and shifted to RXBUF but the RXIFG flag is not set nor is an interrupt generated (when corresponding IE is set).  What occurs next (on multiple byte reads) is that the MSP430 will generate 7 clocks of the next byte read and then hold the SCL line low on hte 8th clock (clock stretch scenario) because the RXBUF hasn't been read by my ISR. (due to the UCRXIFG flag never being set). 

I have tried both an interrupt based approach as well as a polling the UCRXIFG approach.  Both fail randomly because the I2C module does not always set UCRXIFG after receiving the 8bits of data.  Interestingly, if I break point the code at the failure, the UCB1RXBUF register holds the correct value for the last byte that did not set the UCRXIFG flag suggesting the module got the data into the shift register, copied it to the RXBUF but just did not set the flag bit.  I have searched my code to ensure only the ISR is clearing the flag.  I do not believe this is an interrupt enable related problem since the error occurs with my polling version (interrupts disabled/ignored).  Any help is greatly appreciated.  Attached image show what should have been a 6 data byte transaction but failed to set the RXIFG flag on the second byte and therefore clock stretched until my safety timeout in on the 7th bit of the third byte.  Note that single data byte reads do not clock stretch since the STP is issued during the data bit collection but the RXIFG flag is still not set as it should be.

 

1207.Six_Byte.pdf

  • 0
    Guru 227245 points

    In I2C mode, both, RXIFG and TXIFG are triggering the TX ISR. The RX ISR is used for status changes (start condition detected, NACK received etc.)
    It's easy to miss.

    How do you know the RXIFG bit is never set? Do you check it? Do you check it before the debugger reads RXBUF (which will clear the bit)

    I see that there are only 24µs between two interrupt events. On 1MHz, this are only 24 MCLK cycles. Maybe you're too slow servicing the first interrupt and when you finally do, you're reading the second and not the first byte in your ISR?

    How do you create the RXIFG signal on the scope? A software output to a GPIO pin?

    A look at your code would be useful.

**Attention** This is a public forum