• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 255 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.

Original question:

MSPM0G1106: I2C jamming

MSPM0G1106: I2C getting stuck after a NACK

Asiel Trejo
Prodigy 90 points
Part Number: MSPM0G1106

Hi, I'm currently creating a multimaster I2C driver.

After transmitting any message in controller mode, I switch the I2C to target mode. 

I notice that it gets stuck after receiving an NACK. I would like to know what would be the sequence of handling NACK. I'm currently doing this according to the manual in the interrupt section.

Then I switch it to target using the code that is provided in the SDK examples.

I found that after an NACK, it just gets stuck. Am I doing something wrong? should I reset the driver.

If so, could you please provide code to reinit or handle in anyway the NACK.

  • +1
    TI__Mastermind 28075 points

    Hi Asiel,

    When you say "stuck" do you mean the code stops executing or the I2C is no longer outputting?

    Knowing exactly where you are getting stuck in code would also be helpful.

    Receiving a NAK should not prevent your next I2C command from executing. It should just set the NAK interrupt and trigger you to enter the ISR if that interrupt is enabled.

    As far as NAK handling goes, resetting the I2C peripheral when you receive a NAK is one option, setting a flag, or turning on an LED, or trying the communication another 1 - 10 times to see if the device responds properly are other options you might want to take when a NAK occurs. Exactly what you need to do will depend a bit on your application requirements. 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 90 points

    Thank you! I dug deeper and you are right, it is not the NACK interrupt. I improved a better handler and saw where it got stuck.