[U-Boot-Users] I2C @ MPC8343

Andre Schwarz andre.schwarz at matrix-vision.de
Thu Apr 10 14:13:53 CEST 2008


Martin,

thanks for your hints.


Martin Krause schrieb:
> Hi Andre,
>
> u-boot-users-bounces at 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?
>
>   
Yes - it's the configuration data of the CPU.
I can see the transaction on the bus - all data is correct. U-boot shows 
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.
>
>   
no - only 0xff.
Scope shows valid I2C transactions with correct data.
>> 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).
>
>   
rise time is  ~200ns.
> 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
>   



MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080410/49ab5ff0/attachment.htm 


More information about the U-Boot mailing list