Lpc2000

Bill Knight wrote:

> I just uploaded a set of LPC flash programming routines to the files area
> on Yahoo.  They were written for gcc and support both ARM and Thumb modes
> of operation.  Hopefully, they will prove useful to the group.

Bill,

Just been having a look at your routines as I need to do some IAP now 
myself.
I have a few questions to you/the group if you don't mind:

1/ I notice you expect CMD_SUCCESS, never BUSY back from calling iap. 
This implies to me the iap routines always execute to completion before 
returning (this conficts with another posting to this group which showed 
a for(;;) loop waiting for non-BUSY return). Confused !

2/ If the iap routines don't return till all is done, what happens to 
the watchdog ? The watchdog cannot be disabled once started, so do
a) the iap routines feed the watchdog internally (philips question) ?
b) we need to reboot with watchdog disabled in order to do IAP ?

3/ I notice you prepare all sectors for write every interation of your 
writing loop. Is this just for easier coding ?

4/ In what cases would memmap be anything other than user code in 
practice ? (I notice you save and restore).

-- 
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
-------------------------------------------------------------------

....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 ?
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 ?


-- 
Cheers,
Bruce
-------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager.

     /\\\/\\\/\\\    /   /      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
-------------------------------------------------------------------

Answers interspersed
-Bill


On Fri, 08 Apr 2005 13:35:28 +1000, Bruce Paterson wrote:


Bill Knight wrote:

> I just uploaded a set of LPC flash programming routines to the files area
> on Yahoo.  They were written for gcc and support both ARM and Thumb modes
> of operation.  Hopefully, they will prove useful to the group.

Bill,

Just been having a look at your routines as I need to do some IAP now 
myself.
I have a few questions to you/the group if you don't mind:

1/ I notice you expect CMD_SUCCESS, never BUSY back from calling iap. 
This implies to me the iap routines always execute to completion before 
returning (this conficts with another posting to this group which showed 
a for(;;) loop waiting for non-BUSY return). Confused !

*** The code simply returns the result whenever it is not CMD_SUCCESS or
when done.  A test for BUSY could be added to flashWrite() with a limit
to the number of tries.  So far, I have not found this to be a problem
but YMMV.

2/ If the iap routines don't return till all is done, what happens to 
the watchdog ? The watchdog cannot be disabled once started, so do
a) the iap routines feed the watchdog internally (philips question) ?
b) we need to reboot with watchdog disabled in order to do IAP ?

*** I'll leave the answer for this one to the Philis Apps guys.

3/ I notice you prepare all sectors for write every interation of your 
writing loop. Is this just for easier coding ?

*** Caught me.  Because the translation from address to sector number
is different between various LPC parts, I chose to do it the simple
way.

4/ In what cases would memmap be anything other than user code in 
practice ? (I notice you save and restore).

*** Not exactly.  The interrupt vectors could have been remapped
to RAM.

-- 
Cheers,
Bruce

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 
the flash.  In addition to the corruption due to previously high bit being 
programmed low the internal EDC code will be wrong for that 16 byte block 
now.  Basically once a 16 byte block has been modified no further 
successful changes can be made to it, any modifications will result in 
corrupted memory.

Oh, BTW, erasing flash results in all high bits (0xFF).

>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 
flash memory.  They only differ in the details of what may be written and 
in what size of chunk.  Many allow any high bit to be programmed low, the 
LPC error correction circuitry treats 16byte block as a single location 
that must be dealt with as a unit and only programmed from all 1's once 
between erases.  Erase, on the other hand, uses larger chunk sizes.  8K I 
think is the smallest.

I hope that clears things up a bit.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

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
-------------------------------------------------------------------

Bill Knight wrote:
> 2/ If the iap routines don't return till all is done, what happens to 
> the watchdog ? The watchdog cannot be disabled once started, so do
> a) the iap routines feed the watchdog internally (philips question) ?
> b) we need to reboot with watchdog disabled in order to do IAP ?
> 
> *** I'll leave the answer for this one to the Philis Apps guys.

Robert ?

-- 
Cheers,
Bruce
-------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager.

     /\\\/\\\/\\\    /   /      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
-------------------------------------------------------------------