[U-Boot-Users] I2C Initialization

Adam Bezanson
2003-03-05T13:05:45Z

I don't have the ability to control the I2C lines directly from the
processor. I'm using a 7410. I have a System controller chip which
has the I2C master controller in it. All it provides is a higher lever
indirect access register interface to control I2C transactions.

I have though about controlling the power supply to the I2C slaves
and have them controled by register bits in memory space. But this
would require alot of rework of the hardware at several places in my
particular system.

In terms of your question of the system hanging while masking reset to the
processor, I was thinking of adding a timer in hardware to unmask the reset
if it's set too long. Thanks for making sure I've thought of all the
obvious corner cases.

Regards,
Adam

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Reinhard
Meyer
Sent: Wednesday, March 05, 2003 12:43 AM
To: U-Boot Mailing List
Subject: [U-Boot-Users] I2C Initialization

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?

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net