[U-Boot-Users] I2C @ MPC8343
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
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
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
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@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
Martin,
thanks for your hints.
Martin Krause schrieb:
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?
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
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
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
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
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
participants (4)
-
Andre Schwarz -
Ben Warren -
Martin Krause -
w.wegner＠astro-kom.de