Lpc2000

Thanks, Jayasooriah.

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guile,
> 
> I am happy to clarify by way of annotation:
> 
> --- In lpc2000@yahoogroups.com, "Guillermo Prandi" 
<yahoo.messenger@> wrote:
>  >
>  > Oh, I think I see the point, now. From what you say I get the
>  > following:
>  >
>  > 1) I have no choice but to go through the embedded bootloader 
for the
>  > initial programming.
> 
> Philips boot loader update distribution contains (authoritative) 
code that 
> will update the boot sector for any of the LPC devices for which 
they have 
> released boot loader updates.
> 
> This can be used (after stripping the "protective" bits) in lieu of 
IAP 
> calls to switch between the original and alternate boot loaders.  
You may 
> need to switch back to the original boot loader, for example, if 
your board 
> needs to be sent back for repair.
> 
>  > 2) Using the embedded bootloader should work if I am careful 
enough
>  > to provide the correct crystal frequency. However, as the writing
>  > procedure seems to be poorly implemented, a write-read-compare 
cycle
>  > should be considered.
> 
> I do not think write-read-compare cycle will work because when 
things go 
> wrong and the write or erase fails the IAP call may not return:
> 
> 1/  While erase or write operation is in progress, the flash memory 
is not 
> accessible.  Writes will (in general) have no effect and read (in 
general) 
> always return ones.
> 
> 2/  For this reason, the boot loader loads into and runs from RAM a 
stub of 
> code that starts the erase or write command, sits in a programmed 
loop, and 
> then terminates command and returns.
> 
> 2/  However when this stub returns before the flash is ready the 
CPU is now 
> in the wilderness.
> 
> 3/  At some time when the flash becomes ready, the processor starts 
getting 
> real data from on-chip flash from wherever its PC is pointing to, 
and what 
> happens next is disaster.
> 
>  > 3) I might get a non-functional unit if my program misbehaves and
>  > accidentally runs code that erases the provided bootloader. This
>  > is "unavoidable" since the processor lacks some kind of hardware
>  > protection to prevent this to happen accidentally.
> 
> Correct.  All the flash memories (embedded and external) that I 
have dealt 
> with have some kind of feed sequences to prevent accidents like 
these.
> 
> I cannot find any evidence of such sequences in the boot loader for 
2105, 
> 2292.  I believe the situation is the same for all the LPC series 
because 
> they use a the same boot loader code, one for 2104/5/6 and another 
for the 
> others,
> 
>  > 4) I have the choice (however undocummented) to write my own
>  > bootloader. If this bootloader lacks flash memory programming
>  > capabilities I might be safer because my potentially misbehaving
>  > application will not be able to jump in the middle of the flash
>  > programming code and accidentally erase the bootloader or other 
parts
>  > of the flash.
> 
> You can use the provided boot loader if you are prepared to live 
with the 
> problems people have raised in this forum with respect to flash 
programming.
> 
> Writing your own boot loader that does not deal with flash memory 
is IMO a 
> low risk option.  By looking at what the provided boot loader does 
between 
> reset and running user code, you can work out the couple of 
instructions 
> your own boot loader needs to run.
> 
> Replacing flash algorithms is more involved and higher risk because 
you 
> have to rely on suck-and-see assurances.
> 
> However, if you do not require flash for your application and only 
need it 
> for purposes of firmware updates, and you only will run 
authoritative code, 
> then there is nothing stopping you from using the very code that is 
used by 
> Philips in their boot loader update distribution.
> 
> Regards,
> 
> Jaya
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>