AnsweredAssumed Answered

MQX4.2.0 I2C (ii2c:) EEPROM read broken?

Question asked by pmt on Sep 30, 2015
Latest reply on Oct 20, 2016 by pmt



I have recently converted from MQX4.1.1 to MQX4.2.  I have an I2C EEPROM memory read function modeled after the MQX example function i2c_read_eeprom_interrupt().


Everything works in MQX4.1.1, but is broken in MQX4.2.0.


The transaction I am trying to do is a single byte read of the memory chip, just like this:

On the scope MQX4.1.1 does a nice transaction just like the above:


But MQX4.2.0 does a bad transaction: 

Scale is 40us per division to fit in the whole transaction.  Notice that everything works fine until the very end (5th word) where it should be issuing the STOP condition, but instead an entire extra byte is read/written.  This then leaves the bus in a "hung" state (SDA line stays low). 


Aside from the oversight that MQX drivers have no capability to clear a bus hung state (in fact drivers will deadlock on the next transaction busy polling for an idle bus), there is the mystery of where this extra byte transaction comes from.  Also note the extra slow clocking at the top is where I manually clear the "bus hung" state by taking control of the I/O pins and clocking out the hung condition.


A zoom of the last part of the transaction:


Now this may be some other issue, such as an incorrect setting in my custom BSP.  But I suspect the MQX EEPROM I2C example will fail in regression test. 


Can anyone at MQX shed some light on this?