IWR6843AOP: I2C transfer fail

Hi Neil,

Thanks for reaching out! We can help you look into this.

Is this I2C slave or master? What is the exact transfer fail error?

Thank you,

Angie Mitchell

Hello Angie,

Thank you for your reply. It is I2C master. 

I am interfacing an external temperature sensor with IWR6843AOP with I2C interface. I could initialize and start communication without any problem. 

I am reading 258 bytes value from the RAM of this temperature sensor in every 26 ms. I2C_transfer( ) is used to read these values from RAM. But after sometime during communication I2C_transfer() returns false, which means "I2C Driver Transfer ERROR " and during next try for I2C_transfer the task of this I2C communication gets blocked. I believe it is because of last I2C transfer fail.

I have observed that if I lower the priority of I2C task than other tasks then this error comes more early and by keeping the I2C task at highest priority, error comes much later in communication.

Is there any way to reinitialize or cancel the failed transfer ? Or if you have any suggestions about handling this error, please let me know.

Thanks and Regards,

Neil

Hello Neil,

Do you have I2C_MODE_BLOCKING enabled?

Also, do you have a timeout? Is this project built on one of our SDK or toolbox projects, if so which one?

Here is a definition of I2C_transfer() in case this helps (comes from mmwave_sdk_03_05_00_04\packages\ti\drivers\i2c\docs\doxygen\html):

Perform an I2C transaction with an I2C slave peripheral.

This function will start an I2C transfer and can only be called from a Task context when in I2C_MODE_BLOCKING. The I2C transfer procedure starts with evaluating how many bytes are to be written and how many are to be read from the I2C peripheral. Any data to be written will always be sent before any data is read.

The data written to the peripheral is preceded with the peripheral's 7-bit I2C slave address (with the Write bit set). After all the data has been transmitted, the driver will evaluate if any data needs to be read from the device. If so, a Re-START bit is sent, along with the same 7-bit I2C slave address (with the Read bit). Else, the transfer is concluded with a STOP bit. After the specified number of bytes have been read by the I2C, the transfer is ended with a NACK and STOP bit.

In I2C_MODE_BLOCKING, the I2C_transfer will block task execution until the transaction completes.

Parameters

handle	A I2C_Handle
transaction	A pointer to an I2C_Transaction. All of the fields within transaction should be considered write only, unless otherwise noted in the driver implementation.

Returns

In I2C_MODE_BLOCKING: true for a successful transfer; false for an error (for example, an I2C bus fault (NACK)).

Thank you,

Angie Mitchell

Hello Angie,

Yes i have I2C_MODE_BLOCKING enabled. But I dont have a timeout. Can it be set in I2C_transfer?

Regards,

Neil

Hi Neil,

Thank you for the info. I would suggest not editing the I2C_transfer() function to be safe. Here are two things we can try:

1. Try increasing the time between samples (instead of 26 try 50ms, 100ms, and/or 150ms) and see if the error comes sooner or later when you change this.

2. within the i2c driver code (mmwave_sdk_03_05_00_04\packages\ti\drivers\i2c\src) you will find the source code which can be added to your project to be edited. In i2c_master.c is the function I2C_ISR() which may help you understand which error you are getting.

Thanks,

Angie Mitchell

Hello Angie,

Thank you for your answer and Sorry for my delayed response. Your suggestion was helpful in debugging I2C master interface. 

I tried your first suggestion and its independent of time between samples. It just made sensor response faster or slower. Whereas by reducing priority from 7 to 2, had generated this error more sooner.

With second suggestion I could debug in more detail and I saw that the problem occured in function SemaphoreP_pend(ptrI2CMCB->transferComplete, SemaphoreP_WAIT_FOREVER) in function I2CMaster_transfer(). The task could not recover after this function. Not sure why. 

Thanks and Regards,

Neil

Hi Neil,

I'm glad the second suggestion was helpful!

Are you able to monitor your i2c lines, maybe with a logic analyzer? Could you share some details about your physical i2c setup? Signal degradation could be causing an issue here. 

Thank you,

Angie Mitchell

Hello Angie,

Below is the Hardware setup of IWR6843 with Thermopile sensor.

The I2C signal after fail looks like this.

After fail, the data and clocks are unevenly separated as compared to normal stream. Not sure if its because of low task priority. Should I keep I2C task at highest priority. 

I think the signal distortion is not there. This is observed signal when priority of I2C is 2 to get error soon. But usually I keep at priority 7 which is highest in my project.

Regards,

Neil 

Neil,

Thank you for this info! I am going to reach out to an expert on our team for the i2c driver and get back to you on this with more information.

In the meantime, I am wondering if this is due to the amount of information you are transmitting and if it doesn't have time to finish the 258 bytes. Is there a way to test sending less data over?

Thanks again,

Angie Mitchell

Hello Angie,

Thank you for suggestion, but according to this thermopile read API, actually these 258 bytes should be read at once otherwise all successive data will get corrupted. It has block wise read algorithm and each block has 128 pixel, each two bytes and two bytes of register data that makes 258 bytes of total read and hence should be read at once. There are total such 8 blocks, that makes total 1024 pixel data. Each second I read 8 times these total 8 block

Thanks and Regards,

Neil

Neil,

Thank you for that information. I should have more info on debugging from our expert team soon.

Thanks again,

Angie Mitchell

Hi Neil,

Our team noticed that in I2CMaster_transfer function only I2C interrupt is disabled.

Can you try disabling all the interrupts and restoring after setting up I2C transfer using below listed HwiP API’s?

HwiP_disable()

HwiP_restore()

Thank you,

Angie Mitchell

Hi Neil,

Thank you for your patience and I'm glad you found a solution!

Thanks again,

Angie Mitchell