CC1352R: I2C_Open() and I2C_Close() functions generate again glitches in the latest SDK - 7.10

Hi Angel,

I have witnessed that issue some time ago, and have notified the team in charge. I let them know that you are encountering the issue as well.

As of the execution time, I will try to go and find some answers.

Regards,

Arthur

Hi Angel,

I have provided test-cases that reproduce both glitches to the team in charge. They are looking right now.

In the meantime, how are you measuring execution time, are you measuring with a GPIO being toggled before and after I2C open? Just to make sure we are on the same page.

Regards,

Arthur

Hi Arthur,

The execution time can be checked by different methods . For example, in Debug mode in CCS counting the clocks from the beginning of the function I2C_open() to the beginning of the function I2C_transfer().

The second method could be this issue with the glitches during the execution of the functions I2C_open() to the first falling edge of the SDA line (START condition). Also you can measure the execution time when the function I2C_close() will be executed. It is smaller, but according to me it is to long ONLY to close one instance to the I2C driver.

Please see the attached picture. It demonstrates the glitches before the i2C_transfer. The test is done with the older SDK 6.10, but the result is similar with latest SDK 7.10.

Your idea to toggle a pin also is very good.

Hi Angel,

I will look at the timings, because it seems like I am not getting the same results.

As of the glitch, it has been reproduced on my side and documented. Now we will have to wait for a fix.

Regards,

Arthur

Hi Arthur,

I did some measurements for you. They are done using CCS V12.5 and SDK simplelink_cc13xx_cc26xx_sdk_6_10_00_29. 

1. Blocking mode - I2C_Open() - 8960 clocks or 186.6us typ.

                               I2C_Close() - 1654 clocks or 34.5us typ.

2. Callback mode - I2C_Open() - 6284 clocks or 130.9us typ.

The execution time may vary with few microseconds.

Also in Debug mode during the execution of the function you can see where are the longest execution time.

Hi Angel, I'll measure ASAP and I'll come back to you today.

I do not think that this is something that can be fixed though.

As of the actual glitch, I will check the status of that.

Regards,

Arthur

I typically measure 50 uS on I2C_open (blocking mode), and 24 uS on I2C_close, with the following code.

void *mainThread(void *arg0)
{
    /* 1 second delay */
    uint32_t time = 1;
    int status = 0;
    I2C_Handle i2cHandle;
    I2C_Transaction i2cTransaction = {0};
    // initialize optional I2C bus parameters
    I2C_Params params;
    uint8_t writeBuffer[3];

    I2C_Params_init(&params);
    params.bitRate = I2C_400kHz;

    writeBuffer[0] = 0xAB;
    writeBuffer[1] = 0xCD;
    writeBuffer[2] = 0xEF;

    i2cTransaction.targetAddress = 0x50;
    i2cTransaction.writeBuf = writeBuffer;
    i2cTransaction.writeCount = 3;
    i2cTransaction.readBuf = NULL;
    i2cTransaction.readCount = 0;

    /* Call driver init functions */
    GPIO_init();
    I2C_init();
    // SPI_init();
    // Watchdog_init();

    while (1)
    {
        sleep(time);

        GPIO_write(CONFIG_GPIO_LED_0, 1);
        i2cHandle = I2C_open(CONFIG_I2C_0, NULL);
        GPIO_write(CONFIG_GPIO_LED_0, 0);

        if (i2cHandle == NULL) {
            // Error opening I2C
            while (1) {}
        }
        
        // Will not ack as no device is connected
        status = I2C_transfer(i2cHandle, &i2cTransaction);

        if (status == false) {
            // Unsuccessful I2C transfer
            if (i2cTransaction.status == I2C_STATUS_ADDR_NACK) {
                // I2C target address not acknowledged
            }
        }

        GPIO_write(CONFIG_GPIO_LED_1, 1);
        I2C_close(i2cHandle);
        GPIO_write(CONFIG_GPIO_LED_1, 0);
    }

}

If you own a Launchpad device, could you try and see if you get the same results as me?

Regards,

Arthur

Hi Arthur,

You are right. The execution time of I2C_Open() is 50.4us and 23.6us for I2C_Close(). They can be improved (reduced) if the optimization level is "fast".

Only a few comments.

1. Your example code works with the latest SDK 7.10.01.24. The name of the variable "slaveAddress" is updated "targetAddress".

2. SDK 7.10 comes with new RTOS - tirtos7 and new compiler - ticlang.

3. Our project works with the previous SDK 6.10.00.29, tirtos and different compiler.

By the way, the log file from the logic analyzer is for bitrate 100kHz and 2 bytes I2C transmission (18 clocks). Not important.

But even with these significant improvements in the last SDK, it is strange. 

In your example (2 bytes I2C transmission, 400kHz bitrate, 18 clocks, duration 45us) and additional execution time 74us only to open and close one instance to the I2C module. The situation is worse for the SPI transactions where the bitrates could be 5Mhz, 10Mhz even higher. With these modern SDKs and RTOS this is the results.

Let's see what the TI team will do about the glitches.

Thank you very much again for your help and cooperation.

Angel

Hi Arthur,

We found another I2C Slave device (LED driver) that doesn't work properly because of these False glitches generated by the I2C_Open() and I2C_Close() functions. Obviously this issue should be fixed somehow in the future. For now, there is a method to fix it, but we lose the options to work with different settings of the I2C interface (baud rates, Callback or Blocking mode) when on the I2C bus there are different Slave devices.

One more question. In Callback mode, we have the option to transmit I2C Chained transactions. All examples are with 2 or 3 I2C transactions. All of them will be placed in internal queue. The question is how deep is this queue? What is the maximum number of the chained I2C transactions? Is there a limit?

I didn't find any information about this in all available documents.

Thanks in advance for your response.

Angel

Hi Angel,

I absolutely agree, this must be fixed as soon as possible.

There is not hard fixed limit to the number of transactions you can queue (except memory ones), as the driver (I2C.c) will simply use the pointer to the transactions that you have defined, which are allocated in memory. This is likely why you did not find information about it.

Regards,

Arthur