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