[U-Boot-Users] I2C @ MPC8343

[U-Boot-Users] I2C @ MPC8343

[Andre Schwarz]

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
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................


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.


regards,
Andre Schwarz
Matrix Vision


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot-Users] I2C @ MPC8343

[Martin Krause]

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?

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

[U-Boot-Users] I2C @ MPC8343

[w.wegner at astro-kom.de]

Hi,

On 10 Apr 2008 at 13:08, Martin Krause wrote:
> > 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).

sorry if I did not follow the discussion up to here. As I stumbled over
it yesterday, I just want to give another example how to hang a bus.

There are devices (namely LM75) that claim to be I2C devices but
do not care about I2C specification. In case of LM75, a read must
always be 16 bit (2 bytes), in case of reading only 1 byte the device
does not interpret the missing ACK correctly and, in case the
last byte read is '0', it will block the bus until some more (worst
case 8) SCL pulses follow.

Maybe something like this could also happen in your case?

Regards,
Wolfgang

[U-Boot-Users] I2C @ MPC8343

[Ben Warren]

Hi Andre,

On Thu, Apr 10, 2008 at 4:37 AM, Andre Schwarz
<andre.schwarz@matrix-vision.de> wrote:
> 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
>  0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>
>
>  Observing the I2C bus wires show that everything _works excellent_ :
>  100kHz speed as well as all data seems ok - but u-boot shows "ff".
>

The fact that probing works and your scope shows bits toggling leads
me to believe that your command syntax is the problem.
Please try something like: "i2c md 50.1 0 10".  I2C syntax is a bit
goofy - you often have to specify the bus width.  I've used 1.3.2
successfully on an MPC8349 (same as yours) with and without Timur's
speed patches.

regards,
Ben

[U-Boot-Users] I2C @ MPC8343

[Andre Schwarz]

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 

[U-Boot-Users] I2C @ MPC8343

[Andre Schwarz]

Wolfgang,

I have indeed a LM75 on this bus - but it's not adressed.
The same I2C bus works fine on linux-2.6.25 including LM75 and EEPROM.

The oszi shows complete transactions with valid data.
I think it is as software issue.

Thanks,
Andre

w.wegner at astro-kom.de schrieb:
> Hi,
>
> On 10 Apr 2008 at 13:08, Martin Krause wrote:
>   
>>> 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).
>>     
>
> sorry if I did not follow the discussion up to here. As I stumbled over
> it yesterday, I just want to give another example how to hang a bus.
>
> There are devices (namely LM75) that claim to be I2C devices but
> do not care about I2C specification. In case of LM75, a read must
> always be 16 bit (2 bytes), in case of reading only 1 byte the device
> does not interpret the missing ACK correctly and, in case the
> last byte read is '0', it will block the bus until some more (worst
> case 8) SCL pulses follow.
>
> Maybe something like this could also happen in your case?
>
> Regards,
> Wolfgang
>
>   



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/73f6157e/attachment.htm 

[U-Boot-Users] I2C @ MPC8343

[Andre Schwarz]

Ben,

I'm a little confused right now and need to have a closer look.

The EEPRM is a M24C64 from ST with extended adressing modes. There might 
be something going wrong during probe or initial adressing.


I'll post as soon as there are more useful results ...

thanks,
Andre

Ben Warren schrieb:
> Hi Andre,
>
> On Thu, Apr 10, 2008 at 4:37 AM, Andre Schwarz
> <andre.schwarz@matrix-vision.de> wrote:
>   
>> 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
>>  0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>
>>
>>  Observing the I2C bus wires show that everything _works excellent_ :
>>  100kHz speed as well as all data seems ok - but u-boot shows "ff".
>>
>>     
>
> The fact that probing works and your scope shows bits toggling leads
> me to believe that your command syntax is the problem.
> Please try something like: "i2c md 50.1 0 10".  I2C syntax is a bit
> goofy - you often have to specify the bus width.  I've used 1.3.2
> successfully on an MPC8349 (same as yours) with and without Timur's
> speed patches.
>
> regards,
> Ben
>   



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/f45d001a/attachment.htm 

[U-Boot-Users] I2C @ MPC8343

[Martin Krause]

Hi Andre,

Andre Schwarz wrote on Thursday, April 10, 2008 2:14 PM:
>> 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.

If you see the correct data on the bus with your scope and U-Boot 
nevertheless shows only 0xff, this seems like a bug in U-Boot to mee.
If you set the address lenght (.x spezifier) wrong, then the data
you see on the bus will also be wrong.

>> 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.

This should definitely be fast enough (for 100 kHz)

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

[U-Boot-Users] I2C @ MPC8343

[Ben Warren]

Andre Schwarz wrote:
> Ben,
>
> I'm a little confused right now and need to have a closer look.
>
> The EEPRM is a M24C64 from ST with extended adressing modes. There 
> might be something going wrong during probe or initial adressing.
>
>
If it's an extended addressing eeprom, you probably need to do 16-bit 
reads, e.g.

i2c md 50.2 0 10

If that doesn't work, it's quite possible that something else has hosed 
the bus.

regards,
Ben