Kinetis I2C Slave: SCL being driven and possibly causing latch-up with Isolator

[scottthompson]

Greetings,

We use many different Kinetis K-series MCUs, but the version that I am discussing here is the MK10DX128VLF5.

These K10 devices are I2C slaves, and the I2C driver is a fairly lean slave-only driver.  An i.MX53 SoM is on the B-side of the isolator, and the K10 is on the A-side of the isolator (higher voltage level than the SoM).  According to many "isolator" datasheets, one must put the higher voltage side on the A-side of the isolator due to its change in voltage levels to help prevent lockup (as can occur when trying to use anti-parallel drivers to achieve bi-directional communication).  This voltage difference/requirement is best documented in the Silicon Labs' Si8606 part.

What we are experiencing is an I2C bus lockup especially during EMI/EMC testing (EFTB is a major culprit, 2kV).  Troubleshooting has led us to believe it is a combination of the K10 and the Si8606, although other isolators are supposedly susceptible to similar lock-up.  Where the K10 might be affecting this is when it actively tries to drive the SCL line, even though it's a slave device.

We are observing the K10, in slave mode but when transmitting back to the master, the clock line being periodically pulled low just past the switching of SCL low on the SoM.  Because of the voltage differences on the A-side of the isolator, the VOL of this side is about 0.9V so as to not trip the A-side reading of an input LOW.  There needs to be a minimum 50mV difference between A-side and B-side lines to achieve the anti-lockup condition.  Please refer to the photo, below, to see where we believe the K10 is pulling the A-side SCL line low (and B-side is also low, being driven by the SoM).

(top: SCL, bottom: SDA; both taken on K10 A-side of Si8606 isolator)

I am trying to track the mechanism in which the K10 will pull the SCL line low on every clock cycle when it's transmitting back to the master.  From the datasheet, it appears that the SCL line should only be actively driven (see datasheet snippet, below).

We always have TXAK=0 and FACK=0, only sending one byte at a time.

Our goal is to rule out the K10 pulling the A-side of the isolator LOW while the B-side of the isolator is being driven LOW by the i.MX53 SoM, which could help explain why we get lock-ups.

Does anyone have an idea of why the K10 would massage the SCL line as a slave like this?  I have tried to manipulate the SBRC bit to see if there was some clock stretching or such occurring but this bit didn't prevent the pull-down from happening.  I have also copied that portion of the datasheet (K10) that mentions the SBRC field.

Anyone experience I2C bus lock-ups with digital isolators and Kinetis I2C hardware in slave mode?  Did you find a work-around?  Using ADuM1250 for isolation appears to give us protection from the lock-up, but we still get the K10 pulling SCL on every clock, so I'd like to understand the mechanism that causes this (and we may need to stick with the Si8606).

Thanks again for your input, Freescale Community!

[Jorge_Gonzalez]

Hello Scott Thompson:

Did you enable the Open Drain setting for the I2C pins (PORTx_PCRn[ODE] = 1)?

Your issue looks like the one in these threads:

Re: i2c waveform

Re: Kinetis I2C problem

Regards!,
Jorge Gonzalez

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[scottthompson]

Thank you for the reply, Jorge.

I checked the GPIO initialization and do see that ODE is being configured; we also have high drive strength turned on in the port control; later, I found that I2C had a normal or high drive strength bit as well and turned those on.

I will investigate turning *off* the port high drive strength (maybe it's what's causing this to appear) and just enable the I2C high drive strength.  I will also double-check the port configuration and ensure that the ODE is set to the correct port/muxing combination for the I2C we're using.

I'll re-post with anything meaningful I find.

Best,

Scott

[Edit: double-checked port configuration and we indeed have ODE enabled.  Also, appearance of I2C signals is normal when isolator is bypassed or swapped with Side-B, but this is expected due to the voltage levels on the A-side of the isolator.  The higher low voltage is simply an artifact of the anti-lockup mechanism on the isolator, but the K10 is actively driving the line (pulling it low) on every clock, which is where I'm trying to isolate the cause].

[Jorge_Gonzalez]

Hi Scott:

The problem is then very strange. Are you confident that those low spikes are caused by the K10 and not the isolator?

When configured for slave mode, the K10 should never drive low the SCL line, unless it is trying to stretch the clock, but I don't think this the case. Can you try with a lower I2C frequency from the i.MX master side? What is the core frequency of K10?

If you can share the slave code I could give it a check.

Regards!

Jorge Gonzalez

[scottthompson]

Well, Jorge, that's certainly a valid question, and one that I've asked myself--especially since there are multiple slaves on the I2C bus.

But on the side of the isolator that this scope capture is from, this is on the K10 side.  I haven't put our logic probe on this proper (but have other captures with the I2C sniffer) to see if this particular packet is indeed from the K10, but I suspect it is since it's located directly on the K10 side and no other slaves are on this side of the isolator.

But, I can't 100% rule out that the isolator is not doing this.  It *shouldn't*, though, because the VOL is about 0.9V and if it is driving the line <0.7V it is subject to latch-up.  Still, I am getting ready to probe the input vs output relationship of the isolator to ensure a > 50mV differential.  This may tell me if the isolator is actually causing that blip.

So, I suspect that it really is the K10 doing this; and I agree that clock stretching seemed odd.

Our QNX package for the SoM turns out to be only clocking I2C at about 80 kbps, so we are reworking the BSP to get it up to 400 kHz.  At that time, I will hopefully get back to this strange behaviour.

BTW, an Analog Devices ADuM1250 has a very similar Side-1 plot as shown above, because it is configured with a high VOL on the Side-1 portion of the isolator to prevent latch-up.  Interestingly, we can't seem to cause latch-up with the ADuM1250 device...

One other option that we are exploring is our floating VBAT line; I read in a K22 errata that spikes on this line > 50V/ms (or something around that) cause VBAT and VDD latch-up on the K22 series.  Since this I2C problem only occurs during EMI/EMC testing (in particular EFTB), we are investigating tying this line to 3.3V via a 5k resistor, and maybe add a filter capacitor.

I'll let you know about the code once I get over my FlexNVM configuration...

Cheers,

Scott