TMS320F280037: I2C communication stuck

Hello Luke,

Can the customer provide their I2C configuration? I mainly need to see their addressing and data format they configure for the I2C peripheral, but any other configurations they do will be useful.

Best regards,

Omer Amir

Luke,

Did customer try to understand glitches observed on the SDA line? How strong is your pull-up and what is the bus capacitance? Also, in your C28-I2C code, have you enabled I2CMDR.FREE = 1. If not, ask customer to do so. This will ensure that I2C transaction doesn't stop in middle of communication when CPU hits a debugger halt.

Based on the scopeshot, it looks like customer is trying to perform two back to back controller (master) transmitter without stop condition. I don't understand why you need repeated START after first controller (master) transmitter? Since you are already in master transmitter mode, why not just transmit more bytes on I2C bus.

You shouldn't be doing the below procedure to revive the SCL pin.

Luke Chen said:

This problem can be resolved by configuring I2C clock pin to GPIO function, outputs a GPIO low and then a GPIO high signal, then configures this pin back to I2C clock function and restart I2C communication. This problem is not easy reproduced, how should we debug this issue please? Please advise your comments, thank you.

Regards,

Manoj

Manoj,

No capacitance and no external pull-up resistors attached to the I2C bus, my customer just enable internal pull-up of SCL and SDA pins, is it possible to cause this clock stuck problem, because no external pull-up?

Based on the scopeshot, my customer sends a stop condition before sending next start conditioin, please review the scopeshot again. Actually he sends five different slave addresses and data, sometimes I2C communication stuck at the fourth slave address read/write bit, but we are not sure is it always stuck at the fourth slave address because it is not easy to duplicate this problem.

Regarding I2CMDR.FREE, do you mean we should enable I2CMDR.FREE = 1 even when the system is standalone executing?

Regards,

Luke

Luke,

Noisy glitches in SDA line is a cause of concern.

Internal pull-up on I2C pins are really weak pull-up make I2C transactions vulnerable to noise. I would recommend customers to use stronger 2.2 K external pull-up.

Luke Chen said:

Regarding I2CMDR.FREE, do you mean we should enable I2CMDR.FREE = 1 even when the system is standalone executing?

If you are running standalone, then this doesn't matter.

Regards,

Manoj

Manoj,

If we set the IRS bit of I2CMDR register to zero to set I2C module, do we need to add delay time before setting this IRS bit to 1?

Regards,

Luke

Luke,

You need to hold the I2C in reset when you are configuring the I2C and re-enable when you are done with I2C configuration. There is no minimum stipulated time.

Are you using this I2C reset (IRS) bit as a workaround to get your I2C pins working? I know you are running the application in standalone mode. But, have you ever tried reproducing the issue when debugger is connected?

Regards,

Manoj

Luke,

You need to hold the I2C in reset when you are configuring the I2C and re-enable when you are done with I2C configuration. There is no minimum stipulated time.

Are you using this I2C reset (IRS) bit as a workaround to get your I2C pins working? I know you are running the application in standalone mode. But, have you ever tried reproducing the issue when debugger is connected?

Can you have customer have stronger external pull-up resistor? Using internal pull-up resistor (weak pull-up) makes your I2C susceptible to noise.

Regards,

Manoj

Manoj,

This project is close to production, so my customer uses one standalone machine to do system ON/OFF relibility test and sometimes this I2C problem occurs, this problem cannot be duplicated when CCS debug mode, or maybe we should say too difficult to reproduce this problem in CCS debug mode.

The original project is developed by using F2808, I2C module is the master and used to communicate with external FPGA, the I2C module works well then. For new generation product, my customer selects F280037 and migrate the project from F2808 to F280037, this I2C problem didn't happen until the standalone system ON/OFF test.

This afternoon my customer adds the external I2C pull-up resistors, use 2 KOhm pull-up on both SCL and SDA pins. However, the I2C problem occurs again after about one-hour ON/OFF test. But this time my customer doesn't disable the internal pull-up, I think it doesn't matter to enable or disable the internal pull-ups since we have external I2C pull-up resistors, it this correct?

You mentioned using weak pull-up will makes the I2C susceptible to noise, what will happen to I2C module in this situation, will it stop working?

Do you have any comments on this situation please?

Regards,

Luke

Luke Chen said:

You mentioned using weak pull-up will makes the I2C susceptible to noise, what will happen to I2C module in this situation, will it stop working?

Noise on SCL / SDA line can possible corrupt the I2C state machine and hang the communication.

Can you schedule a webex call? I need to know more information about this problem. Once we resolve the issue I can post the resolution here.

Regards,

Manoj