Hi Andre,
u-boot-users-bounces@lists.sourceforge.net wrote on :
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
Uh, it seems I lag behind in U-Boot evolution. I know this "i2c md" command as "imd"?
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
Devices with address 50 normally are EEPROMs. If this device is an EEPROM, are you sure it contains data other than 0xff?
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.
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.
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).
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 http://www.tq-group.com