Lpc2000

Ok, I think my confusion is cleared up a bit.  It came from a mix of
the IAP interface to erase & program the flash and the flash
implementation as descibed by Philips Apps at the end of this message.

In small steps:

1) Data are stored in flash as 128-bit words (plus ecc bits)

2) Because of the ecc bits, each 128-bit word may only be programmed
once without being erased.

3) Multiple 128-bit words are combined in a 4096-bit (512-byte) block.

4) The IAP interface only allows programming of some multiple of
4096-bit (512-byte) blocks (1-512, 2-1024, 8-4096, 16-8192).
Therefore, programming any unprogrammed 128-bit words (16-byte) first
requires copying the 512 byte block in which it resides to a RAM
buffer, adding the new data to the RAM buffer, then using the IAP to
reprogram the 512 byte block.  Erasing the flash first is not required
as long as the new data does not overlay a previously programmed
128-bit word.

5) While a 4096-bit block could potentially be erased, the IAP
interface combines a number of them into 8K/64K sectors and allows
only sectors to be erased.

PLEASE let me know if this is accurate and correct me if it is in
error.

Thanks
-Bill Knight
http://www.theARMPatch.com 

<snip>

On Thu, 09 Dec 2004 07:25:17 -0000, philips_apps wrote:

Hi Al,

even changing some bits from 1 to 0 would generate a wrong reading.
The LPC2000 devices have an error correction  ECC mechanism build in.
 This is part of the flash and will be written the first time (after
erasing) the block of 128-bits is programmed. Any changes thereafter
will result in reading garbage because the ECC mechanism will try to
correct anything changed after the initial write.

The idea was to write one 128-bit block after the other, NOT writing
the same 128-bit block several times. This is possible 16 times within
a 4k block. So 16 writes to 16 different sections of 128-bit each
within a 4k block, then erase the 4k block.

Hopefully this clarifies this issue a little more.