Lpc2000

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