RE: [ECOS] Flash Driver Read/Write Alignment Question

[Jay Foster <jay@systech.com>]

Ahh, thanks.  I see it now.  My omission of the flash base address in my
example is where I missed the magic.

	volatile flash_data_t *ROM = flash base address
	f_s1 = (volatile flash_data_t *)((CYG_ADDRWORD)(ROM + 0x555));

Jay

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Friday, June 09, 2006 12:06 PM
To: Jay Foster
Cc: 'ecos-discuss@ecos.sourceware.org'
Subject: RE: [ECOS] Flash Driver Read/Write Alignment Question


On Fri, 2006-06-09 at 11:43 -0700, Jay Foster wrote:
> I have not encountered an alignment issue (yet), as I haven't gotten that
> far.  I am studying the source code (flash_am29xxxxx.inl).  I still don't
> see how this is supposed to work.  Effectively, I would have:
> 
> 	typedef cyg_uint16 flash_data_t; // flash_io.h
> 	volatile flash_data_t *f_s1, *f_s2;
> 	f_s1 = (volatile flash_data_t *)0xAAA; // flash base address omitted
> 	f_s2 = (volatile flash_data_t *)0x555;
> 
> 	*f_s1 = FLASH_Reset;
> 	*f_s1 = FLASH_Setup_Code1;
> 	*f_s2 = FLASH_Setup_Code2;
> 
> Where does the 0x555 and 0xAAA get shifted left by 1?  The value of f_s2
is
> odd.  Dereferencing it will result in an unaligned transfer.

That's not what my version of the code looks like :-)  There are macros 
that do the casting and get the addressing/alignment correct.

Try running your version of the code through the C-Preprocessor (use -E)
and see what the real C code looks like.  You'll see that it's a bit 
more than just a cast offset.

> Jay
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Friday, June 09, 2006 11:02 AM
> To: Jay Foster
> Cc: 'ecos-discuss@ecos.sourceware.org'
> Subject: Re: [ECOS] Flash Driver Read/Write Alignment Question
> 
> 
> On Fri, 2006-06-09 at 10:06 -0700, Jay Foster wrote:
> > I am puzzling over how the eCos flash drivers are supposed to work when
> > using 16-bit wide flash devices.  I'm using an ARM architecture
(ARM7TDMI,
> > ARM940T), and the AMD AM29LV160 flash device connected in the 16-bit
wide
> > mode (CYGNUM_FLASH_WIDTH=16).
> > 
> > Looking at the flash driver code, this defines the flash_data_t as a
> 16-bit
> > type.  This results in all accesses to the flash device to be performed
as
> > 16-bit reads/writes.
> > 
> > The flash driver defines some special addresses (FLASH_Setup_Addr1,
> > FLASH_Setup_Addr2, etc.).  At least one of these will be defined as an
odd
> > address.  This will result in an unaligned transfer, causing a DATA
ABORT
> > exception.  What am I missing here?
> 
> They should not end up at odd addresses since they are cast to the
> FLASH element type.  If this is 16 bit, Addr(0xA55) == 0x14AA, etc.
> 
> If you're ending up with alignment issues, then you've configured
> your FLASH driver incorrectly (check the defines).  There are lots
> of examples of 16 and 32 bit device setups, as well as some parallel
> and banked layouts.
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 
> 
-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss