Lpc2000

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