Lpc2000

Hi,

I searched before posting & didn't find what I was looking for, 
hopefully this isn't old territory.

I will be using the 2101 in a new design.  2k SRAM, 8k flash (2x4k 
blocks)

It seems as though the minimum amount that can be programmed at once 
(IAP) is 256 bytes, and that the RAM-->flash copy command is what does 
it.

I need to use a portion of the flash as a non-volatile memory, 
presumably through IAP at run-time.  Let's assume that my code uses 
approx. 7k of the 8k of the on-chip flash, and that the block of info I 
need to save is 64 bytes in size.

There can't be any sector erasing, since code is in both sectors. The 
last 1k of flash leaves enough room for 16 "chunks" of 64 bytes 
each.... in reality, over the life of the product, there will probably 
only be a handful (2..3...4) updates of this block.

[Anyway, these numbers (7k boundary, 64 byte block) are still TBD, I'm 
just trying to talk through an example....]

So here is what goes through my mind, can anyone tell me "that should 
work", "you're insane", etc...

- I'll need to dedicate (or at least share) a 256-byte chunk of RAM to 
go back & forth with flash, i.e. I can't use IAP to write only 64 bytes

- I'll (re-write) 0xFF's to the later "virgin" parts of flash, and with 
each update I'll fill in the next 64 byte chunk.

So in other words, the first time I write the 64 byte block, it will be 
written to offset 7k in flash, and I'll use IAP to write a 256 byte 
block from RAM, with the first 64 bytes being "valid", and the last 192 
bytes being 0xFF.

The second time I write the block (i.e. the first update in the field), 
I will read 256 bytes from flash at flash offset 7k into RAM, fill in 
bytes 64-127 (0-based) with the new info, keeping the "stale" data in 
the first 64 bytes (or maybe zeroing them out... TBD), and still 
leaving the last 128 bytes as 0xFF.

As the need arises, I can continue to march down the flash part, only 
clobbering 64 bytes at a time, taking care to keep the rest at 0xFF 
until I need to change them.

Does that make sense?  Is it clear what I'm trying to do?  Any (many?) 
flaws in the approach?

Thanks a lot for your input.

Hi, 

sounds all doable. However, I do remember that there was a max number
of programming cycles mentioned without erasing in between. Because
you can not dedicate a whole sector to the NV-data, there will be only
a limited number of writes possible before the Flash writes become
unreliable. If I remember it correctly it was something about 10
writes before you need to erase the sector again.
May be a LPC2102 is the better solution, you would have a whole sector
available and also double the RAM to buffer a whole sector while
erasing / re-writing. 

As you mentioned only a handful updates of this block during the
lifetime, the 2101 might still be OK. 

Bob

--- In lpc2000@yahoogroups.com, "shergtu" <shergtu@...> wrote:

>
> Hi,
> 
> I searched before posting & didn't find what I was looking for, 
> hopefully this isn't old territory.
> 
> I will be using the 2101 in a new design.  2k SRAM, 8k flash (2x4k 
> blocks)
> 
> It seems as though the minimum amount that can be programmed at once 
> (IAP) is 256 bytes, and that the RAM-->flash copy command is what does 
> it.
> 
> I need to use a portion of the flash as a non-volatile memory, 
> presumably through IAP at run-time.  Let's assume that my code uses 
> approx. 7k of the 8k of the on-chip flash, and that the block of info I 
> need to save is 64 bytes in size.
> 
> There can't be any sector erasing, since code is in both sectors. The 
> last 1k of flash leaves enough room for 16 "chunks" of 64 bytes 
> each.... in reality, over the life of the product, there will probably 
> only be a handful (2..3...4) updates of this block.
> 
> [Anyway, these numbers (7k boundary, 64 byte block) are still TBD, I'm 
> just trying to talk through an example....]
> 
> So here is what goes through my mind, can anyone tell me "that should 
> work", "you're insane", etc...
> 
> - I'll need to dedicate (or at least share) a 256-byte chunk of RAM to 
> go back & forth with flash, i.e. I can't use IAP to write only 64 bytes
> 
> - I'll (re-write) 0xFF's to the later "virgin" parts of flash, and with 
> each update I'll fill in the next 64 byte chunk.
> 
> So in other words, the first time I write the 64 byte block, it will be 
> written to offset 7k in flash, and I'll use IAP to write a 256 byte 
> block from RAM, with the first 64 bytes being "valid", and the last 192 
> bytes being 0xFF.
> 
> The second time I write the block (i.e. the first update in the field), 
> I will read 256 bytes from flash at flash offset 7k into RAM, fill in 
> bytes 64-127 (0-based) with the new info, keeping the "stale" data in 
> the first 64 bytes (or maybe zeroing them out... TBD), and still 
> leaving the last 128 bytes as 0xFF.
> 
> As the need arises, I can continue to march down the flash part, only 
> clobbering 64 bytes at a time, taking care to keep the rest at 0xFF 
> until I need to change them.
> 
> Does that make sense?  Is it clear what I'm trying to do?  Any (many?) 
> flaws in the approach?
> 
> Thanks a lot for your input.
>

Hi Bob,

Thanks very much for the reply, Bob.  The information is very helpful.

Even though the current product, as spec'ed, mentions something like 4
updates max over the life of the product, it never occurred to me that
*if* we were go to 8...10... 15 updates (you know how these things
go), the reliability might not be as high.

Regarding the 2102, I'll "run it up the flagpole" so to speak... as
you can imagine, I always get push-back when I ask for anything!  In
fact I initially spec'ed the '03 (at least during design/development),
saying we can always drop down to the '01 or '02 for production if
everything will fit.... and man-o-man, you should have heard the wailing!

Have a nice weekend & thanks again for the help.

Dan

--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@...> wrote:

>
> Hi, 
> 
> sounds all doable. However, I do remember that there was a max number
> of programming cycles mentioned without erasing in between. Because
> you can not dedicate a whole sector to the NV-data, there will be only
> a limited number of writes possible before the Flash writes become
> unreliable. If I remember it correctly it was something about 10
> writes before you need to erase the sector again.
> May be a LPC2102 is the better solution, you would have a whole sector
> available and also double the RAM to buffer a whole sector while
> erasing / re-writing. 
> 
> As you mentioned only a handful updates of this block during the
> lifetime, the 2101 might still be OK. 
> 
> Bob
> 
>

> Subject: [lpc2000] Re: IAP questions (LPC2101) - conserving flash
> 
> Hi, 
> 
> sounds all doable. However, I do remember that there was a 
> max number of programming cycles mentioned without erasing in 
> between. Because you can not dedicate a whole sector to the 
> NV-data, there will be only a limited number of writes 
> possible before the Flash writes become unreliable. If I 

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

--- 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

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
>

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
> >
>