ppc440 and i2c

ppc440 and i2c

[Miku Jha]

Hi,
I am running ppc440 with linux kernel version 2.4

If I reboot the ppc440 in middle of a read transaction
from a slave say( at the 3rd clock pulse for example)
then somehow ppc440 is hung.

Basically when it comes up it sees that data line
held low.
How does the powerpc deal with this situation.?

>From the i2c bus trace it looks like in this
situation ppc440 keeps issuing the clock pulses
until the data line SDL is released by the slave
but following that the SCL line is held low
by ppc440 and is never released or set to IDLE?

Is this the expected behaviour if the SDL is held
low when the ppc440 comes up.
Is there anyway I can fix this in the ppcboot code.

Please let me know.
Any help appreciated.

Thanks a bunch


=====
mailto:jha_miku@yahoo.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ppc440 and i2c

[Eugene Surovegin]

On Mon, Nov 17, 2003 at 11:18:29PM -0800, Miku Jha wrote:
>
> I am running ppc440 with linux kernel version 2.4
>
> If I reboot the ppc440 in middle of a read transaction
> from a slave say( at the 3rd clock pulse for example)
> then somehow ppc440 is hung.
>
> Basically when it comes up it sees that data line
> held low.
> How does the powerpc deal with this situation.?
>
> From the i2c bus trace it looks like in this
> situation ppc440 keeps issuing the clock pulses
> until the data line SDL is released by the slave
> but following that the SCL line is held low
> by ppc440 and is never released or set to IDLE?
>
> Is this the expected behaviour if the SDL is held
> low when the ppc440 comes up.
> Is there anyway I can fix this in the ppcboot code.
>

Your problem sounds strange.

Are you saying that after 440GP _reset_ IIC line state affects 440 ?

This is _very_ unlikely. I doubt that 440GP even sample IIC lines (and
drive clock) until it's asked to do so by software.

Could you elaborate a little: what kernel are you using, what
bootloader (version)?

Maybe it's bootloader's driver problem, not 440 itself.

The other possibility is that you are using bootstrap IIC controller
(it shares lines with IIC0). Is this intended configuration? If not
you may want to check pull-down on UART0DCD_N line.

If bootstrap IIC is accidentaly activated you may get problems if you
have non-compliant/not-properly-reset device on IIC0 bus.

Eugene

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ppc440 and i2c

[Wolfgang Denk]

In message <20031118071829.43116.qmail@web40301.mail.yahoo.com> you wrote:
>
> I am running ppc440 with linux kernel version 2.4

Grrrghh...  You  sent  the  same  message   twice   to   the   (dead)
PPCBoot-Users   list   and   another   time  to  linuxppc-embedded???
Grrrrghhh!!!! Please fix your posting habits.

> >From the i2c bus trace it looks like in this
> situation ppc440 keeps issuing the clock pulses
> until the data line SDL is released by the slave
> but following that the SCL line is held low
> by ppc440 and is never released or set to IDLE?
>
> Is this the expected behaviour if the SDL is held
> low when the ppc440 comes up.

This is an expected and documented problem. See "doc/I2C_Edge_Conditions" in
the U-Boot / PPCBoot sources.

> Is there anyway I can fix this in the ppcboot code.

Yes. You could back-port the fixes that  went  into  U-Boot.  But  it
probably makes more sense to switch to U-Boot instead.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ppc440 and i2c

[Wolfgang Denk]

In message <20031118080843.GA28129@gate.ebshome.net> you wrote:
>
> Your problem sounds strange.

No. It's just that this version (out of 3 different in a total  of  5
messages  to  several  mailing lists I've seen so far!) does not even
explain the problem correctly.

It's just a known issue on the I2C bus.

> Are you saying that after 440GP _reset_ IIC line state affects 440 ?

No.

> If bootstrap IIC is accidentaly activated you may get problems if you
> have non-compliant/not-properly-reset device on IIC0 bus.

The problem is an I2C Edge Condition which means that I2C devices may
be left in a write state if a read  was  occuring  and  the  CPU  was
reset. This may for example result in EEPROM data corruption.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
(null cookie; hope that's ok)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ppc440 and i2c

[Eugene Surovegin]

On Tue, Nov 18, 2003 at 09:22:43AM +0100, Wolfgang Denk wrote:
>
> > If bootstrap IIC is accidentaly activated you may get problems if you
> > have non-compliant/not-properly-reset device on IIC0 bus.
>
> The problem is an I2C Edge Condition which means that I2C devices may
> be left in a write state if a read  was  occuring  and  the  CPU  was
> reset. This may for example result in EEPROM data corruption.
>

Well, I just read doc from U-Boot, and as far as I understand "I2C
Edge Condition" _cannot_ cause 440 to hang as it was described in the
parent post. Sure, it may cause some unlikely corruption but that's
it (provided we haven't corrupted bootstrap EEPROM itself :).

That's why I suspected some bootstrap IIC interaction with
non-properly-reset i2c device left in some intermediate state (as
show in U-Boot doc for example).

Eugene.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: ppc440 and i2c

[Robert Berger]

Hi all,

I'm neither a Linux nor a PPC expert, but I've done some work with I2C
devices.

If I understand you well, you have the following problem:
Problem:
The slave device will only release the I2C bus when the clock is restored or
when the device is temporarily powered down (most devices do not have a
reset signal that can be connected to the system reset).
To provide a clock signal on the I2C bus, there has to be a master on the
I2C bus.
The problem is that no device can be switched to master mode when the I2C
bus is busy (conform the I2C bus specification).
So a typical hardware deadlock occurs: The slave waits for the master to
generate a clock signal and the master waits for the slave to release the
bus.
Solution 1:
You can issue a number of clocks while SDA is high, so that the devices are
all out of the above-mentioned sequence.
This problem was worst with the IIC RTC, because it stayed power on when the
uP was powered down. That's why later on a reset line was added.

Solution 2:

In the read mode the slave goes high during the ACK bit, in the write mode
during the data bits.
After reset before enabling I2C you must test if both SDA and SCL= high.
If not you must clock SCL up to 9 times until SDA is released. ( This is my
favourite solution if I have direct control over the SCL and SDA pins and I
call it free clocking ).
Then you can generate a stop condition.
In multimaster applications you must watch that SCL also can be delayed by
the other master. Then you must wait until SCL = high before generating the
next clock pulse (SCL = 0, wait 5µs, test SDA == 1, SCL = 1, wait 5µs, SCL =
0 ...).

Solution 3 With "intelligent" bus master:

What if your master sends some commands to the bus at reset?
Just send some bogus commands -- the master can ignore a busy bus at reset
if it is supposed to be in charge.
Wouldn't a hosed slave reset then?
Unfortunately, sometimes you can only access the I2C bus via "intelligent"
bus master hardware.
This means that you do not have direct control over the SDA and SCL lines.
I have chosen the following solution: - Connect (wired OR) spare I/O pins
with the I2C bus lines. - When the bus is locked, Generate clock pulses on
the SCL line (via an I/O pin) until the SDA line has been released. - Send a
stop condition - Continue normal operation

I hope this helps.

Regards,

Robert


----------------------------------------------------------------------------
----
Robert Berger
Embedded Systems Software Group Leader

INTRACOM S.A.
Hellenic Telecommunications & Electronics Industry
Research and Development Division
New Technologies Dept.
Advanced Internet and Digital TV Section
P.O. Box 68, 19.5 km Markopoulo Ave. (Building A)
190 02 Peania, Athens, GREECE
Tel.: (+30 210) 667 4353, 667 9000
Fax.:(+30 210) 667 7101
email: rber@intracom.gr
URL: www.intracom.gr


"Software development is like making a baby... You can't make a baby in one
month by impregnating nine women."

"Giving up on assembly language was the apple in our Garden of Eden:
Languages whose use squanders machine cycles are sinful."
(Epigrams in Programming,  ACM SIGPLAN Sept. 1982)

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD432D756

-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Wolfgang
Denk
Sent: Tuesday, November 18, 2003 10:23 AM
To: Eugene Surovegin
Cc: Miku Jha; linuxppc-embedded@lists.linuxppc.org
Subject: Re: ppc440 and i2c


In message <20031118080843.GA28129@gate.ebshome.net> you wrote:
>
> Your problem sounds strange.

No. It's just that this version (out of 3 different in a total  of  5
messages  to  several  mailing lists I've seen so far!) does not even
explain the problem correctly.

It's just a known issue on the I2C bus.

> Are you saying that after 440GP _reset_ IIC line state affects 440 ?

No.

> If bootstrap IIC is accidentaly activated you may get problems if you
> have non-compliant/not-properly-reset device on IIC0 bus.

The problem is an I2C Edge Condition which means that I2C devices may
be left in a write state if a read  was  occuring  and  the  CPU  was
reset. This may for example result in EEPROM data corruption.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
(null cookie; hope that's ok)


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/