Lpc2000

Robert Adsett wrote:
> At 03:56 PM 4/8/05 +1000, Bruce Paterson wrote:
> 
>>....and one more question after further study....
>>
>>5/ I notice you copy from the flash into the temporary buffer if we're
>>not 512byte aligned, or for the final fragment of size < 512.
>>You also say:
>>  *  NOTE: When programming data into a sector that is already partially
>>  *  programmed, all new data MUST be programmed into previously
>>  *  unprogrammed 16-byte (128-bit) [Ed: Assume 512-byte now] blocks.
>>The statement implies you cannot write a block unless the flash has been
>>previously erased => all 0's or FF's. So why bother copying these (dst)
>>back into the temporary buffer prior to copying the partial (src) over
>>the top ?
> 
> 
> Semantics I believe.  Cannot in this case means not that the flash won't 
> get written, but that the value that results from the write won't match the 
> actual value written unless it is an exact match for what was already in 

OK on that. Only the first write can change it. Subsequent writes to the 
same area must re-write the same data.

> Oh, BTW, erasing flash results in all high bits (0xFF).
Thought it might :)

>>May as well dispense with the temporary buffer and just back the (src)
>>pointer back into whatever crap is in RAM there and write that into the
>>512-aligned-dst (similar with the far end).
>>
>>Seems to me the only way to achieve what I think you're trying to do is
>>to make a whole segment copy prior to erase, and then write overwrite
>>that huge (8k or more) buffer with (src), then program that. Have I got
>>misunderstood something here ?
> 
> You can (must?) program a 512byte chunk at once, but you must take care to 
> preserve anything already written.  This is no different than any other 

Ahhh I get it. The routine lets you write say a single byte at a time. 
You can only ever write any particular byte once per erase, but each 
byte write is implemented by writing the same 512bytes every time, but 
with 1 new byte changed each time.  I was only thinking of >512byte 
(misaligned) writes before. Doh!
...BUT, the minimum size you can *actually* write is 16bytes (on a 16 
byte boundary?) rather than 1 byte, due to the LPC error correction, so 
we should probably add this restriction to the routine.
In fact, the routine could also check for double writes by ensuring all 
_new_ bytes to be added in a call are all to be written over FF's.

I can see how this could work for direct translation of say incoming hex 
records to flash (as long as |16byte| in length), but don't think it 
would help much for 'non-volatile' ram situations in practice because 
the ram case would need to remember across the erase anyway.

> I hope that clears things up a bit.

Yup, Ta!

-- 
Cheers,
Bruce
-------------------------------------------------------------------
     /\\\/\\\/\\\    /   /      Bruce Paterson
    /  \\\ \\\ \\\  /   /    Senior Design Engineer
   /   /\\\/\\\/\\\/   /   8 Anzed Court, Mulgrave, Vic, 3170
  /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
/   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
       Tele-IP Ltd.      Email: bruce@...    Icq: #32015991
                         WWW:   http://www.tele-ip.com       VK3TJN
-------------------------------------------------------------------