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.

RTOS/CC3220SF-LAUNCHXL: CC3220S-LAUNCHXL : wifi_doorlock Project: I2C: MULTI slave: SDA PULLED LOW

Part Number: CC3220SF-LAUNCHXL

Tool/software: TI-RTOS

In this project, with Multi-slave configuration, it is found while debugging that some times SDA pin is pulled low.
So, in this scenario, at next debug, without power reset, if we try to open i2c, it throws an hardware Exception & code hangs there.

If we do the power reset, then SDA is high again & everything works fine.

Is there any way to handle this without power reset , at the run time ?

How to make SDA HIGH again ?

How resolve this issue ?


Another one, How to control the I2C_SCL , I2C_SDA pin as GPIO, to read & write values at those port pins.
function like GPIOPinRead , GPIOPinWrite. Any example to exactly how to pass arguments in this ?

  • Hi,

    I never seen issue with SDA to be held to low by I2C slave. But with SCL is this issue pretty common. You need to switch pin from I2C to GPIO and generate few pulses by GPIO at line and than switch back to I2C. This way I use SCL and it works well.

    With my CC3220 I use older driverlib instead TI Drivers. From this reason I cannot provide you exact piece of code.

    Jan
  • Yes, my bad SCL pin.
    But how to avoid the hardware exception, code hangs there.

    So, as per your solution, we must send some clocks on that pin as GPIO.
    But if one of the slave is kept pulling it down & we send high pulses on that... Will it not damage the that pin, if we forcefully push pulses on that pin ?

    I have handled GPIO & i2c seprately. But How to convert it I2C pins to GPIO , is there any example for this ?
  • Hi,

    I am not sure what is going on in your case. Generally you should see error I2C_MASTER_ERR_ARB_LOST from I2C hardware peripheral. I don't see any reasons to be triggered hard fault in this case.

    You need to be "stronger" than your I2C slave. I agree that this is not ideal, but generally it should not happen something wrong. Another option is to use reset pin, if your I2C slave have this pin (commonly not have them).

    In case of TI driver are used, you need to switch between I2C and GPIO at runtime. That means close I2C driver, reconfigure GPIO, generate few pulses, open I2C again. This is slightly tricky with TI drivers. From this reason I use driverlib. With drivelib recovery code look like:

    MAP_PinTypeGPIO(cfg->pinSCL, PIN_MODE_0, false);
    MAP_GPIODirModeSet(cfg->portSCL, cfg->maskSCL, GPIO_DIR_MODE_OUT);
    MAP_GPIOPinWrite(cfg->portSCL, cfg->maskSCL, 0xFF);
    for (i = 0; i < 4; i++) {
      MAP_UtilsDelay(200);
      MAP_GPIOPinWrite(cfg->portSCL, cfg->maskSCL, 0x00);
      MAP_UtilsDelay(200);
      MAP_GPIOPinWrite(cfg->portSCL, cfg->maskSCL, 0xFF);
    }
    MAP_UtilsDelay(200);
    
    MAP_PRCMPeripheralClkEnable(PRCM_I2CA0, PRCM_RUN_MODE_CLK);
    MAP_PinTypeI2C(cfg->pinSCL, I2CgetPinMuxMode(cfg->pinSCL));
    MAP_PinTypeI2C(cfg->pinSDA, I2CgetPinMuxMode(cfg->pinSDA));
    
    MAP_PRCMPeripheralReset(PRCM_I2CA0);

    Jan

  • Hi Sagar,

    I assume that you have resolved your issue with Jan's suggestions since we have not heard back from you. If not, feel free to post a response to this thread, or open a new thread regarding this issue.

    Regards,
    Michael