[U-Boot-Users] I2C Initialization

[Reinhard Meyer]

Its one of the trickiest things at all...

For I2C Reset it is adviseable to cause at least a sequence of eight STOP
one START and another STOP condition. Some Manufacturers (Microchip when I
remember correctly) require that because in violation of the I2C Spec they
do not recognize a STOP condition while expecting the Bits of a Byte.
Otherwise you might end up writing an arbitrary value the last addressed
location in your I2C memory if the previous transfer has been interrupted in
an unfortunate state... (see also I2C Edge Conditions, which addresses a
part of the Problem).

I know it doesn't help you, but we put our Vital Product Data section in a
part of the EEPROM that can be protected against writes by keeping the WP
pulled high (ATMEL 24LC64: 6kb always writeable, 2kb protected). The test
adapter will pull it low so it can be programmed during testing.

In order to do that you need TWO general purpose I/O Lines. Its simple with
the MPC8xx series, since the I2C Bus Pins can also be used as general
purpose I/O lines. Can't you somehow directly control your I2C lines through
the processor?

((Note to myself: check whether the SOFT_I2C driver in u-boot does that kind
of init, if NOT add it?))

A wild idea might be to conditionally power the I2C devices to cause them a
power-on-reset...

Reinhard

> This is an interesting topic, because I am actually
> seeing I2C bus hangs on our own custom hardware
> once and a great while. This hardware is PowerPC
> based but doesn't use u-boot. I kind of narrowed
> it down to the processor getting reset during
> an I2C transaction. Since the slave device (EEPROM with a temp
> sensor in it) doesn't have a reset, the bus gets stuck
> low and when a master tries to start a new transaction
> it can't because the bus appears busy.
>
> Which line did you attach a GPIO pin to? The clock or the data?
> It seems that this would be a good generic solution to this
> particular part of the problem to simply clock the slaves back to
> a known state. I'm not sure if I've seen corruption as mentioned in the
> I2C_Edge_Conditions doc.
>
> I was thinking, in my design, since I have independent control of the
> reset to the processor subsystem in hardware, To make the code set a bit
> which gates the reset to the processor subsystem while doing I2C accesses.
> When the access(es) finish the bit would be cleared and then the reset
would
> be
> allowed to take effect. This of course is very hardware specific, but just
a
> thought
> I had.

What _IF_ your systems hangs during that phase?