• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 245 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSPM0L1306: I2C arbitration lost

Jose Valdes
Prodigy 30 points
Part Number: MSPM0L1306


Tool/software:

Hello,

We are masking an I2C arbitration lost interrupt (SARBLOST) which we know for a fact that is getting triggered sometimes, at the same time we have an issue where the SCL line is going and staying low. We are not sure at this point:

  • if the SCL=low (happening for reasons outside the microcontroller) is triggering the arbitration lost interrupt
  • OR
  • if a false positive of the arbitration lost interrupt followed by reinitializing the I2C driver is causing the SCL=low

Before getting into more details of our implementation, we have a couple of questions:

  1. What conditions does the microcontroller need to see to trigger SARBLOST?
  2. What should the software do as a result of SARBLOST (aside from what the TRM recommends which seems to be written for controller mode)?

The microcontroller is configured as I2C target.

Thanks

  • 0
    TI__Guru 71216 points

    Hi Jose,

    I super apologize for the delayed response.

    First, I'll assume the I2C controller is another MCU, correct?  Can you tell me what it is? ( I ask in case I need to lookup information about that MCU)

    Next, since the MSPM0 is the target, why are you looking the SARBLOST interrupt?  This is used in controller mode.

    Regarding the SCL being low, this typically is a "clock stretch" event that occurs when the controller is attempting to read data from the MSPM0 and it is not ready to send data.  This is caused due to an empty TXFIFO (nothing to transmit in the FIFO). 

  • +1 in reply to Dennis Lehman
    Prodigy 30 points

    Hello Dennis,

    We solved the issue, it was in fact a "clock stretch". Not caused by an empty FIFO but by a "target wakeup" therefore setting SWUEN=0 did the trick. Also per your recommendation we removed support for SARBLOST.

    Thanks for the support