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.

TMS320F2800156-Q1: I2C pins remain low

Part Number: TMS320F2800156-Q1
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

Tool/software:

Hi,

I want to test a sensor with I2C communication. I set I2C configurations with sysconfig. 

SCL and SDA pins is high on power up. After setting gpio pins the pins get low and remains low.

I have a custom pcb. I2C pins are empty. The sensor pcb has a 4K7 resistors on SCK and SDA pins.

I have tested sensor with STM32 MCU and works fine.

Where am I missing?

  • Mesut,

    Normally when the clock is stuck low, it's because the target is holding it low. How many cycles do you see before it stops? I've attached a screenshot about clock stretching behavior from the F28P55x TRM (same behavior of I2C in both devices, but we haven't documented it in previous TRMs unfortuantely)

    Since I do not know what type of sensor you are using, I will provide some general debugging tips. As simple as it seems, ensure the I2C settings on both the MCU and sensor match such as 7 or 10-bit addressing, addresses, and what data F280015x is transmitting. Are the voltages on the GPIOs / PCB the same? Are the GPIOs connected to the I2C pins on the PCB and thus effectively including the pull-up resistor on the I2C line? If the I2C pins are empty, how have you tested whether data can be sent or received? 

    Best Regards,

    Aishwarya

  • Hi Aishwarya,

    Thank you for your answer.

    I have custom pcbs for MCU and sensor. MCU pins directly connected to sensor. The sensor pcb has 4K7 pull-up resistors. When power up SDA and SCL pins are 3.3V. After that I debug the MCU. When setting gpio pins as I2C pins, the pins goes to low(0.052V) and remains low all the time whatever I set on I2C settings. I think my problem is related to GPIO pins.

    I have tested the sensor with STM32 MCU by connecting pins directly. The sensor works fine. I did not accomplish to work with C2000 MCU

    All codes are generated by SysConfig v1.20.0 and C2000Ware v5.2.0.00 as on the picture above.

  • Mesut,

    In terms of GPIO configuration, configure the pin type as "Open-drain output with pull-up enabled output and input" and try different I2C GPIOs to see if you still have this issue. Board.c output should look something like this:

     

    If you can change the resistor value, I would also recommend trying 2.2 kOhms.. that's usually more than enough for applications I've seen at least.

    Best Regards,

    Aishwarya

  • Hello,
    I am using the F280039C in a similar way, MCSDK/C2000ware 5.02 and SYSCONFIG 1.20.

    This is a I2C bus with only the 39C and an ATMEL 24C256C so the C2000 side is master.

    When using the driverlib I2C sample code only and not using SYSCONFIG to configure I2C and GPIO pins for I2C there is no problem.

    When switching to SYSCONFIG to configure both the I2C peripheral and GPIO pins for I2C there is a difference in the generated code in board.c and the related code in the example. I2C pins are both set to Open-drain output with pull-up enabled output and input in SYSCONFIG.

    The SYSCONFIG generated code in board.c does not set the GPIO direction for I2C clock and data.

    The example code c2000ware/driverlib/f380003x/examples/i2c/i2c_ex4_eeprom_polling.c includes a direction configuration to "input" in lines 311 and 315.

    The SYSCONFIG generated code in board.c does set the GPIO pad configuration to open-drain with pullup:

    GPIO_setPadConfig(EEPROM_I2C_I2CSDA_GPIO, GPIO_PIN_TYPE_OD | GPIO_PIN_TYPE_PULLUP);

    GPIO_setPadConfig(EEPROM_I2C_I2CSCL_GPIO, GPIO_PIN_TYPE_OD | GPIO_PIN_TYPE_PULLUP);

    The example code c2000ware/driverlib/f380003x/examples/i2c/i2c_ex4_eeprom_polling.c includes a pad configuration to "pullup" (and no open-drain) in lines 312 and 316.

    With SYSCONFIG code for I2C the clock and data start "high" but after GPIO pin configuration they both are "low" even with an external pullup of 1 kohm.

    Once these are low the bus is "busy" as the I2C peripheral cannot clear the condition (I2CSTR:BB is set following I2C_enableModule).

    If TI confirms this status I would welcome a SYSCONFIG fix to resolve this.

  • Hi Matthew, 

    Thank you for your answer. 

    I have tried i2c_ex4_eeprom_polling example configuration and it works. I also tried different pad configs, but only GPIO_PIN_TYPE_PULLUP worked fine.

    My last gpio config is here

    void I2C_GPIO_init(void)
    {
        // I2CA pins (SDAA / SCLA)
        GPIO_setPinConfig(GPIO_35_I2CA_SDA);
        GPIO_setDirectionMode(35, GPIO_DIR_MODE_IN);
        GPIO_setPadConfig(35, GPIO_PIN_TYPE_PULLUP);
        GPIO_setQualificationMode(35, GPIO_QUAL_ASYNC);
    
        GPIO_setPinConfig(GPIO_37_I2CA_SCL);
        GPIO_setDirectionMode(37, GPIO_DIR_MODE_IN);
        GPIO_setPadConfig(37, GPIO_PIN_TYPE_PULLUP);
        GPIO_setQualificationMode(37, GPIO_QUAL_ASYNC);
    }

    Thanks

  • Hi Mesut / Matthew,

    Thank you for your collaboration on this forum, that's what we like to see! I've made a note of this and will look into it on my end and take the appropriate following steps, as needed.

    Best Regards,

    Aishwarya

  • Hi Mesut / Matthew,

    After looking through this post as well as SysConfig, I've realized that I already filed a ticket to have this fixed earlier this year. We are aiming to have this fix ready for the next C2000Ware release. Thanks for your help.

    Best Regards,

    Aishwarya