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.
Hello,
We are developing a new device using CC1352R and accelerometer MC3635. The project is created with SDK 6.10.00.29. During the DVT testing, we noticed glitches during the execution of the functions I2C_Open() and I2C_Close(). This causes a serious problem with the accelerometer, because its output registers are always locked when there is a START condition on the line till to the moment when a STOP condition is detected. Those glitches generate a FALSE START condition.
This issue is already reported very well in the forum:
The official response from TI is the issue is fixed in the latest SDK 7.10, but it is not.
Today we tested this SDK. The situation is a little bit different, but the glitches exist.
1. When the default state of the pins SDA and SCL is "Input with pullup", the glitches are only after the execution of the function I2C_Close() (25us after the last STOP condition). The duration of the glitches is 200nS and additional rising time up to 200ns.
2.When the default state of the pins SDA and SCL is "Output with High state", the glitches are before the I2C transfer during the execution of the function I2C_Open() (40us before the START condition). The duration is again 200ns and additional rising time up to 200ns.
This issue is critical for us, because the output registers of the accelerometer are locked constantly after every I2C transfer.
What are your recommendations to fix this issue? Is there a way this issue to be fixed entirely in your SDKs 2 year after the moment when it was introduced?
And one last question.
Why the execution time of the function I2C_Open() is to long - 140us typ?
By the way, all functions XX_Open() have the same or similar execution time. For one SPI or I2C transfer which take 2us or 10us, we have an execution time 140us ONLY to open an instance to the module.
Thank you very much for your responses in advance.
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(¶ms); 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