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.

Anomalous behavior of I2C on TM4C129x processors

Can someone be of some assistance with I2C on the Tiva?  Here is my problem:

 

I currently have the I2C running with 2 different I2C modules/buses and several devices. I am trying to incorporate error checking. The situation I am trying to address is a “stuck bus” state. This is where a device is holding the SDA low because a previous bus operation was interrupted and never completed.

 

To address this I intend to implement the following:

 

Switch the I2C5 bus signals  (PB4 and PB5) to GPIO configuration rather than (input for the SDA, output for the SCL)

Read GPIO PB5, which used to be SDA

If  low, loop a number of timer until it goes high

 

Switch the I2C5 bus signals back to I2C configuration

 

Go on with normal processing

 

---------------------------------------------------------------------------------------------------------

 

Every time the following code gets executed, to return the configuration to I2C, the SCL gets asserted LOW (forever) and has obvious adverse consequences.

 

    GPIOPinConfigure(module->clockPinConfigure); //exactly the same as: MAP_GPIOPinConfigure(GPIO_PB4_I2C5SCL);

    GPIOPinTypeI2C(module->clockPort, module->clockPin); // exactly the same as: MAP_GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_4);

 

    GPIOPinConfigure(module->dataPinConfigure); // exactly the same as: MAP_GPIOPinConfigure(GPIO_PB5_I2C5SDA);

    GPIOPinTypeI2C(module->dataPort, module->dataPin); // exactly the same as: MAP_GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_5);

 

Can the pins not be configured like this, except at Power-ON initialization? Do you know what might generating this anomalous behavior?

 

I suppose another way to achieve this is to not switch the I2C pins, but instead connect another set of GPIO up to the I2C lines and use those GPIO pins to toggle the I2C bus lines when needed but this is an awful waste of other GPIO lines.

 

Any ideas???

 

Thanks,

 

Russ

  • Do you know what might generating this anomalous behavior?

    The simple state sequencer implementation of the I2C slave ?

    Any ideas???

    A common method is quite close to yours:

    Switch the I2C5 bus signals  (PB4 and PB5) to GPIO configuration rather than (input for the SDA, output for the SCL)

    Read GPIO PB5, which used to be SDA

    If  low, loop a number of timer until it goes high

    Only, you don't just wait for the slave to recover (he most probably never will), but clocking out on SCL, and checking back after each clock if SDA is up.

    Alternatively, you can reset the slave - if he has any such input (usually not).

  • The appeal of I2C (as our poster notes) is the (reduced to just 2) GPIO.

    And too - that "strength" proves its weakness!

    At the sacrifice of GPIO - poster may "depower" the offending slave to restore (for awhile) I2C operation... SPI is the alternative...
  • cb1 said:
    SPI is the alternative...

    For the modest cost of two additional pins for one device and 3 additional pins for as many as your fanout can handle.

    Robert

  • Hello Russ

    First of all when configuring the I2C pin as GPIO, make sure theya re configured as output in Open Drain Mode rather than Output mode. The former is open-drain while latter is push-pull type IO configuration. The latter can cause IO damage, especially when there is a stuck condition on the bus.

    Now at power up almost all IO's are configured as General Purpose input (JTAG and a few others are exceptions)
  • At the sacrifice of GPIO - poster may "depower" the offending slave to restore (for awhile) I2C operation... SPI is the alternative...

    While this is certainly true, and quite easy to manage for hobby or singe-item project, I have almost always seen project managers frown/freeze at the idea of a hardware redesign. Software does not cost anything (*), so let's try to fix it in software.

    (*) - Just to be explicit, this is a quote, not my opinion.

    And SPI is workable if the IC either has a combined interface, or a SPI option exists. This is not always the case ...

  • May I counter by reporting that "many" large firms are retreating from I2C - switching to SPI.   Firm/I are embedded at a giant for some time now - such is true here and at our last (similar) contract assignment.

    Can software (really) be free when Regulatory Agencies DEMAND that such changes REQUIRE "Brand New Qualification Tests?"   And page upon page of updated Test/Verify/Approval/Sign-Offs!    (perhaps free for a garage shop - NEVER/EVER Free for a serious concern.)

    Firm/I would not employ I2C "unless" we provided the ability to control Slave Power!    Implemented w/that discipline - NO Hardware changes would be required.   But that's a function of planning/preparedness - is it not?

    If SPI could "accomplish the mission" my sense is that the, "EASE, ROBUSTNESS, & DIRECTNESS" of SPI entitles it to "First Rotation."

  • cb1 said:
    If SPI could "accomplish the mission" my sense is that the, "EASE, ROBUSTNESS, & DIRECTNESS" of SPI entitles it to "First Rotation."

    That's been my position for several decades. Why complicate life if you can avoid it.

    However, as f.m. said,  sometimes you can't. It used to be tuner ICs (thankfully I never worked close to that area) only available in IIC now it seems most camera/image ICs have an IIC port for control.

    I'm using a 'standard' platform on my next project and it needs an IIC EEProm for ID on the expansion and for an RTC. At least the SW for that is already done I just have to hook up the hardware. Hopefully the SW quality justifies that optimism.

    cb1 said:
    Can software (really) be free when Regulatory Agencies DEMAND that such changes REQUIRE "Brand New Qualification Tests?"   And page upon page of updated Test/Verify/Approval/Sign-Offs!

    You don't say. And it doesn't even have to be regulatory agencies, some industries make the demand themselves and if you deal with consumers then your insurance company is sure to demand it. Multiple test days, expensive lab time and time to write a report (repeated if you fail).

    Robert

  • Robert Adsett72 said:
    Multiple test days, expensive lab time and time to write a report (repeated if you fail).

    And - it is productive (profitable) for those placing such demands (when) you fail...

    Robert - I believe that you (past) mentioned that the (original) I2C specification has "wandered" as individual vendors have, "trimmed/clipped" to ease their implementations...    All of this increases the "degree of difficulty" for hapless I2C users...   (and - never are we allowed to cry, "Does NOT Work!)

  • Robert Adsett72 said:
    cb1
    Can software (really) be free when Regulatory Agencies DEMAND that such changes REQUIRE "Brand New Qualification Tests?"   And page upon page of updated Test/Verify/Approval/Sign-Offs!

    You don't say. And it doesn't even have to be regulatory agencies, some industries make the demand themselves and if you deal with consumers then your insurance company is sure to demand it. Multiple test days, expensive lab time and time to write a report (repeated if you fail).

    And to be fair f.m. also mentioned the free characterization wasn't his.

    Robert

  • cb1 said:
    Robert Adsett72
    Multiple test days, expensive lab time and time to write a report (repeated if you fail).

    And - it is productive (profitable) for those placing such demands (when) you fail...

    It's also more productive for them to keep you as a customer. They can't squeeze a knowledgeable customer beyond the bounds of the applicable standards very far w/o risking them going to a different testing organization. The standards may be single sources but there are a few testing organizations, not a lot but at least the whims of one don't rule.

    cb1 said:
    Robert - I believe that you (past) mentioned that the (original) I2C specification has "wandered" as individual vendors have, "trimmed/clipped" to ease their implementations...

    Maybe, I don't remember that. I do know the speed specifications have changed a couple of times. And I have no doubt vendors have as well, especially since only one can really claim to be IIC, the others had to call it something else and unlike the standards above there was no testing to keep their feet to the fire on interoperability (or resistance to lockup).

    Robert

  • And (perhaps) resistance to "voids?"