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.

tm4c1292ncpdt: I2C bus arbitration lost error

I am getting I2C0 bus arbitration lost error. On probing SDA line, found that it is stuck at low. Even doing a power cycle does not help. Looked into various forums, where it was suggested to toggle the SCL line few times configured as a GPIO. I did the same as listed below:-

MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

MAP_GPIOPinTypeGPIOInput (GPIO_PORTB_BASE, GPIO_PIN_3); // I2C data
MAP_GPIOPinTypeGPIOOutput (GPIO_PORTB_BASE, GPIO_PIN_2); // I2C Clk
count = 0;
while(MAP_GPIOPinRead(GPIO_PORTB_BASE, GPIO_PIN_3) == 0) {
MAP_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_2, 0);
//for(i=0;i<1000;i++) ;
SysCtlDelay((120000000/(3 * 1000000)) * 1); //wait 1ms

MAP_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_2, GPIO_PIN_2);
//for(i=0;i<1000;i++) ;
SysCtlDelay((120000000/(3 * 1000)) * 1); //wait 1ms

count++;
if(count > 100) //max 100 toggles before giving up to ensure we don't get stuck here
break;
}

After this i initialize I2C peripheral as normal. 

The above approach is not resolving my problem. I even configured the I2CSDA as open drain i.e. MAP_GPIOPinTypeGPIOOutputOD(GPIO_PORTB_BASE, GPIO_PIN_2) as someone suggested and even that did not work. Can someone please help me resolve this issue.

Thanks

Sumeet Deo

  • Hi Sumeet,
    Do you have multiple masters on the bus? Arbitration lost usually happens when there are multiple masters competing for the bus and one will eventually lost the arbitration. If you don't have multiple masters then it is also possible that the I2C slave is pulling the SDA low. Sometimes the slave is pulling the SDA low as it can not ack to the master. With the SDA pulled low, the master detects it as a arbitration lost. So I will suggest that you investigate who is pulling the SDA low, is it the master or the slave?
  • Hi Charles,

    Thanks for your quick response.
    No we are not using multiple masters on the bus. Its just one controller as the master i.e. TM4Cncpdt.
    But there are multiple slaves connected. And we suspect, one of the slaves is pulling the SDA low.

    SO as suggested by many, I followed the approach of configuring SCL input(PB2) as GPIO output and SDA as GPIO(PB3) input.
    And toggle the SCL many times, till SDA is detected high.

    But this approach does not seem to work for me.
    Can you suggest something, which I am missing here.
  • If you have multiple slaves and suspect one is holding SDA low, can you remove the slaves one by one and identify the offending module? What value of pull-up resistors are you using?
  • We are using 2K pull up resistors for SDA and SCL. And trying to identify the offending module.
  • We removed the offending slave and it fixed the stuck issue. But how can we recover from such a problem in software?
  • I2C is an open drain bus. If a bad slave holds the SDA line low, there is nothing that software in the master can do to free the I2C bus.
  • Agree (almost) w/vendor's Bob - that is an especially unfortunate and "difficult to overcome" issue.

    Yet (sometimes) the simple replacement of/that (particular) "troublesome" remote device - will remove (or greatly reduce) issue occurrence.

    We have LONG used that "pulsed SCL method" to recover from (similar) "I2C hung" situations.

    Should replacement of the (particular - problem device IC) not greatly improve - we have found that your "dedication of a spare GPIO" which either by itself - or via driving a small FET - applies & removes power to that remote, I2C slave - most (always) will "clear that fault."    

    As always - the replacement of the "troubling" device AND remote pcb - to eliminate "single board/chip anomaly" saves great (and misspent) time & effort!    And - of course - prior to arriving here - you HAVE (really) measured & verified the appropriateness of all connections (especially power) upon the offending board & chip!

    [edit] Note too that NO MENTION of the "distance" between this failing board/device & the controlling MCU has been provided!    I2C is not (famed) for long-distance success!

  • Bob Crosby said:
    If a bad slave holds the SDA line low, there is nothing that software in the master can do to free the I2C bus.

    Yet - both the o.p. & I have noted - that with the application of a sufficient number of SCL clocks - the offending slave (may) release the SDA from its ground hold.   Firm/I & multiple others have done just that - many times - and in fact our I2C software recognizes that this "errant slave" condition (may) occur - and software - upon detection - implements SCL clock (corrective) action.

    Should we not be concerned that a "Verify" has been applied to the post holding that (may I say, "imperfect/limited") quotation.

    Indeed if the slave is "really bad" and rejects SCL clock train and/or slave power removal/restore - it is (only) then that the master is unable to restore I2C.

    I believe that this point deserves clarification!

  • CB1,
    You are correct. Thank you for making that clear.
  • Thank you as well, Bob. (Verified post should strive for correctness.)
    It should be noted that you were first to suggest, "One by one - slave device removal - to identify the "troublesome" device."