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
>