[U-Boot-Users] I2C address above 0x7f

Wed Dec 4 14:30:12 CET 2002

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