Lpc2000

I have had extensive experience with the ARM flash storage on the
  LPC2106 and LPC2129 forms and can pass along a few pieces of information
  that might be helpful.

  For the reprogramming algorithm with random access to flash storing a
  32-bit aligned word where:

     n - 32 bit number to store
     a - address in flash to store n at
     al - a aligned to a lowerbound 16 byte region: al = ((a+15)&~15)
    
     if the 16 bytes from al are all 0xFF then you only need to modify
     the segment with a read, modify and write back.  If any of the 16
     bytes are not 0xFF, then the sector must be copied out, modified,
     flash sector erased and then written back.

     To modify a segment (512 bytes), you'll need a temporary buffer
     space to hold the data.  The flash segment address should be on
     a 512 byte boundary like the 16 byte one above.

     To modify a sector (2K or 64K), you'll need a bigger buffer.  On
     the LPC2129, two of the flash sectors are 64K and the onboard RAM
     is only 16K so it is not possible to do it this way (but you could
     ping pong the two with incremental writes and have a safe backup
     mechanism since you'd write before erase).  The 2K sector can be
     dealt with in the same manner as the 512 byte segment with an added
     erase command thrown in which will add 400msec to the sequence.

  So if you always pick an unwritten 16 byte aligned chunk of flash,
  then you won't hav to do any expensive erasing on the fly.  And
  then how much you can buffer up to 16 bytes before writing will
  determine your usage efficiency.
    
  Now a word to the wary.  Some early chips contain a bug in the erase
  algorithm in the bootloader which causes the IAP call to not return
  sometimes requiring a restart of the micro.  This can be reproduced
  by alternately writing and erasing a sector of flash. At some point
  it hangs.  I sent off an email with the details of my tests to
  Philips and got a positive response where they acknowledged the
  problem and replaced all the chips we had.

  Here are the parts that we are currently having problem with:

   Part # : LPC2106B-CC0057-TP323B
   Bootloader Version 1.3

   Part#: LPC2129FBD64-CC4761.00102-TP0404AY
   Bootloader Version 1.6

Philip's response:
   We have been experiencing difficulties with the flash array
   that are similar to the problem you have described. This problem is
   fixed (by modifying the bootloader) in later versions of the device.
   At what stage of development are you? If you would require new
   samples I can send them to you. Also, please give me the complete
   part markings and the bootloader version.


Previous posting:
>I read the postings under the the "Flash fails to write..." topic,
>but have problems following along and/or reproducing it.
>
>My Goal:
>to log single variables into flash occasionally, with minimum loss of
>overhead (unused Flash space). Typically two 32bit values get stored
>at the time, the first is an ID for the variable, the second is the
>current value of that variable. When the current value of a variable
>with a certain ID is needed, a backward search is started from the
>end of the Flash sector downwards - if ID is found, the value behind
>it is the last written value of that variable.
>
>
>Summary of thread so far and new questions from me:
>1.) As stated in this thread, minimum write segment size on LPC is
>512 bytes (per datasheet), so if just a few bytes are stored, a big
>overhead occurs.
>
>2.) First suggested work-a-round was to read a 512-byte segment, add
>the new variables and write it back. I assume as long as the only bit
>changes made are erasing bits, such a re-write can be performed
>without a previous sector erase.
>Correct?

  No this will cause other bits to flip unpredictably.

>
>3.) "Someone" came up with a 16byte boundary
>I tried using a 16byte size instead of 512 when calling the IAP
>routines, that results in a "COUNT_ERROR" reported back. Contents of
>Flash did not change.

  Use proper alignment and criteria as mentioned above and it will work.

>
>So how and where can I use this 16byte write? Or does this only apply
>together with 2.)?
>In other words:
>a) read 512 bytes segment
>b) pick a block of 16 bytes all set to FF
>c) change data in block
>d) write segment back (without erase)
>?

  and note the alignment to boundaries as per above.

  Rob