TMS320F28388D: EEPROM read issue, unexpected read cause I2C bus locked

Hi Hang,

Apologies for the delay, please give me another day to get back to you.

Best Regards,

Aishwarya

Hang,

Is the third word read random or the next expected data being read too early? Do they have any delays inserted after the second data is being read? Make sure the RRDY flag is being properly handled after the second read to prevent future reads from occurring. 

Customer can use external EEPROM with control card, if needed.

Best Regards,

Aishwarya

Hi Aishwarya,

I believe the EEPROM on CC only connects to ESC, I2C module has no access to it.

The third word is next expected data. We are looking into the RRDY flag or using non-repeat mode since the data length is fixed.

Regards,

Hang. 

Hang,

Hang Yang said:

I believe the EEPROM on CC only connects to ESC, I2C module has no access to it.

Yes, that's correct. I was referring to an external EEPROM, not the one on the CC for this reason.

Is repeat mode enabled? If so, can customer try without it and see the results?

Let me run this example on my end and get back to you. If they do not use the function, and just do the operation, does the same issue occur?

Best Regards,

Aishwarya

Hi Aishwarya,

They tired running ex2 which uses non-repeat mode. There is no issue running the example. However, when they integrated the ex2 into their application, the issue still happens, but not all the time (still the chance is high).

Customer's interrupt has been well scheduled so they can not use extra interrupts. The interrupts in ex2 has to be removed.

Their data read code is like below, this code can reproduce the I2C lock (see the end of the waveform) like below using control card.

Could you please help looking at it?

Not sure if the code is correct, I am still checking it. In case it's not correct, could you please help provide a simple data read example code without interrupt? 

Regards,

Hang.

Hang,

I'm assuming this is being used instead of the function in the original question. The code itself looks good, but instead of just adding delays, I think it would be good to add the if statements from example #2 to make sure we are sending the STOP condition only if the address setup phase is completed. 

Also, in F2838x, it should be the I2C_ControllerReceiver() function not I2C_MasterReceiver(). Older devices use I2C_MasterReceiver(). Maybe this is the issue as well?

Best Regards,

Aishwarya

Hi Aishwarya,

Aishwarya Rajesh said:

it should be the I2C_ControllerReceiver()

I am using  it should be the I2C_ControllerReceiver() now.

Aishwarya Rajesh said:

it would be good to add the if statements from example #2 to make sure we are sending the STOP condition only if the address setup phase is completed. 

ex2 is sending STOP condition after the read phase is complete, seems there is no stop between address setup phase and read phase.

I attached the waveform when the I2C lock happens. 

This happens at the end of the read phase, where the read process stopped after only reading one byte.

As you can see in the right panel, the correct pattern is like setup write - two bytes - setup read - two bytes, but at the final round, there is only one byte after setup read. 

Since the error is happening at the end of the read phase, it should have nothing to do with weather using if statements to do the transition of the phases.

Do you have any idea what might causing the above I2C lock?

This can be reproduced by replacing the while loop in ex2 with above codes. the numofbyte is set as 2.

Regards,

Hang.

Hang,

I will look into this more on my side and see if I can reproduce it. I will be out office until early next week but will get back to you as soon as possible. Thank you for your patience!

Best Regards,

Aishwarya

Hang,

In addition to disabling I2C_REPEAT_MODE, ensure that you are setting the I2CCNT register to the correct value of the desired number of bytes to be transmitted and received. What is value of I2CCNT?

Best Regards,

Aishwarya

Hi Aishwarya, 

I set it as 2 via I2C_setDataCount() API.

Hi Team,

Update the progress.

I am able to identify the conditions to reproduce issue.

It's about the timing of setting STP bit. In my case, I use the driverlib api to set STP and monitor its timing with GPIO, and control its timing with delay like below:

With this, we can observe timing of setting STP like below (The stop condition is generated later and the next frame comes normally)

It turns out that if the timing of setting STP is close to the "last two clocks" of the current frame, this would cause the SCL to be locked as low.

Starting from above waveform, if I add 1us delay to STP, the SCL would stuck low.

In the meantime, the level of SCA when locked depends on the EERPOM response to the read. If it response zeros (I write zero to it in advance) I would be stuck low.

Regardless of the SCA level, the SCL is locked anyway, which is unexpected. If both SCA and SCL are locked low, and user reset the I2C at this point, SCL will go high and SCA remains low, the I2C bus would remain locked and only I power cycle on the EEPROM can unlocked it.

In actual application, there would be no purposed delay before setting STP, however, there would be interrupts that halt the I2C in background, and the effect is similar to a delay.

By tunning the delay of setting STP, I find a range that setting STP would cause SCL lock.

What's the mechanism causing the SCL locked in this case?

If customer keep using repeat mode, how to control the timing of setting STP to avoid SCL lock?(without using any interrupt)

Regards,

Hang

Hang,

Thanks for the update. We're going to look into this with our design experts and get back to you. Thank you for the detailed reponse.

Best Regards,

Aishwarya

Hang,

Upon further investigation, we see that the RRDY status flag is being set (as part of the internal I2C module flow), but the bit is not being cleared in SW (since the assumption is to clear flags only set by the user) which is locking the bus. Please add the following lines of code to the I2C_ControllerReceiver() function in the  i2cLib_FIFO_polling.c file as shown below:

    I2C_clearInterruptStatus(I2CA_BASE, I2C_INT_RX_DATA_RDY); // Needed only in INT mode
    I2C_clearStatus(I2CA_BASE, I2C_STS_RX_DATA_RDY);

Similar idea applies for the I2C_ControllerTransmitter() function where you'd clear XRDY flags. Let me know.

Best Regards,

Aishwarya

Hi Aishwarya,

We tried clearing RRDY today like below

However, the lock still exist.

• Could you please check if we are clearing RRDY correctly?
• If this works on your side, could you provide a screen shot like above with a GPIO flip indicating the STP timing?
• Could you share a project to demo how clearing RRDY can solve the issue?

Regards,

Hang.

Hang,

Allow us to keep this thread open as debug this further offline. Will update this thread with final solution for visibility.

Best Regards,

Aishwarya

Hang,

I'm going to close this thread but please feel free to message on the email chain or make another thread if the customer has any other questions.

Best Regards,

Delaney