I believe the CFG_I2C_SLAVE value is put in a register because the register must have something in it, but it is only used if the 8xx/82xx processor is used as a I2C slave. Leave it at 0xFE. This would be the shifted value, so it actually sets what I would consider the I2C to be 0x7F.

I2C addresses are the top 7 bits of a byte with the LSBit the R/W flag. Some people treat the whole byte as the address. I (and approximately half the world, including u-boot) find that non-intuitive and thus treat I2C addresses as the 7 bits right-shifted one bit. Thus when you write that your FRAM is at address 0xAE/0xAF, that is the full byte address and includes the R/W flag. As you deduced, the address you should use with u-boot is 0x57.

The iprobe command should just work. What you show is nobody responding (which is one result of "works", you just need to figure out why nobody is responding :-/) Unfortunately, iprobe can be quirky, especially when using hardware accelerated I2C as opposed to the bit-bang (software driver) I2C. I don't have any 8xx experience, but my experience is that it is much easier to get the 8260 to work using the bit-banging driver. I have had limited exposure to the 8240 (which only supports the hardware driver) but my experience is that iprobe is very quirky on it.

Things to check with an oscilloscope: 1) Speed: if you clock too fast, the slaves won't respond. 2) Activity: if the clock and data lines don't wiggle, the slaves won't respond. 3) Edges occur per the I2C specification (should be diagrammed in your FRAM manual)

Use an oscilloscope to look at the waveforms. Usually it is pretty obvious once you look at it what is wrong.

gvb

At 02:03 PM 12/4/2002 +0100, Stephan Linz wrote:

Am Mittwoch, 4. Dezember 2002 12:43 schrieb Wolfgang Denk:

...

In message 0212041158460F.06014@pcj86.jena.mazet.de you wrote:

...

currently I play with the I2C facility of PPCBoot 2.0.0 (I know, it's deprecated). At my TQ850L I'm using the I2C hardware machine (CONFIG_HARD_I2C) with needed configuration:

• CFG_I2C_SPEED=400000
• CFG_I2C_SLAVE=0x7f

Why don't you use the default of 0xFE?

Oh yes, the value above was coming from TQM8260.h. I've changed.

...

...

Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the highes valid slave address, isn't it ?

No, what makes you think so? It's the value that gets programmed into the MPC8xx I2C controller's I2ADD register. See the Users Manual for details.

The subject suggests you ntended to ask something different?

Oops, I've forgot to ask. Now, at my TQ there is a so named FRAM I2C brick connected to I2CSDA (PB27) and I2CSCL (PB26). The FRAM has two different addresses both above 0x7F, 0xAE for write access and 0xAF for read access. The FRAM is similar to E2PROM bricks like AT24C64.

My question: Is there an read/write abstraction layer inside of the I2C stuff of PPCBoot ? I don't know if I should use the bit shifted address 0x57 instead of 0xAE for calling imd -- I think 0x57. However, upt to now I've tried both addresses without success.

Ah, just now I see there is a nice tool to scan I2C devices (iprobe). Can anybody give me an generic command line dump with iprobe in action? I've ran iprobe but without any success. The only thing I see is:

=> iprobe Valid chip addresses: => _

I think iprobe has not found any valid chip. Is it so ?

...

Best regards,

Wolfgang Denk

--

====================================================================== Stephan Linz Software Engineer

MAZeT GmbH Email: mailto:linz@mazet.de Branche office Jena Phone: +49-3641-2809-55 Göschwitzer Straße 32 Fax : +49-3641-2809-12 D-07745 JENA Germany

Visit our web-pages: http://www.MAZeT.de

---

This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

********************************************************************** This e-mail and any files transmitted with it are confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster@si.com and then delete this e-mail, its files and any copies.

This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. ***********************************************************************