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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

629 Views
pmt
Contributor V

Hi,

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:

pastedImage_0.png

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

pastedImage_2.png

But MQX4.2.0 does a bad transaction: 

pastedImage_3.png

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:

pastedImage_4.png

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?

Thanks,

PMT 

0 Kudos
2 Replies

396 Views
pmt
Contributor V

I wanted to add the polled I2C driver does the transaction correctly.  Only the interrupt driver driver exhibits this problem.

0 Kudos

396 Views
pmt
Contributor V

BTW, this is a BSP based on 'twrk60f120m'. 

Thanks.

0 Kudos