Lpc2000

Rob, I am doing the exact same thing myself. Our units never hit the 
field yet, but they seem to behave quite well in the lab so far. The 
only thing to mention is that I write 0xFF even on the bytes of the 
256 byte chunk that already have data. I didn't understand well if 
you are doing that too, but this is worth mentioning because a thread 
about this took place some weeks ago and the general feeling was that 
this is the right thing to do.

My data has not a predefined size (although 32 bytes is a good 
average), so I had to implement some kind of "incremental" file-
system to deal with that. My implementation makes sure information is 
always written at a 16-byte alignment (wasting up to 15 bytes if the 
data doesn't fit a multiple), due to LPC's Flash architecture 
limitations.

Guille

--- In lpc2000@yahoogroups.com, "chazeltopman" <timbreworks@...> 
wrote:
>
>  I'm in a similar boat as I'm porting code from an environment 
where I
>  keep pointers into a flash buffer in EEPROM.  I double buffered 
the pointers
>  so that the unit could survive random poweroffs and pick up where 
it left
>  off.  On the LPC with only flash this is not acceptable due to:
>   o erase is on a sector basis which on the 2138 is 4K or 32K
>   o it takes 400ms to do an erase which you don't want to do every 
second
>  I looked over the Philips program and also found some useful 
references:
>   http://groups.yahoo.com/group/lpc2000/message/2681
>   http://groups.yahoo.com/group/lpc2000/message/8586
>  I'm not using the Philips code but it acted as another reference.  
There is
>  no getting around the physical constraints of the LPC flash but it 
is good
>  to know what you can do with it.  In my case I need to write 32 
bytes
>  of data every second.  Even tho the spec sheet says 256 bytes is 
the minimum
>  you can still play around inside that and the details are in the 
above messages.
>  For me to write 32 bytes, I copy out 256 bytes aligned to a ram 
buffer, change
>  the 32 bytes I want to record (must be all FF's to do this) and 
then write back
>  the 256 bytes.  Only the 32 bytes I changed are affected in the 
flash.  To get
>  around using pointers into the flash,  I'm using a sentinal marker 
every 4K
>  bytes that has a unique sequence number.  So upon bootup, I scan 
through
>  the flash looking for the sentinel markers and take the latest one 
and scan
>  forward for empty flash and then start there.  As I'm recording in 
wraparound
>  fashion, if I get to the end of a sector, then I erase the next 
sector for the next
>  second.  From the end of flash I wrap to the beginning of the 
flash space I'm
>  using.  I also need to reserve an area of Flash for keeping boot 
parameters
>  but those change infrequently so I can just keep a 4K block for 
that purpose
>  (even though I need less than 100 bytes of config data!).
> 
>  Rob
> 
> --- In lpc2000@yahoogroups.com, "shergtu" <shergtu@> wrote:
> >
> > --- In lpc2000@yahoogroups.com, "Bruce Paterson" 
<bruce.paterson@> 
> > wrote:
> > 
> > > Woah, haven't heard of that one !  The Philips example (in the 
files
> > > area) to emulate Eeprom using flash has the potential to do 
many 
> > many
> > > writes (marching onwards through the flash) without an erase. 
Where 
> > did
> > > you find out that information ? Certainly the Philips program 
should
> > > have a re-programming counter if this is indeed the case. Can
> > > phillips_apps (Robert) confirm ?
> > > I haven't experienced any issues so far with many reprograms 
without
> > > erase on the lab units. (Field units at present would typically 
not
> > > experience many changes).
> > > 
> > > Cheers,
> > > Bruce
> > 
> > Bruce,
> > 
> > Wow, I didn't even realize until now there was sample code along 
> > those lines (EEPROM emulation).  I just downloaded the .zip file 
& 
> > will take a look.
> > 
> > When I get to the point where I have some interesting/meaningful 
> > results of my own to report, I'll post back to the group.
> > 
> > Thanks,
> > Dan
> >
>