• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 255 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.

MSP430FR5964: EUSCI_B STOP interrupt fires before RXIFG in last byte of RX transmission

Munan Xu
Expert 4610 points
Part Number: MSP430FR5964

Hello,

I have a customer who's experiencing that occasionally they will receive one less byte than expected from an I2C RX operation. They had found that occasionally the STOP interrupt will be asserted at the same time as the last RX interrupt and since the STOP condition interrupt has higher priority in the I2C ISR the code exits before loading the last byte from the RX buffer into memory. Since the messages are variable length they had been using the stop condition as a signal to exit the ISR and return control to the application with a RX done flag set. Of course with this implementation they are missing a byte in the RX buffer. Is this expected behavior to have both ISRs fire simultaneously? Currently they are manually checking for an RXIFG condition within the STOP interrupt condition, but is there a way to avoid having both these interrupts asserted at the same time?

Munan

  • 0
    Guru 22735 points

    The two interrupt conditions will not happen at the same time but if something delays them being serviced (another ISR running) then they could both be pending at the same time. Causing them to be serviced in priority order.

  • 0
    Prodigy 30 points

    Hmm that is an interesting thought. I do have a frequent timer and ADC conversion operation happing at the same time as this communication. So it is possible occasionally the two could occur at the same time and stave one and other off. I will try disabling this operation and see if the issue does not occur. Thank you for you thoughts.

  • 0
    Prodigy 30 points

    So after further investigation It appears QP using the QK RTOS Time Tick interrupt that occurs every 1 ms running on a 16Mhz MSP430. Occasionally delays the handling of the I2c comm. for the last RX byte of the message and we get a oending Stop condition and the last byte RX byte of the message at the same time. The timing of handling the last RX byte and a Stop condition at 400KHz is sub 10 us. What then happens is the Stop condition is a higher priority and the last byte of the message gets lost. What we did to fix this problem is in the ISR for handling the Stop condition we check if there is a pending RX byte and if so we read it and add it to the message before publishing it to the application. Thank you for your help in this matter and hope this helps others who may run into the same problem.

**Attention** This is a public forum