TM4C1294NCPDT: I2C ARBLOSTRIS status bit

You might also want to look at the SDA line with an oscilloscope. If the rise time is too slow, it may be seen as a loss of arbitration. You might have to reduce the speed (you did not mention which speed you are using) or reduce the resistance value of the pull up to get a faster rise time.

Greetings,

May I agree w/both vendor agents - and as a (successful) participant in the referenced (past) posting - provide an updated, 'Report of Findings' which my firm provided for a key client.    (Client gracefully agreed to the release of this data.)

Follows our 'Summary of Techniques' which aim to (much reduce, ideally prevent) 'I2C Slave designated devices' from, 'Latching the SDA  signal line low while enhancing data exchange speed & robustness:

• If and when/where possible - limit the number of I2C Slaves to '4 or less.'   We tested 'known good Slave Devices' - from 4 different vendors - over a variety of 'connection paths & (both) pcb trace lengths & cable runs.'   Client & my firm were 'unable to positively discover why this limitation occurred' - yet it did so - and existed (even) under 'double blind' tests - performed (both) by my group & this client.    Note that as the distance between I2C Master & Slaves increased - this, 'Cut-off at 4 Slave devices strengthened.'    We lowered the value of the pull-up resistors as Slaves were added - & employed advanced, 'Impedance Measuring Equipment' - and even that could not 'pin-point' why this cut-off occurred - and with such regularity.    When beyond 4 Slaves are required - we recommend 'I2C Bus Repeaters' and/or 'Use of a 2nd I2C Channel.'    (i.e. an independent I2C channel)
• As expected - higher speed I2C data rates (both): 'Reduced the length over which we could robustly exchange' and 'Increased the number of such I2C SDA Bus Hangs!'    Again - this is one area where the 'I2C Repeaters' often resolved such issues.

Both (extended) I2C pcb trace length and cable length - slowed data transfer - AND greatly boosted the occurrence of these 'SDA Hangs!'   We discovered that - 9cm proved error-prone - and above 16cm proved especially error-prone.   Utilization of RF Transmission Line Techniques - to include the widening of both traces (but especially the SCL trace) enabled substantial distance improvement - and higher exchange speed.   Our impedance bridge did detect, 'excessive inductance' when the pcb traces were:

• too long
• too narrow
• too indirect (i.e. direction changing - especially >45°)
• passed thru vias

• It was theorized that this 'excess trace inductance' gave rise to, 'Damaging Transients' - which caused 'latch-up' of the I2C Slave - hanging SDA.
• We added small value series resistors (i.e. 33-50Ω) placed near (both) SDA & SCL pins of 'each slave.'   This appears to have reduced this issue.

Our Tests employed:

• 3 different ARM Cortex MCUs (from 3 different vendors - 2 M4s, 1M7) and an FPGA as I2C 'Masters.'
• I2C Slaves - most always - resident upon, 'Official Eval Boards' - again from a variety of 'name sources.'
• Custom pcbs which provided, 'different: trace lengths & trace widths' between I2C Master & Slave
• Transmission was 'Standard (100Kbps) & Fast Mode (400Kbps).'   The 2 higher speed modes were also tested - those results have not been 'authorized for disclosure.'
• All tests were conducted in an 'RF Resistant Chamber' - a Lab Grade Power Supply insured, 'Pure & Adequate Power.'

We wish to thank our client for enabling us to, 'Share this data' - and trust that (many here) will benefit from this effort...

Hello cb1,

Thank you much for sharing such detailed findings with the community! And extend our thanks to your client as well. This will surely help many others, and we appreciate the sharing of experience from your firm.

Hello Ralph,

In my case, there is only one device connected to the I2C bus, no other master. So, I don't understatnd the status bit "arbitration lost" when there is only one master.

 I tried to pulse the SCL signal with this code :

static void ResetI2CModule(void)
{
 // Reset I2C module
 // Stop the Clock, Reset and EnableI2C Module in MasterFunction
 SysCtlPeripheralDisable(PSENSOR_I2C_SYSCTL_PERIPH);
 SysCtlPeripheralReset(PSENSOR_I2C_SYSCTL_PERIPH);
 SysCtlPeripheralEnable(PSENSOR_I2C_SYSCTL_PERIPH);

 // Wait for the Peripheralto be ready for programming
 while(!SysCtlPeripheralReady(PSENSOR_I2C_SYSCTL_PERIPH));

 #ifdef DEBUG
 TRACE_I2C("I2C reseted, %d times\n",++NbI2CReset);
 #endif

 // Reset interrupt
 I2CMasterIntClearEx(PSENSOR_I2C_BASE,I2CIntFlags);
 //I2CMasterIntClear(PSENSOR_I2C_BASE);
 LastIntStatus = 0;
  //I2CMasterEnable(PSENSOR_I2C_BASE);
 I2CMasterInitExpClk(PSENSOR_I2C_BASE, SYSTEM_CLOCK, false);
 // Enable the I2C Master interrupt.
 I2CMasterIntEnableEx(PSENSOR_I2C_BASE,I2CIntFlags);
}

void Read_I2C_device(void)

{

...

  // Test done before trying to read on the I2C bus:

  if( I2CMasterBusBusy(PSENSOR_I2C_BASE) )
  {
   uint32_t LineState;
   LineState = I2CMasterLineStateGet(PSENSOR_I2C_BASE);
   TRACE_I2C("I2C bus busy! %Xh SDA %s SCL %s\n",LineState,LineState&0x02?"ON":"OFF",LineState&0x01?"ON":"OFF");
   // Reset I2C module
   // Stop the Clock, Reset and EnableI2C Module in MasterFunction
   SysCtlPeripheralDisable(PSENSOR_I2C_SYSCTL_PERIPH);
   TRACE_I2C("I2C Begin Pulse SCL\n");
   // Configure SDA as DTR output signal modem
   GPIOPinConfigure(GPIO_PN4_U1DTR);
   GPIOPinTypeGPIOOutput(PSENSOR_GPIO_PORT_BASE,PSENSOR_I2C_SDA_PIN);
   {
    uint32_t SignalState;
    //SignalState = GPIOPinRead(PSENSOR_GPIO_PORT_BASE,PSENSOR_I2C_SCL_PIN|PSENSOR_I2C_SDA_PIN);
    for( int i = 0 ; i < 50 ; ++i )
    {
     // Reset SCL and SDA
     GPIOPinWrite(PSENSOR_GPIO_PORT_BASE,PSENSOR_I2C_SCL_PIN|PSENSOR_I2C_SDA_PIN, PSENSOR_I2C_SCL_PIN/*|PSENSOR_I2C_SDA_PIN*/);
     //vTaskDelay(1);
     SysCtlDelay((SYSTEM_CLOCK/3/100000)+50);
     // Reset SCL and SDA
     GPIOPinWrite(PSENSOR_GPIO_PORT_BASE,PSENSOR_I2C_SCL_PIN|PSENSOR_I2C_SDA_PIN, PSENSOR_I2C_SDA_PIN);
    }
   }
   //Configure the pin muxing for I2C functions
   GPIOPinConfigure(PSENSOR_I2CSDA_PIN); 
   //Select the I2C function for these pins
   GPIOPinTypeI2C(PSENSOR_GPIO_PORT_BASE, PSENSOR_I2C_SDA_PIN);
   TRACE_I2C("I2C End Pulse SCL\n");

     ResetI2CModule();

...

}

 It works four or five times, but later, the device definitivly doesn't answer...

Thank you for your answer.

 Best regards.

Ralph Jacobi said:

Thank you much for sharing such detailed findings with the community!

Hello Ralph,

Staff/I thank you for your kindness - and for the unceasing support, 'Vendor Agents provide for this forum community.'

Our client - reading our posting - has authorized the release of 4 other of our findings:   (Note: in all cases - only 'One Bus Master' was employed!)

• Having past taken an earlier Tech Firm 'Public' - we have a 'collection of properly stored, 'virgin' I2C Slave devices.    And these devices (were) included w/in our, 'I2C Slave Device inventory' - which was (primarily) composed of far newer Slave devices.    Now it was 'theorized' that these 'older/past' devices (~15-20 years aged (via date codes)) being implemented w/'larger device geometries/features' - would prove 'more resistant' to such:
  • SDA Hangs
  • Distance restrictions (i.e. between Master & Slave)
  • and that theory (more resistant) was 'substantially confirmed!'

• By placing a small-signal FET (capable of well-sourcing the Slave device's required current) w/the FET operated under MCU's GPIO Control - we were (almost) always able to, 'quickly recover' from SDA Hangs!    These tests were performed primarily upon the 'latest/greatest' I2C Slave devices which many/most forum users are likely to employ. 
• While not (yet) entirely conclusive - and while, 'Pulsing the SCL signal' (often) releases the SDA Hang - it is believed that the 'Pulsing Technique AVOIDS Addressing the cause of the SDA Hang - and that further such SDA Hangs - in time - (likely) lead to device destruction!
• Should these SDA Hangs occur w/regularity - there is likely to be a,
  • Board design issue (routing, trace width, unwanted (adjacent) noise and/or signal coupling)
  • excessive separation between Master & Slave
  • improperly valued 'pull-up' resistor(s)

Again - all of these findings resulted from, 'ONE I2C MASTER Only' implementations - thus 'Arbitration' was not (realistically) in play.    Instead - the 'SDA Hang' likely provides a 'Warning' - that, 'All is NOT Well...'

Hello Francois,

Have you been able to look at the SDA line with a Scope? Bob detailed a number of causes that could also result in this which would occur due without a second master. Given what you are reporting, that should be the next step here. Even at 100kbps, the pull-up resistors need to be assessed. You may also want to refer to this app note regarding the pull-up's. http://www.ti.com/lit/an/slva689/slva689.pdf

Thanks cb1 for additional four findings!

cb1_mobile said:

Should these SDA Hangs occur w/regularity - there is likely to be a,

• Board design issue (routing, trace width, unwanted (adjacent) noise and/or signal coupling)
• excessive separation between Master & Slave
• improperly valued 'pull-up' resistor(s)

When assessing the root cause for some of these hangs, were there any behaviors on scope caps that helped indicate which of the these issues were present? I would guess for points 1 and 2 that the behaviors were similar, but what about those first two compared to wrongly valued pull-ups?

Ralph Jacobi said:

...were there any behaviors on scope caps that helped indicate which of the these issues were present?

We have hundreds of scope caps: 'Pre, At & Post' Trigger.   Indeed the (unwanted) added inductance - introduced by conditions 1 & 2 - produced transient spikes - which exceeded the Slave device's spec.    At this stage - our client believes that, 'Sufficient data has been herein presented - so that those (really) interested - should be able to perform their own investigaton...'

Again the potential 'critical finding' is that the repeated occurrence of, 'SDA Hang' (initiated by the Slave) serves as a 'Marker' of a design/implementation weakness...

Hello cb1,

Oh I wasn't requesting the scope captures to be posted or anything to that effect, but just some ideas about what Francois could try keeping an eye out for as he analyzes the hardware. Your latest reply provides sufficient advice for that, so thank you once again for all the contributions here.

Hello Ralph,

We've had no feedback from this poster - thus are unaware what (if anything) has been absorbed.

I can add that, 'Not all Slave Devices exhibit this 'SDA Sensitivity' to the same degree!      That's key/critical!

For example - a 'flawed pcb layout' may (in time) destroy a particular Slave - yet a 'Substituted Device' - (ideally w/mating pcb footprint) may exhibit, Far Less or (even) NO SUCH SENSITIVITY!    That's a (pardon) rather spectacular find - don't you agree?    (we are - once again - indebted to our client for allowing the 'public sharing' of (certain) of our key/critical 'I2C Finds!'

Usually - but not always - multiple vendors may supply (near) identical devices - which enables the 'Search & (hopefully) successful identification of a 'Mating Performance, Slave Device' which can 'SURVIVE' - w/in (even) a 'less than pristine' board/noise/pcb implementation layout...    Such (may) prove the 'best course of action' for this (thus far) 'silent to us' poster...

Thank you Ralph and cb1 for your answers.

I can't use an oscillo to see the signal's state because I do not have one.

I only call I2CMasterBusBusy() and I2CMasterLineStateGet() procédures to determine the state of the lines. Sometime, SDA is ON, and sometime SDA is OFF when problem occurs.

Best regards.

                       FWX.

Hello Francois,

Without the scope captures it is very hard for us to offer more feedback here... when can you get access to one?

Debugging this situation with a partial set of information may not be possible if the issue is with hardware.

Hi Ralph,

Agree completely - remote Diagnostics - minus key measurements - operate at 'Great Difficulty & Challenge.'

Local schools, universities - even small Tech Businesses - may allow the 'supervised use of a scope.'

Absent 'scope caps' - based upon my client's well described 'findings' - a 'High Resolution' photo of poster's board - (may) enable further comment.

Such photo (must) include:

• clear, unobstructed view of (both) MCU & 'Faulting Slave Device'
• accurate measurement of the 'separation distance' - between MCU & Slave
• photo should clearly reveal the trace routing between MCU & Slave - especially that of the SCL line
• clear identification of the Slave device - ideally w/a 'link'

It is unclear if the poster 'accepted' that a, 'near identical device'  (w/matching pcb 'footprint') (may) be available - and (may) prove more resistant to, 'lock-up and/or destruction.'