Using AN4652 - I2C Driver Locks Up

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

Using AN4652 - I2C Driver Locks Up

Jump to solution
2,372 Views
mrupp_viatechno
Contributor III

I am using the I2C driver as presented in AN4652 on a K70 system using MQX 3.8 and CodeWarrior 10.2.  The K70 is a master and there is a single slave device.  Initially everything works fine.  Looking at an oscilloscope I see the clock and data lines; the data from the slave device is correct.  The problem is that after some time the I2C interface just stops--the oscilloscope shows nothing.  The time is somewhat random but less than five minutes.  The program is executing an 'fread' statement that never returns.   The problem is somewhat baud rate dependent.  Lowering the baud rate (from 100,000 to 10,000) results in a longer time until the interface locks.  Are there any know problems with the I2C driver?

Tags (2)
0 Kudos
1 Solution
827 Views
mrupp_viatechno
Contributor III

The problem was "solved" by using a better cable.  Shorter, twisted pairs and shielded.  Although we occasionally get incorect data, the driver no longer locks up.  Thank you for your response, but I just don't have the time to go back to the old cable to verify if the new file solves the problem.

View solution in original post

0 Kudos
6 Replies
827 Views
jia_guo
NXP Employee
NXP Employee

The driver is developed and tested on MQX3.8.1.

Please check after the communication stops.  Is the SDA/SCL low?  If yes, master make it low or device make it low?

If master make it low, here is a new version of the driver in the attachment, which adds the SMBUS feature to prevent lock-up.

0 Kudos
827 Views
panpwr
Contributor IV

Can you please upload it to AN4625 in Freescale website? I just downloaded the AN zip file, and it contains the old version.

Thank you.

0 Kudos
827 Views
Mohsin455
Contributor IV

Hi All,

          I am also having some issues with I2C driver. It works fine but the delay required between completing a write for one device (i.e. sending STOP) and starting the write for the second device (sending START) is very high around 10us. I have seen the documentation and any of the connected device does not require this long delay.

If I give a delay of 15us it works fine but really not sure why it required this much delay.

Thanks

Mohsin

0 Kudos
828 Views
mrupp_viatechno
Contributor III

The problem was "solved" by using a better cable.  Shorter, twisted pairs and shielded.  Although we occasionally get incorect data, the driver no longer locks up.  Thank you for your response, but I just don't have the time to go back to the old cable to verify if the new file solves the problem.

0 Kudos
827 Views
BryGuyH
Contributor IV

Use the I2C driver from MQX 3.8.1

0 Kudos
827 Views
mrupp_viatechno
Contributor III

I copied all the files from MQX3_8_1\source\io\i2c into the corresponding folder in MQX3_8.  Then made the changes as per AN4653 and rebuilt MQX (BSP, PSP, and so forth).  Lastly, I rebuild my application and ran it.  No change.  The driver still hangs in the 'fread'. 

0 Kudos