P82B96: SDA lock after the slaves ACK's

Hey Lucasz,

Are you able to provide the schematic around both P82B96 devices?

Are you able to take a look at the "L" sides on an o-scope? For one side to latch, either S side has to be below 0.6V and stay below that or L side has to stay below 0.45*Vcc.

Because this problem came up over time I am suspecting the L side could have been damaged due to ringing when pulling from high to low and generating an undershoot below the specified maximum under voltage.

Thanks,

-Bobby

Hello Bobby,

Here are the schematics:

The HDC1010 end:

The MCU end:

I will be able to provide scope views from LDA and LCL at monday, although, from a setup which is still working, as I had to disassemble that one. I hope it will shed some light however, Do you have any insights after seing the schematics? A note from me: The LDA/LCL pull-ups in my config are only connected at one end.

Hey Lucasz,

I don't see anything from the schematic that would point out why this is happening.

I looked again at your waveform and what I do see is it doesn't look like the slave (and the P82B96 connected to slave) is the one responsible for the SDA line latching low. The waveform is suggesting the master is the one actually latching low.

Slave waveform buffers it's output to about 0.7V so that means the L-DA is being driven low (below 0.45%Vcc). Master waveform shows after the ACK it looks like the master is latching the line. If the slave were latching the line then master would see 0.7V on the P82B96 attached to the master. (P82B96 should not be capable of generating a voltage below it's offset at around 700mV because it can only pull low to 700mV).

My next step here would be to double check code and to remove the P82B96 on the master side and repopulate a new one (maybe our device was damaged and can't receive signals properly). If it works with a new P82B96 then it was our device (damaged?) but if we are still seeing issues I would investigate the code further.

Edit: you may also want to try testing if you can pass a low to the master side with just the P82B96 device. With the device turned on, pull L-DA low (u can just tie this to GND) and see if SDA is pulled to 700mV.

Let me know what you find out.

-Bobby

thanks for answer,
I also thought that maybe master could be the case here, for the reasons you have pointed out. But even if he is doing that, it is somehow connected with the fact that there are P82B96'a in the system, because if I remove them and connect HDC1010 directly over the long cable, it works fine. They code is very standard, used for many different slaves. I also tried decreasing speed, as well as decreasing pull-up values- did not help... Is it possible that master wrongly interprets 0.7V low signal? What would make him hold the line in general?

Hey Lucasz,

"Is it possible that master wrongly interprets 0.7V low signal?"
It can be possible though I2C standard is a low is defined as 30% of Vcc or lower which in this case is about 1V which 700mV is below. If there is a line in the code which states if the ACK voltage the master sees is not below say 0.5V then I could see this as a possibility but that just seems like a funny mistake to make.

"What would make him hold the line in general?"
That's a tough question as the master is usually the one that is controlled directly. Typically master pulls low on SDA during an ACK, during a start condition, during communication when needing to pass a low, and when initiating a stop condition. None of which seem to be the case here as SCL goes high.

The waveform does also show something kind of funny.... The master looks like it pulls directly to GND during communication and pulls down to GND again immediately after he receives the ACK (I think he's trying to pull low to initiate a stop condition) but then tries to release but then SDA gets stuck, the signal has a small step to it, like a 100mV offset or something. I'm wondering if there is some leakage current coming from somewhere when this happens......

Any other devices on the master side other than the MCU and the P82B96?

Are you able to repeat the issue and then remove the master while the line is still stuck with our device still on? If the bus remains stuck then that will also show our device is malfunctioning and there is another path to GND else where through the device. If the device releases after the master is removed then it will also show the master is responsible for the low.

Thanks,
-Bobby

Hello Bobby, thanks for answer.

It can be possible though I2C standard is a low is defined as 30% of Vcc or lower which in this case is about 1V which 700mV is below. If there is a line in the code which states if the ACK voltage the master sees is not below say 0.5V then I could see this as a possibility but that just seems like a funny mistake to make.

Thats not it for sure, I have no control over this in code, as I am using the I2C hardware peripheral of ARM MCU.

The waveform does also show something kind of funny.... The master looks like it pulls directly to GND during communication and pulls down to GND again immediately after he receives the ACK (I think he's trying to pull low to initiate a stop condition) but then tries to release but then SDA gets stuck, the signal has a small step to it, like a 100mV offset or something. I'm wondering if there is some leakage current coming from somewhere when this happens......

Yes now hen you said it I have noticed it as well. But this wouldnt it indicate that its not the MCU's fault?

It would be hard for me to remove the master as it is soldered to the PCB with 100 pins. I have however performed such test before posting this: As soon as this occurs, I can no longer use I2C, as SDA is stuck low. So instead after occurance I tried to put the SDA and SCL lines in analog input mode. This way if they were open-drain low for some reason, they would let go and the pull-ups would take the line high. That did not happen however. The only way to "restart" everything, way to make a software reset, and I have to point out that at that point, the power for P82B96 is being cycled, as well as for other external peripherals.

Does this give you any hints?

Hey Lukasz,

Sorry for the delayed response.

"Yes now hen you said it I have noticed it as well. But this wouldnt it indicate that its not the MCU's fault?"
-This is something I am not sure about. It could be possible the device was damaged somehow and P82B96 pulls low to GND if Rx is pulled low while Tx is internally disabled.

"So instead after occurance I tried to put the SDA and SCL lines in analog input mode. "
Can you elaborate on this? I'm not so sure I understand. Do you mean you made the MCU port connected to the SCL/SDA lines an analog input? (tri state mode)?

Can you pull CON2 pin 2 (board that connects to MCU) to GND and probe CON1/CON3 pin 4? MCU does not need to be powered for this but P82B96 does. I would like to see if the SDA line on the master's side pulls low to GND or if it pulls low to 700mV like we expect it to.

Thanks,
-Bobby

Hey Bobby, no problem at all.

Can you elaborate on this? I'm not so sure I understand. Do you mean you made the MCU port connected to the SCL/SDA lines an analog input? (tri state mode)?
Yes, you understood correctly. As soon as this occurred, I reconfigured the SDA/SCL pins to be tri state (High-Z), hoping that the pull up resistor on SDA line would pull it up. But that did not happen.

Can you pull CON2 pin 2 (board that connects to MCU) to GND and probe CON1/CON3 pin 4? MCU does not need to be powered for this but P82B96 does. I would like to see if the SDA line on the master's side pulls low to GND or if it pulls low to 700mV like we expect it to.

Yes, I would be happy to make this experiment, but the problem is I dont have this exact piece of problematic PCB anymore. On the other ones I have so far, this problem doesnt occur. I am wondering either there is any possibility to provoke this to happen?

Hey Lucasz,

"Yes, I would be happy to make this experiment, but the problem is I dont have this exact piece of problematic PCB anymore. On the other ones I have so far, this problem doesnt occur. I am wondering either there is any possibility to provoke this to happen?"
-I see, so it's one of these kind of problems..... This makes me think that the root cause is our device due to some sort of damage over time...

Can you get two sets of scope shots for me? Use the master to communicate and let me see the SDA/SCL on that side (zoomed in to the transition where we go from high to low of both clock and data). I am interested to see if we have ringing and the undershoot is violating the absolute minimum voltage for the device. (The undershoot only lasts for a few nano seconds but over time it can cause damage)

The second scope shot should be the same thing but on the TX/RX-TY/RY pins closest to the master. I suspect the ringing could be worse here.

Thanks,
-Bobby

Hi,
Yes I can definitely get those shots for you at Monday, thank you. The only limitation is that they will not be from the same run, as I have only 2 channels available.

Hello Bobby,

Here I am uploading the waveforms from a working PCB:

Master side:

Another run, this time middle side (LDA/LCL):

And slave side (HDC1010):

Please let me know either you have any conclusions.

Hey Lukasz,

I don't actually see any issues in the scope shots you've showed me but it may help if we can zoom into one of the transitions from high to low. (resolution of your o-scope could also be a possibility).

Here is an example of what I am talking about, here the signal when it transitions from high to low causes undershoot. If the undershoot is large enough then the device could be damaged. Sometimes strong pull down FET from a master (like a FPGA) can cause this to happen as well due to the very fast change in current. V(L) = L*di/dt so if there is a large enough inductance (like from a cable) or a fast change in current (like from a strong pull down from an FPGA) then we can see large undershoots.

Thanks,

-Bobby

Hello Bobby, thank you for answer.

Yes, this situation is hard to debug since that PCB is not available anymore. It is hard to figure out which part was causing the problem. There is additional uncertainty caused by the following facts:

1. When The P82B96 device was "jumped" (or removed) from the circuit, the circuit worked.
2. When this same P82B96 was used with a different MCU, that system worked.

So, its like you cannot say for 100% either the P82B96 is faulty or MCU.

Hi Lukasz,

I was just curious since some time has gone by - have you had any luck in narrowing down a root cause for this issue? If not, are there any other components on the I2C bus of the master side? I ask because when the SDA voltage is held low it seems to be a little higher than the master device typically drives and lower than what the P82B96 drives. Maybe there is some other component that is getting locked up and holding the line low?

If you keep toggling SCL, will the SDA line eventually release?

Max