Lpc2000

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.

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.

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.

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.

Correct me if I'm getting you wrong.

Guille

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guile,
> 
> Based on my own experience, and of those who have communicated such 
> problems to me by email, there are two reasons as to why you may 
need to 
> consider custom boot loader in your case where you are not 
concerned with CRP.
> 
> 1/  The coding of the flash programming algorithm in the boot 
loader 
> unreliable because: a) it depends on wait loops rather than polling 
the 
> flash controller status register; and b) it requires clock 
frequency to be 
> passed as a run-time argument.
> 
> 2/  The boot loader includes code that writes to flash, and as the 
flash 
> device is not protected by feed sequences (industry standard for 
flash 
> memories) you can get accidental trashing of the boot loader when 
the 
> application misbehaves.
> 
> I recommend that the boot loader be replaced with one that is 
simple and 
> does not include flash programming code.  A simple loader is less 
likely to 
> be plagued by bugs.  The absence of code to program flash makes it 
more 
> robust with respect to application misbehavior in the field.
> 
> There is nothing we can do about the flash device not having 
industry 
> standard protective feed sequences -- so the less code there is in 
memory 
> that is capable of modifying on-chip flash, the safer your system 
is going 
> to be in the field.
> 
> Field upgrades can be done by sending down your upgrade application 
that 
> includes flash programming code which is discarded once the upgrade 
is 
> complete.  The code to program the flash is minimal -- at last 
count my 
> flash library itself (written in C) was 820 bytes.
> 
> Hope this helps.
> 
> Jaya
> 
> --- In lpc2000@yahoogroups.com, "Guillermo Prandi" 
<yahoo.messenger@> wrote:
>  >
>  > Thanks, Jayasooriah.
>  >
>  > This however leaves me with more questions than before. I am not
>  > particularly interested in code read protection. However, my 
company
>  > designed a board using LPC2138/LPC2148 and I would like to know 
if I
>  > am likely to encounter problems when programming those boards, 
what
>  > kind of problem will they be and if can or can't I avoid them. 
We use
>  > plain UART0 interface for the one-time programming 
(occasionally, a
>  > firmware upgrade might kick in, also using the standard 
bootloader).
>  > We will be using the Philips utility for the task. If you have 
some
>  > info about that, please let me know.
>  >
>  > Guille
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>