Problems with I2C on MCF5208

[Rambabu]

Hi,

We are using MCF5208 processor and I2C is configured as Master. It has 4 I2C slave peripheral devices connected to it. Out of the four devices, two are on board and two are external devices which are connected through the buffers.

When one of the external peripheral holds the I2C bus by pulling the SCL line low, the bus busy status bit is set to 1 as expected. However, even after reinitializing the I2C controller, it is unable to communicate with any other remaining peripheral devices.  Once this happens, the IIF bit in the I2SR is never becoming 1 for any read or write transactions, and the only option is to reboot the board.

For initialization we followed the steps given in the MCF5208RM.pdf document and couldn't find anything regarding I2C in errata. Is there anyway to reset the I2C controller alone in the 5208 other than the initialization sequence? Thanks in advance.

-Rambabu. 

[JimDon]

Can you check if the SCL line is being held low?

[TomE]

There is a design problem with the I2C bus. It can lock up if the master is reset during a transaction. When this happens the master is trying to start a cycle while the slaves assume they're in the middle of a cycle.

This may not be the cause of your problem, but by resetting the master you may be getting the system into this state.

I've known about this for years, and have found my I2C Reset code that says how you should reset the I2C bus prior to using it. You should send 9 clocks (to clear out any previous cycles) during I2C initialisation. In some cases you have to program the port pins as GPIOs and toggle SCL in software to do this.

Google "i2c bus lock up reset " finds:

http://forums.parallax.com/showthread.php?112299-I2C-reset-%28part-of-protocol-or-by-device-manufact...

I have had a only a bare handful of projects where under certain circumstances an I2C slave may "lockup" (generally by not releasing SCL if a lockup happens during clock stretching -- masters that do not timeout under these circumstances usually fall into their own endless loop as well because SCL never goes high). There are workarounds of course: polling SCL, bit-banging I2C routines to ensure that I2C transactions timeout while waiting for a slave to release a line, power cycling the slave, etc.

However, I came across this tidbit in a datasheet from Atmel (an I2C 32kbit SOIC EEPROM)

doc said...
After an interruption in protocol, power loss or system reset, any 2-
wire part can be reset by following these steps:
(a) Clock up to 9 cycles, (b) look for SDA high in each cycle while SCL is high and then
(c) create a start condition as SDA is high.

The following are usually similar.

http://www.microchip.com/forums/m45683.aspx

http://www.utasker.com/forum/index.php?topic=990.0;wap2

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/49472.aspx

http://www.picaxeforum.co.uk/showthread.php?18654-Curing-a-locked-up-i2c-bus-after-hardware-reset-of...

Tom