This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: Flash Driver Read/Write Alignment Question
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Jay Foster <jay at systech dot com>
- Cc: "'ecos-discuss at ecos dot sourceware dot org'" <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 09 Jun 2006 13:05:33 -0600
- Subject: RE: [ECOS] Flash Driver Read/Write Alignment Question
- References: <74C9525D67A5FF4791614FDB06593BB1028627@mail.systech.com>
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