AnsweredAssumed Answered

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

Question asked by SCOTT THOMPSON on Jun 1, 2015
Latest reply on Jun 3, 2015 by SCOTT THOMPSON



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!