Yahoo Groups archive

Lpc2000

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

Message

Re: Partial Flash Programming (ctd)

2004-12-11 by philips_apps

Hi Bill,

thanks for writing it more clearly than I did. Yes you got it. Don't
forget the rule of max 16 writes to a 4k block. Means you can not
write the whole 4k before erasing it again.

Robert

--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
> 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.

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.