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.

TIDA-01168: I2C issue

Part Number: TIDA-01168

I have a couple questions regarding the I2C issue mentioned in the user manual.

"Testing during development shows that, under certain conditions (high output current, four-phase operation), the I2C temperature sensors randomly fail to send ACK to the bus. This occurrence happens approximately six times per hour due to noise on the I2C bus. Current firmware is able to recover from such event."

(1) Has there been a recent update to the software or hardware such that the 'ACK' error no longer occurs? I'm assuming the last sentence in the above paragraph is a 'fix' in the software.
(2) I would like to resolve the I2C issue as I'm planning to add more nodes on the I2C bus. My first attempt at resolving the issue is to replace the pull-up resistors from 10k to say 2.2k. I would like to test before and after results with the fix. What is the easiest way to catch this 'ACK' fault during operation?

  • Hello Antonios, 

    thank you for your interest in TIDA-01168. Let me answer your questions.

    (1) Has there been a recent update to the software or hardware such that the 'ACK' error no longer occurs? I'm assuming the last sentence in the above paragraph is a 'fix' in the software.

    -> We released only one version of the firmware. This very version from 28-Jun-2017 incorporates the "workaround". There is a function "hal_I2CWait" in hal.c that does the job. 

    /* Wait until I2C is ready */
    void hal_I2CWait(void)
    {
        /* Wait for Stop condition bit to be zero. */
        while (I2caRegs.I2CMDR.bit.STP == 1) { asm(" NOP"); }
    
        /* Wait for Bus Busy to be zero or until error happens */
        while (I2caRegs.I2CSTR.bit.BB == 1)
        {
            /* the thing is that the power stage in DC/DC is quite noisy for i2c
             * and there are error on the bus (no ACK or Arbitration loss). It is
             * just temperature measurement therefore the error is ignored and only
             * the error counter is increased. PLEASE DO NOT COPY AND PASTE
             * THIS DIRTY SOLUTION TO ANY SERIOUS APPLICATION !!! USE ISR INSTEAD ! */
            if ((I2caRegs.I2CSTR.bit.NACK == 1) || (I2caRegs.I2CSTR.bit.NACK == 1))
            {
                I2caRegs.I2CMDR.bit.STP = 1; /* Send a STOP */
                I2caRegs.I2CSTR.bit.NACK = 1; /* Clear NACK flag */
                i2c_err_cnt++;
                break;
            }
        }
    }

    (2) I would like to resolve the I2C issue as I'm planning to add more nodes on the I2C bus. My first attempt at resolving the issue is to replace the pull-up resistors from 10k to say 2.2k. I would like to test before and after results with the fix. What is the easiest way to catch this 'ACK' fault during operation?

    -> This is tough. I assume that the problem with ACK is caused by noise injection on the i2c bus. Unfortunately, the bus does not have push-pull drivers and currents injected in the bus cause drops on pull-up resistors. It may happen that the state-machine in i2c slaves react to it and fails to respond properly. I remember that I lowered pull-up resistors down to 1k but it did not help much hence the workaround. I think analog or SPI sensors would provide more consistent results. Also, the PCB layout plays an important role here.

    I hope this helps,

    Best regards, Jiri