The TI E2E™ design support forums will undergo maintenance from Sept. 28 to Oct. 2. If you need design support during this time, contact your TI representative or open a new support request with our customer support center.

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.

TM4C1290NCZAD: Questions about TM4C129 I2C glitches

Part Number: TM4C1290NCZAD
Other Parts Discussed in Thread: EK-TM4C1294XL, EK-TM4C123GXL, TM4C123, DK-TM4C129X

From my customer:

We are using some TM4C129 Tiva microcontrollers on a couple of our products. We recently discovered an issue with the Tiva’s I2C bus’s SDA signals glitching low when the chips are reset. Can you help us figure out if this is expected behavior or not, and if we need to change our I2C configuration to safely handle chip resets?

 

We currently configure the SDA pins with the following calls into the TivaWare API:

GPIOPinConfigure(GPIO_PB3_I2C0SDA);

GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);

 

Later, our firmware issues two different types of reset – Software System Reset (by calling SysCtlReset()) and Watchdog Timer Reset (by allowing the watchdog timer to expire). Upon reset, the SDA signal is driven low momentarily and then released, as seen in the attached screenshot (oscilloscope channel 4).

 

We have played around with various register configurations prior to issuing the resets, and we found that calling GPIOPadConfigSet(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_STRENGTH_2MA,GPIO_PIN_TYPE_ANALOG) right before issuing a reset seems to resolve the issue. We don’t know why these register settings resolve the issue, so we’re hesitant to implement this particular fix without your consent that it is an acceptable and repeatable fix. Can you advise us?

  • Hello Meredith,

    I have been trying to re-create this issue myself in order to better understand & debug it, but so far I have not been successful at doing so. I would not say that is expected behavior, and searching through topics, I did not see a related case reported yet.

    On my end to try and recreate the issue, I added a SysCtlReset and monitored SDA with a trigger on the o-scope set for 3V and across dozens of attempts it only triggers when communication starts with the slave device. No glitches on Reset were observed.

    So, I'd like to ask a few more questions here:

    1) Is this only occurring on custom hardware? Is it occurring with all devices or just a few? Can they re-create this 100% of the time when doing a reset?

    2) Have they removed the slave device and still observed this?

    3) When the reset occurs, was there any I2C communication ongoing?

    4) Do they see any difference with SysCtlReset vs Watchdog? I have not tried Watchdog resets, but I have tried both hard and soft resets via RST assertion and SysCtlReset.

  • Hello Ralph,

    My small tech group (LIKES) your diagnostic list (#1 & #2).

    It proves always useful to learn the "Population (percent) impacted by the issue" as well as the "Possible influence of a connected device(s)."

    We propose adding (further) questions/observations to your diagnostic list:

    • Note that the "Number of I2C Slave (or remote Master) devices (likely accessing 'SDA') is presently "unknown!"   
    • There is no mention of, "How or If (any) of the "remote" I2C devices (Slaves or Master) connect to or are "influenced" by such Reset.
    • It likely will prove easier to simply, "Desolder & Lift the remote device's SDA pin" (gently of course) rather than "removing the chip(s)."    (especially helpful should there be multiple, remote I2C devices!)
    • It proves wise to monitor the supply voltage - both to the MCU as well as (all) remote I2C devices - while reset is asserted.
    • We've found that a "Longer Duration Reset and/or Pulsed Reset" may "Aid in the de-masking of such "glitch issues."

    Unstated is, "How this glitch was discovered" and its potential impact.    (If no SCL toggle occurred - then the SDA glitch may not have registered...)

  • Ralph,

    Thanks for looking at this issue and your follow-up. Here are my responses to your questions and more (hopefully helpful) information.

    1) I can reproduce this issue on both our custom hardware and EK-TM4C1294XL LaunchPad board.

    2) When we use the LaunchPad board to reproduce, there are no I2C slaves on the bus. The Tiva is the only device.

    3) There is no I2C communication when the reset occurs. To simplify the debugging, we issue the suspect resets immediately before any I2C communication are enabled.

    4) We see the same behavior with SysCtlReset and Watchdog.

    To simplify the issue, I have stripped out all unnecessary code to isolate the issue. Also, I have started using the LaunchPad exclusively to reproduce and debug the issue. In my hardware configuration, I am using a new LaunchPad board with no modifications other than connecting a 10KOhm resistor between the SDA pin and +3.3V to create the required pull-up resistor for proper I2C operation. The resistor is connected to header A1 pin 10 (I2C0SDA) and header A1 pin 1 (+3.3V).

    I have attached the source file that reproduces the issue. It uses SysCtlReset, but a watchdog reset performs the same. I have also attached a scope capture that shows the glitch using the attached code.

    If there is anything that you recommend I try with my LaunchPad, please let me know. I greatly appreciate your help in this matter.

    Thanks,

    Doug

    Policy.c
    #include <stdint.h>
    #include <stdbool.h>
    #include <TivaWare/inc/hw_memmap.h>
    #include <TivaWare/driverlib/gpio.h>
    #include <TivaWare/driverlib/sysctl.h>
    #include <TivaWare/driverlib/pin_map.h>
    
    int main(void)
    {
       // Enable the GPIOs usd for I2C
       SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOB);
       SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
       
       // Enable the I2C peripheral
       SysCtlPeripheralReset(SYSCTL_PERIPH_I2C0);
       SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);
       
       // Configure SDA
       GPIOPinConfigure(GPIO_PB3_I2C0SDA);
       GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);
       
       // Configure SCL
       GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);
       GPIOPinConfigure(GPIO_PB2_I2C0SCL);
       
       // Reset the chip
       SysCtlReset();
    }
    

  • Hello Doug,

    Thank you for these added details and how you were able to re-produce the issue on the LaunchPad. It is a bit of a curious behavior as when not using a slave device, I still used the same pull-up values as the I2C board that did not produce the glitch (3.3kOhm and I had used the BOOSTXL-SENSHUB originally) and I was able replicate the voltage drop.

    In my case, the minimum voltage was 2.64V and the time duration was approx 15 ns.

    I'll need to check with my colleagues a bit more about this but a few questions:

    1) Is the drop causing concern at a system level or is just more of a question for understanding how the device works?

    2) What value pull-up resistors are used on the custom hardware?

    3) Does the issue show up on the custom hardware both with and without the slave device attached?

    I did another round of searching to find out more on the topic, but haven't seen much. My initial guess from readings is that this has to do with how the open drain configuration works and so when you turn it to analog mode, that is why the 'glitch' goes away. Have you noticed any correlation on the value of the pull-up and the voltage drop observed?

  • Ralph,

    It looks like the BOOSTXL-SENSHUB connects to EK-TM4C123GXL, which uses a TM4C123 device. Our devices are TM4C129 parts, which might have different behavior. I'm unfamiliar with the differences between the TM4C123 and TM4C129 parts.

    In response to your questions:

    1) This is a concern at a system level. Our product is part of a platform standard that allows our customers to add third party devices to it. This means that we cannot control the number of slaves attached to the bus, and it means that we need to tolerate I2C devices that are not under our control, some of which might be adversely affected by the glitch.

    2) We use 4.7K on some and hardware and 10K on other.

    3) Yes, the issue is present on our hardware with and without slave devices present.

    I do notice that the resistor value does affect the voltage level and duration of the glitch. Higher pull-up resistor values larger voltage drop and longer recovery time.

    I acknowledge that there may be an unavoidable glitch during reset when the GPIO pin is configured as I2C SDA. If we can confirm that changing the SDA pin to analog mode is known to be glitch-free during reset, then we will be satisfied with that solution. As a point of reference, when we leave the SDA pin configured as-is for I2C operation (open-drain, controlled by the I2C peripheral), we see a glitch at reset with 100% reproduction. When we have reconfigured the pin as analog input right before the reset, we have observed 0% reproduction with 1000+ reset cycles. We are highly confident in this fix/solution based on our testing, but would like TI's confidence in this fix as well.

    Thanks for all your help!

    Doug

  • Hello Doug,

    Doug Ahlstrom said:
    It looks like the BOOSTXL-SENSHUB connects to EK-TM4C123GXL, which uses a TM4C123 device. Our devices are TM4C129 parts, which might have different behavior. I'm unfamiliar with the differences between the TM4C123 and TM4C129 parts.

    That BoosterPack works for both TM4C LaunchPad's and the DK-TM4C129X as well. I used the BoosterPack with the EK-TM4C1294XL LaunchPad and projects from [Install Path]\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c1294xl-boostxl-senshub

    Doug Ahlstrom said:
    When we have reconfigured the pin as analog input right before the reset, we have observed 0% reproduction with 1000+ reset cycles. We are highly confident in this fix/solution based on our testing, but would like TI's confidence in this fix as well.

    We are working on further root cause analysis right now, and until we understand the cause, I am not ready to suggest whether that fix is ideal. But it is a promising result you are getting, and we will look into that as a possible solution once we understand the problem on our end better.

  • Hello Doug,

    From the results of our testing, it looks like the glitch is specifically linked to the GPIO being configured as an Open Drain. If the GPIO is set to be in a state other than Open Drain, we are not seeing the glitch occur.

    The glitch would be hard to prevent from external reset sources unless you know when you are not using I2C and you can turn Open Drain off in those cases.

    From a Watchdog/SysCtlReset standpoint, you can avoid the glitch by using the following API before generating the intentional system reset:

    GPIOPadConfigSet(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);

    The GPIO_PIN_TYPE_STD setting is similar to the GPIO_PIN_TYPE_ANALOG setting which also clears the ODR bit (open drain), but this setting would be better to use given the I/O is being used a digital pin and not an analog one typically, so this retains the setting of the pin being digital and also clears the ODR bit which should solve your issue. That is the recommendation we would make to use.

  • Greetings,

    For the sake of "completeness" are not the following points worthy of (some) consideration?

    • Opening post stated, "issue with the Tiva’s I2C bus’s SDA signals" - yet it remains unclear if (other) than "PB3" was examined.    Should (another) SDA capable pin escape this issue - that appears a superior solution.
    • SDA's "Partner in Crime" (SCL) 'strangely' received "No mention!"    Has it escaped the glitch?   And - if so - does that not, "Point the way toward a (potential/possible) speeded (perhaps eased) internal device solution?"
    • Will the glitch occur upon each "Power-On Reset?"   What then?
    • and upon "Brown-Out/similar" occurrences?

    It should be noted that, "After each "Known Reset Command" (and MCU's recovery) the SDA line must then be restored to Open Drain..

    While anecdotal - at SIX YEARS + in to MCU's production - the "Impact of the glitch" may prove minimal as few (perhaps NONE) have similarly, "sounded such an alarm!"

    In closing - might, "Switching In a 2nd (paralleled) pull-up R" [via a GPIO toggled high]) better meet the I2C standard (Open Drain) while (further) shrinking the offending glitch?    Such would be commanded exactly as vendor's 'solution' - yet removed via ordering that GPIO to "input" - when not required...

  • Hello cb1,

    Great questions, I have a few answers already uncovered!

    cb1_mobile said:
    Opening post stated, "issue with the Tiva’s I2C bus’s SDA signals" - yet it remains unclear if (other) than "PB3" was examined.    Should (another) SDA capable pin escape this issue - that appears a superior solution.

    I tested multiple I2C ports, and found the behavior on all of them. Not 100% comprehensive sweep, but three ports indicates a pattern I would say.

    cb1_mobile said:
    SDA's "Partner in Crime" (SCL) 'strangely' received "No mention!"    Has it escaped the glitch?   And - if so - does that not, "Point the way toward a speeded (perhaps eased) internal device solution?"

    The devil is in the details with this! SCL does not actually need an Open Drain configuration. So we have a different configuration API for it: GPIOPinTypeI2CSCL

    In this API, the following is used:

        GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);

    Ergo, no issue with the Open Drain related glitching.

    cb1_mobile said:
    Will the glitch occur upon each "Power-On Reset?"   What then?

    From what I can see, yes, every device reset is impacted.

    cb1_mobile said:
    and upon "Brown-Out/similar" occurrences?

    I didn't test BOR, but I would presume based on the observations that it would also present the glitch.

    cb1_mobile said:
    It should be noted that, "After each "Known Reset Command" (and MCU's recovery) the SDA line must then be restored to Open Drain..

    Correct but that should occur naturally as part of proper I2C configuration post-reset which would have the device go through reconfiguration.

  • Good evening Ralph,

    Thank you - your "crack of the bat" response is appreciated.

    Good that (most) all SDA candidate pins were examined - left unstated - that proved "hard to accept."

    SCL - is it not true that (really) only the "new/improved" (i.e Extra Speed Modes) require the removal of SCL from "normal Open Drain Mode?"   (and this identifies a point which "all here" have failed to attend!  Especially moi!)    Now in the 100KHz range - IIRC - on your '123 device - we have past, "Forced the MCU's SCL line to "Open Drain" - and that succeeded!    (this was Staff explored - and complied w/client's demand for "Multi-Master" I2C - in which the use of (other) than Open Drain may cause "SCL signal contention!"   (You may wish to consider that yourself - I'm on a "European time schedule" - must be up & (almost) coherent @ 03:00 CST.)

    Have you a comment upon our "Glitch Suppressing" paralleled pull-up suggestion?    While not SDA related - gurl staff have used that (more than once) to resolve similar glitch-related issues.   

    And also - staff notes these MCUs as nearing (almost) teen-age - yet NO OTHER such 'SDA Glitch Reports' have pinged our radar... (purchased 'used' - at great discount...)  

    This weekend - we'll run tests upon our '123 boards - and observe & report if they suffer similarly.

    Take care...

  • Ralph,

    Thank you very much for your prompt actions to support this issue. It appears we are in agreement that the open-drain function is causing the glitch on reset. We have tried your recommended solution to configure the SDA pin as GPIO_PIN_TYPE_STD, but we are now observing that calling GPIOPadConfigSet(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD) causes the SDA pin to be driven high (although there is no longer a glitch at reset, which is great). It would be bad if an I2C device were to transmit a zero during or after the pin is configured as GPIO_PIN_TYPE_STD. We prefer to set the pin to GPIO_PIN_TYPE_ANALOG, with the acknowledgement that it has lost its digital functionality, especially because our firmware guarantees the Tiva part will not be transmitting or handling I2C transmissions during the time that the pin is configured as GPIO_PIN_TYPE_ANALOG. From our testing, configuring the pin for GPIO_PIN_TYPE_ANALOG leaves the pad in a tri-stated condition throughout the reset and until our firmware re-initializes the pin as GPIO_PIN_TYPE_OD post-reset. If you have no known reasons to believe configuring the pin as GPIO_PIN_TYPE_ANALOG is wrong and/or bad, we would like to do so.

    To add more detail, calling GPIOPadConfigSet() with PIN_TYPE_ANALOG actually causes the SDA line to be driven high similar to calling GPIOPadConfigSet() with GPIO_PIN_TYPE_STD, which is not good as I explained above. This is due to the order in which GPIOPadConfigSet() modifies the GPIO's registers. If the ODR bit is cleared first, we see the SDA pin drive high when ODR is cleared. However, if we clear DEN first, we see no driving of the SDA pin (high or low) when we then clear the ODR bit. So our firmware does not call GPIOPadConfigSet() with GPIO_PIN_TYPE_ANALOG. Instead, we explicitly clear the DEN bit first and then clear the ODR bit. This results in both glitch-free resets and a properly undriven SDA pin.

    [Edit] I had the order of operations backwards in our workaround.

  • Hello Doug,

    The focus with our investigation was to track it down to the ODR bit, but based on your system requirements there's no issue on our end to handle the settings like that now that you've explained the drawback to the STD setting as it pertains to your system. There wasn't an issue with the ANALOG setting as much as it seemed to be excessive to change the pin that much, but obviously for your setup you have a reason to do so, and it all makes sense to me.

  • Hello cb1,

    cb1_mobile said:
    Have you a comment upon our "Glitch Suppressing" paralleled pull-up suggestion?    While not SDA related - gurl staff have used that (more than once) to resolve similar glitch-related issues.   

    I don't, unfortunately. That's not a setup I am familiar with so I don't want to comment either way about it's merit, but appreciate the suggestion as another possible avenue to address this issue.

  • Ralph,

    Understood. Thank you for your support of this issue. You (and your team) have been extremely helpful.

    Doug

  • Hello from an "outsider" group, (again),

    The choice of:

    Doug A said:
    configuring the pin for GPIO_PIN_TYPE_ANALOG

    may lead to "down the road issues" especially if the (chosen) SDA pin is, "Not analog compatible!"    (Only a limited subset of the MCU's pins feature Analog operation.)

    This is (another) fact which may deserve consideration.

    Our group's suggestion of, "Reducing the "EFFECTIVE IMPACT" of the glitch via the "Controlled Switching-IN of a paralleled pull-up resistor (driven by a free GPIO) enables the "Continuation of the long standard, proven SAFE, Open-Drain SDA pin configuration!".    (And indeed - upon (other vendors') ARM MCUs - similar attempts to "Force a non analog pin" into analog mode - have led to issues...)    Staff recalls those (misguided) analog 'forcings' as other than SDA rescue.

    Should "long-term" Risk-Reward be bypassed?   Almost surely - such (unusual) pin configuration has not had the benefit of "normal/customary" MCU testing/qualification.    You (may) be saved via the "briefness" of such "forcing" - yet the practice adds an element of risk...