TMS320F28069: F28069 i2c hang up issue

Hi Jackson,

Does this noise & hanging happen at the same spot on every iteration? It looks like the noise being seen is only affecting the logic analyzer. The slave & master device seem OK, finishing the byte and moving onto the next bytes.

As for the line holding issue, is it both SCL and SDA being held low? Does the communication continue after some time or is it held low indefinitely? Can you provide a waveform close-up at the end where the line holding begins for me?

May also want to check the I2CMDR and I2CSTR registers of the C2000 after this holding occurs to understand the state of the I2C module.

Best,
Kevin

Hi Kevin

This noise doe not always happen on the same spot when I polling this 64byte command.

While this issue happen, the DATA and CLK will be held low at the same time, and it will be held low indefinitely until my timeout expired .I run the i2c reset (I2CMDR.bit.IRS=1)to release the i2c bus when timeout.  

My device is supplying the power to sever and run the i2c communication at the same time, I can not go to monitor the I2CMDR and I2CSTR registers on live.

See my attached file as below. Thank you.

Hi Jackson,

Thank you for providing the additional screenshots. There are two issues being seen on the logic analyzer and I'll discuss them below separately.

1. Mid-byte noise on SDA line caught by Logic Analyzer.

The instances of noise being caught on the SDA line are definitely confusing the logic analyzer, which is why the sequential bytes (blue highlighted HEX format) are completely misaligned. However, this does not seem to be corrupting the actual I2C comms (presumably) since the clock and data continue to be valid for several bytes after. Larger noise could lead to actual I2C comms corruption, i.e. unintended START/STOP conditions can occur in the middle of a byte. The C2000 I2C module does have some internal noise filtering to prevent this, but ideally you want to limit the noise on your I2C bus as much as possible in your system design.

2. SCL and SDA lines being held low indefinitely mid-byte.

This issue could be caused by noise being on the lines, causing the i2c communication to become out of spec resulting in confusion on the bus.

The "External Slave Device Hanging the Bus by Holding SDA Low" section in the below wiki may be useful to you. The context is if the C2000 device was the master, but I think it might still give you some insight and ideas.

http://processors.wiki.ti.com/index.php/I2C_Tips

Some questions for you:

1. Is your system environment inherently noisy?

2. What frequency is your master device driving on SCL?

3. Do you have proper pull-up resistance on both the SDA/SCL lines? If you're using the internal C2000 pull-ups I'd recommend against it for I2C.

4. Do you know the bus capacitance? Do you have any resistance in series to help with voltage spikes (could maybe try this, related resources available online)?

Best,

Kevin

Hi Allen

Thanks for your link.

See my update as below.

1. Is your system environment inherently noisy?
Yes, I have three power supply units parallel together to supply power to sever, and they run the i2c communication.

2. What frequency is your master device driving on SCL?
My Master communication frequency is 100K.

3. Do you have proper pull-up resistance on both the SDA/SCL lines? If you're using the internal C2000 pull-ups I'd recommend against it for I2C.
Yes, we have 10k pull-up resistance on both SDA/SCL.

4. Do you know the bus capacitance? Do you have any resistance in series to help with voltage spikes (could maybe try this, related resources available online)?
We have a RC filer on the both SDA/SCL (22R and 10PF). Our EE engineer will help to try this.

Thank you.

Hi Allen

See my update as below

I have 2 PSUs(Power Supply Unit) parallel together and communicate with PC tool(Master). My Master is always polling the data with PSU_#1.

And the PSU#2 is always in the idle state.

While the issue happen(Master CLK & DATA HOLD LOW),we notice the is a signal on the PSU#2. This signal seems to cause PSU#2 to see the

General Call and is forced to response on the I2C bus. After few bytes later the PSU#2 seems to hang up.

Observation.

1. I only polling the data with PSU#1, but the unexpected signal on the PSU#2 cause it to response (General Call) even it is on the idle state.

2.From the signal the I2C bus is hang up due to PSU#2(Idle state) instead of PSU#1(Working state)

Question:

1. The I2C documents has few description about the General Call on F28068, could you share more documents about this?

2. The unexpected signal to cause the PSU#2 to reply due to the General Call . Before our hardware engineer can resolve this unexpected signal, what can we do for the "General Call" on the firmware side, even if this command happen by accidently? Can we reject this command ?

Please help to advise for this. Thank you.  

Hi Jackson Chen,

A General Call is not something specific to our I2C module. You should read the NXP (used to be Philips) I2C spec for more information.

The General Call is only used for sending "general" information from a master to all slave devices, and whatever slaves need the information ACK back. Slaves that don't need it will ignore the information. There shouldn't be any data being transmitted back from a slave device back to the master.

Why are you using a General Call? I'd imagine the I2C modules on the PSUs have specific slave addresses.

Best,
Kevin

Hi Kevin

We don't use the General Call command. The master always ask a command of 64 bytes data from PSU#1. The 0x00 data are piece of the 64 bytes.

An unexpected signal happen on the PUS#2 to cause a Start Bit and then PSU#2 see the 0x00 data on the I2C bus.

1. 0x00 data are piece of PSU#1(address 0x40) send to Master.
2. The unexpected signal to cause the Start bit on PSU#2(address 0x41)

Actually, we have a hotswap IC(PCA9512A) after the PSU. Then the I2C parallel together after the hotswap IC.

We notice the unexpected signal(caused the start bit) seems to be pulled up by the hotswap IC on the PSU#2(before it, it's a small glitch).
From the Waveform the PSU#1 does not see this signal, but it appear on the PSU#2.

By the way, we only expected the master communicate with PSU#1.
At the same time of PSU#1 send 64 byte data back to master, PSU#2 see the General Call and then it response to I2C BUS.
This cause the I2C bus to be confused.
.
Because the master only communicate with PSU#1. We don't want PSU#2 to response to General Call command which caused by (Hotswap IC unexpected behavior
Do you advise any firmware solutions that PSU#2 will not affect the I2C bus(Master is communicating with PSU#1)?

Hi Jackson Chen,

OK I see. Do you have the hotswap on both PSU#1 and #2 sides before the parallel I2C interface? Do you know why the hotswap is causing the SDA line to go high like this? I'd contact NXP about it if this is an unexpected behavior.

Out of curiosity, why is PSU#2 on the I2C interface if only the master C2000 and PSU#1 are communicating?

As for firmware, I don't really have an understanding of why PSU#2 is on the I2C bus, could you further explain this so I can provide better suggestions? Do you have a screenshot of this issue at the master device interface? The glitch doesn't appear on the PSU#1 data line so I'm wondering if it appears on the line at the master.

If this unintended START condition happens at the master interface, I don't think there's too much you can do to ignore it.

Best,
Kevin

Hi Jackson Chen,

No worries! OK, happy to hear you were able to find a possible root cause.

Best,
Kevin