From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Schwarz Date: Thu, 10 Apr 2008 14:13:53 +0200 Subject: [U-Boot-Users] I2C @ MPC8343 In-Reply-To: <47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de> References: <47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de> Message-ID: <47FE0481.6020202@matrix-vision.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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