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.

Compiler/TM4C123GH6PM: I2C write issue. Issue with Continuous write. SDA goes high.

Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: PCA9534

Tool/software: TI C/C++ Compiler

Hello community, 

I am having an issue with my I2C code. In the figure below, I am having an issue with I2C SDA line going high between the bytes. It is still communicating with most of the chips on the i2c (bottom figure), but when I am talking to the PCA9534, the bus hangs as shown in the top figure. 

void I2CSend(uint8_t slave_addr, uint8_t * data, uint8_t num_of_elements_to_send)
    {
    uint8_t i;

    // Tell the master module what address it will place on the bus when
    // communicating with the slave.
    I2CMasterSlaveAddrSet(I2C0_BASE, slave_addr, false);



    //put data to be sent into FIFO
    I2CMasterDataPut(I2C0_BASE, data[0]);

    //if there is only one argument, we only need to use the
    //single send I2C function
    if (num_of_elements_to_send == 1)
        {
        //Initiate send of data from the MCU
        I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_SINGLE_SEND);

        // Wait until MCU is done transferring.
        while (I2CMasterBusy(I2C0_BASE));


        }


        //otherwise, we start transmission of multiple bytes on the
        //I2C bus
    else
        {
        //Initiate send of data from the MCU
        I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_SEND_START);

        // Wait until MCU is done transferring.
        while (I2CMasterBusy(I2C0_BASE));

        //send num_of_args-2 pieces of data, using the
        //BURST_SEND_CONT command of the I2C module
        for (i = 1; i < (num_of_elements_to_send - 1); i++)
            {
            //put next piece of data into I2C FIFO
            I2CMasterDataPut(I2C0_BASE, data[i]);
            //send next data that was just placed into FIFO
            I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_SEND_CONT);

            // Wait until MCU is done transferring.
            while (I2CMasterBusy(I2C0_BASE));
            }

        //put last piece of data into I2C FIFO
        I2CMasterDataPut(I2C0_BASE, data[i]);
        //send next data that was just placed into FIFO
        I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_SEND_FINISH);


        // Wait until MCU is done transferring.
        while (I2CMasterBusy(I2C0_BASE));






        }
    }

  • Hello Andrew,

    I don't think the SDA line going high is the root cause of your issue, from what I recall seeing on other logic shots of I2C examples that is how the I2C bus operates for the device when writing to slave devices, and I haven't found any reports of that behavior causing an issue. I think we will need to look deeper into this than the SDA line behavior.

    Few questions to get more information:

    1) What value pull-up resistor do you have installed?
    2) Can you share the I2C initialization information?
    3) Does the problem occur for both read and write?
    4) Have you verified the slave address is correct for the device? I presume it's set to 0x48 from your image?
  • void InitI2C0(void)
        {
        //enable I2C module 0
        SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);
    
    
        //reset module
        SysCtlPeripheralReset(SYSCTL_PERIPH_I2C0);
    
        //enable GPIO peripheral that contains I2C 0
        SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    
        // Configure the pin muxing for I2C0 functions on port B2 and B3.
        GPIOPinConfigure(GPIO_PB2_I2C0SCL);
        GPIOPinConfigure(GPIO_PB3_I2C0SDA);
    
        // Select the I2C function for these pins.
        GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);
        GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);
    
        // Enable and initialize the I2C0 master module.  Use the system clock for
        // the I2C0 module.  The last parameter sets the I2C data transfer rate.
        // If false the data rate is set to 100kbps and if true the data rate will
        // be set to 400kbps.
        I2CMasterInitExpClk(I2C0_BASE, SysCtlClockGet(), false);
    
        //clear I2C FIFOs
        HWREG(I2C0_BASE + I2C_O_FIFOCTL) = 80008000;
        }

    Hi Ralph,

    1) 4.7K ohm pull-up resistors, I have also tried 10k with no better success.

    3) The problem appears to occur only on the write after the 2nd byte. 

    4) Yes, I have verified the slave address.

    Here is the init code.

  • Hello Andrew,

    Your code for both initialization and sending of data looks solid., though I don't think you need the clear I2C FIFO line and there are driverlib calls for it too. I read through the device datasheet for the PCA9534, and the data sending sequence seemed fine to me just based on that.

    Given that you seem to have success with other devices, I think what you will need to do is take an o-scope and check some of the timings on the I2C lines vs the PCA9534 datasheet specifications. I was looking through E2E for any I2C drivers to reference and while I didn't find any, I found one post which mentioned timing tweaks solved an I2C issue. Given how solid your setup looks, I think that verifying the timings would make sense.

    Also for further clarity on why the SDA line shouldn't be an issue, the big reason that it is a non-concern for me is that while it pulses high, no clock period occurs during that time, so it's not like either slave or master would register the high value.
  • "Feel the pain" (of both Ralph & poster.)

    Indeed I2C was intended as a multi-device bus - yet when, "Issues such as this" (outside and beyond "normal" diagnostic efforts) arise - "KISS" dictates that the,  "Simplest possible set-up be deployed."

    As "timing" - rightfully I believe - rises in the diagnostic cue/que - I'd ask that, "All other I2C devices be, "isolated" from the I2C bus - as much as is possible/practical!"

    Firm/I have observed that on (reasonable number of) occasions - an "unaddressed I2C device" may, "cause an unwanted impact upon the I2C data transfer and/or ACK" - and (even while rare) - this potential (harm) is best "eliminated" ... just in case...

    Our past diagnostic efforts have identified that - several times - the "misbehaving Slave" responded - even though its (exact) I2C address was not generated - yet "enough I2C address bit matches" occurred ... to, "illegally enable that slave!"     (Temporary elimination of such "slaves" prevents ...)

    KISS - once again - "Rises to the Diagnostic Occasion" by, "Reducing the number of  "balls in the air!"   (design variables - here - for purists...)

    It proves also useful to (really) measure/confirm the power routings to each/every I2C device - on the bus.      Sometimes "parasitic power paths" may exist - and these, "open the I2C bus to "unanticipated consequences" - rarely desirable..."

  • All,

    Thank you for your help. I do believe that it is a timing issue. l have run test and found that certain bit patterns are more likely to cause an issue of the chip. I had used the PCA9534 in the past, I removed one of the PCA9534 from a previous project and put on the new project as comparison and the issue did not go away but the occurrence of the issue dropped significantly. I am going to continue looking into issues with the i2c path and the other devices on the bus.

    Thanks,

    Andrew Ward

  • While I2C (may) work (short-term) via "plug-board" or short inter-connecting SDA/SCL wires - rarely do "best results" arrive...

    Again - the removal of (potentially) impacting "outside influences" does much to, "Speed, Ease & Enhance" Diagnostic Success...

    Note too that I2C was intended as a,  "Short Distance Bus" - if  "cable connected" between MCU and "Slave board" - usually ~150mm proves, "Maximum reliable cable length."      It is always mandatory to "double-check" that "Grounds between Slave Boards/I2C devices and the MCU" - are robust and as direct as possible.