<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Martin,<br>
<br>
thanks for your hints.<br>
<br>
<br>
Martin Krause schrieb:
<blockquote
cite="mid:47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de"
type="cite">
<pre wrap="">Hi Andre,
<a class="moz-txt-link-abbreviated" href="mailto:u-boot-users-bounces@lists.sourceforge.net">u-boot-users-bounces@lists.sourceforge.net</a> wrote on :
</pre>
<blockquote type="cite">
<pre wrap="">All,
in my current system the I2C bus is not working properly on a MPC8343
in
u-boot v1.3.2.
i2c board config includes :
#define CONFIG_HARD_I2C
#undef CONFIG_SOFT_I2C
#define CONFIG_FSL_I2C
#define CONFIG_I2C_MULTI_BUS
#define CONFIG_I2C_CMD_TREE
#define CFG_I2C_OFFSET 0x3000
#define CFG_I2C2_OFFSET 0x3100
#define CFG_I2C_SPEED 100000
#define CFG_I2C_SLAVE 0x7F
chip probing works fine.
mvBL-M7> i2c probe
Valid chip addresses: 30 48 50 68
reading the Chips gives all "ff"
mvBL-M7> i2c md 50 0 10
</pre>
</blockquote>
<pre wrap=""><!---->
Uh, it seems I lag behind in U-Boot evolution. I know this
"i2c md" command as "imd"?
</pre>
<blockquote type="cite">
<pre wrap="">0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
</pre>
</blockquote>
<pre wrap=""><!---->
Devices with address 50 normally are EEPROMs. If this device is an
EEPROM, are you sure it contains data other than 0xff?
</pre>
</blockquote>
Yes - it's the configuration data of the CPU.<br>
I can see the transaction on the bus - all data is correct. U-boot
shows 0xff.<br>
<blockquote
cite="mid:47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de"
type="cite">
<pre wrap="">The number of address bytes a device needs is varying. Your could
look up the correct address length in the datasheet of your device,
or try it manually:
imd 50.0 0 10
imd 50.1 0 10
imd 50.2 0 10
One of this should work.
</pre>
</blockquote>
no - only 0xff.<br>
Scope shows valid I2C transactions with correct data.<br>
<blockquote
cite="mid:47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">Observing the I2C bus wires show that everything _works excellent_ :
100kHz speed as well as all data seems ok - but u-boot shows "ff".
BTW: Fetching HRCW from I2C is also working fine.
After some tries (i2c md ..) the bus hangs and no more transactions
can
be seen on the bus.
</pre>
</blockquote>
<pre wrap=""><!---->
One reason for a hanging bus could be a lost clock pulse. This could
happen, if the low->high rise time of the bus signal is longer than
the clock pulse width. For testing you could try a lower bus clock
(10 kHz for example).
</pre>
</blockquote>
rise time is ~200ns.<br>
<blockquote
cite="mid:47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de"
type="cite">
<pre wrap="">Best Regards,
Martin Krause
--
TQ-Systems GmbH
Muehlstrasse 2, Gut Delling, D-82229 Seefeld
Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl
<a class="moz-txt-link-freetext" href="http://www.tq-group.com">http://www.tq-group.com</a>
</pre>
</blockquote>
<br>
<BR>
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
<BR>
</body>
</html>