Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

IAP questions (LPC2101) - conserving flash

2006-03-11 by shergtu

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.

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.