IBB bit stuck in one master system MCF52259, reset does not help

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

IBB bit stuck in one master system MCF52259, reset does not help

Jump to solution
652 Views
timofeibolshako
Contributor I

I have a custom board with MCF52259 and EEPROM Atmel AT24C128C connected to its I2C0.

 

I used a I2C library written by my colleague and come across a situation when IBB in ISR for I2C0 stuck

at high (and I have one master system) and this bit is not cleared by reset.

Power cycle clears this bit just fine.

 

Most likely I will be able to rewrite my I2C code and create a working program, but

stuck bit might be a bug in the processor.

 

Does anybody have an idea about that?

Labels (1)
Tags (2)
1 Solution
406 Views
TomE
Specialist II

> Does anybody have an idea about that?

It isn't the code as such and it isn't the CPU. It is a poorly documented design fault with I2C everywhere.

Just read the manual. It says:

IBB: 1 Bus is busy. When START is detected, IBB is set.

So the chip thinks the bus is busy. I'd suggest you get out an oscilloscope and see what state the pins are in. I'm guessing the EEPROM is pulling one of the pins down when this happens.


Check to see if you have the right pullups on them, just in case. Check ALL of the chip initialisation code to make sure you're not glitching these pins into strange states on power-up.

I2C Bus Lockup is a known design problem with the I2C system. Searching in this forum for "I2C reset" finds a lot of things including this one:

Re: Problems with I2C on MCF5208

That references:

I2C reset (part of protocol or by device/manufacturer only?)

So you need to tie the CPU Reset line to the Reset pin on that chip. Except it doesn't have one.

http://en.wikipedia.org/wiki/I2C#Limitations

Thus it is common for designs to include a reset signal that provides an external method of

resetting the bus devices. However many devices do not have a dedicated reset pin forcing

the designer to put in circuitry to allow devices to be power cycled if they need to be reset.

You don't have to do that because reading the EEPROM's manual and the previously-quoted links finds::

MEMORY RESET: After an interruption in protocol, power loss or system reset, any two-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.

To put it simply, you can reset your CPU DURING an I2C read cycle. The CPU stops sending clocks while the EEPROM is sending data back, and so on every reset you have to "clock the previous read cycle out of the chips" to get them back to normal. And do the rest of that "reset sequence" too.

So you need to perform that "9 clock reset sequence" every time your CPU starts up in order to guarantee the EEPROM is in a proper state to talk to.

Since the I2C Controller doesn't have a command to do that for you, you'll need to first program the pins as GPIO and then SLOWLY  bit-bang the Reset sequence out before reprogramming the pins for I2C operation.

Yes, you do need to do this. You product probably won't operate reliably otherwise.

This applies to all devices using I2C.

Tom

View solution in original post

1 Reply
407 Views
TomE
Specialist II

> Does anybody have an idea about that?

It isn't the code as such and it isn't the CPU. It is a poorly documented design fault with I2C everywhere.

Just read the manual. It says:

IBB: 1 Bus is busy. When START is detected, IBB is set.

So the chip thinks the bus is busy. I'd suggest you get out an oscilloscope and see what state the pins are in. I'm guessing the EEPROM is pulling one of the pins down when this happens.


Check to see if you have the right pullups on them, just in case. Check ALL of the chip initialisation code to make sure you're not glitching these pins into strange states on power-up.

I2C Bus Lockup is a known design problem with the I2C system. Searching in this forum for "I2C reset" finds a lot of things including this one:

Re: Problems with I2C on MCF5208

That references:

I2C reset (part of protocol or by device/manufacturer only?)

So you need to tie the CPU Reset line to the Reset pin on that chip. Except it doesn't have one.

http://en.wikipedia.org/wiki/I2C#Limitations

Thus it is common for designs to include a reset signal that provides an external method of

resetting the bus devices. However many devices do not have a dedicated reset pin forcing

the designer to put in circuitry to allow devices to be power cycled if they need to be reset.

You don't have to do that because reading the EEPROM's manual and the previously-quoted links finds::

MEMORY RESET: After an interruption in protocol, power loss or system reset, any two-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.

To put it simply, you can reset your CPU DURING an I2C read cycle. The CPU stops sending clocks while the EEPROM is sending data back, and so on every reset you have to "clock the previous read cycle out of the chips" to get them back to normal. And do the rest of that "reset sequence" too.

So you need to perform that "9 clock reset sequence" every time your CPU starts up in order to guarantee the EEPROM is in a proper state to talk to.

Since the I2C Controller doesn't have a command to do that for you, you'll need to first program the pins as GPIO and then SLOWLY  bit-bang the Reset sequence out before reprogramming the pins for I2C operation.

Yes, you do need to do this. You product probably won't operate reliably otherwise.

This applies to all devices using I2C.

Tom