Lpc2000

Hi,

I'm very new to ARM and LPC.
I read that very writing into the Flash must be done via the onchip
bootloader which resides alsp in the Flash. This is true for download
via the serial port and also for write accesses by the application.

Question:
Is there way to write into the Flash without using the Bootloader?
I think of building a very specialized Bootloader which works on the
SPI, I2C or TCP/IP. 

I read in this forum that it is possible to destroy the Bootloader
content and then the chip becomes an OTP :-)
And here should be the way to write some RAM parts via JTAG, download
a small loader into the RAM also via JTAG and then let the CPU jump
into this loader which then at least can download a new firmware and
(maybe) also a new bootloader into the bootloader section.

Any hints or links?

Rolf

At 01:07 PM 3/12/04 +0000, you wrote:
>Question:
>Is there way to write into the Flash without using the Bootloader?
>I think of building a very specialized Bootloader which works on the
>SPI, I2C or TCP/IP.

You can use the IAP interface.


>I read in this forum that it is possible to destroy the Bootloader
>content and then the chip becomes an OTP :-)

I haven't heard of that being duplicated.  Has it been?  Philips 
documentation suggests that the on-chip SW locks out access to the segment 
containing the bootloader and IAP.  It also contains (in some places) 
wording that hints the segment could be replaced.  Some of the 
documentation on the startup also seemed to suggest (when I last read it) 
that the micros startup, such as checking the exception vectors, is done 
with code from this segment so erasing or modifying the segment could 
result in an inoperable chip.

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

Robert,

> You can use the IAP interface.

Yes, I know. But is the IAP a part of the Bootloader? If I interprete
the docs correctly, I think this is the case. And exactly this is not
what I want.

The LPC2106 User Manual shows this:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
JTAG FLASH PROGRAMMING INTERFACE
There are three possibilities for this interface:

1. Debug tools can write parts of the flash image to the RAM and then
execute the IAP call "Copy RAM to Flash" repeatedly with proper offset

2. Debug tools can execute the flash programming code via JTAG port.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

The second item is of interest, but I can not find anything about this
in the docs. And there should be ITEM-3 but it is not there :-)
And a bit more strange, the User Manual of the LPC2119 shows only 
paragraph-1 ....

Rolf

At 03:21 PM 3/12/04 +0000, you wrote:
> > You can use the IAP interface.
>
>Yes, I know. But is the IAP a part of the Bootloader? If I interprete
>the docs correctly, I think this is the case. And exactly this is not
>what I want.

It depends on how you define "bootloader".  It is in the same segment and I 
would expect it to use the same programming routines, but it doesn't 
require entering a boot mode.


>The LPC2106 User Manual shows this:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>JTAG FLASH PROGRAMMING INTERFACE
>There are three possibilities for this interface:
>
>1. Debug tools can write parts of the flash image to the RAM and then
>execute the IAP call "Copy RAM to Flash" repeatedly with proper offset
>
>2. Debug tools can execute the flash programming code via JTAG port.

AFAIK those are the same method.  Programming via JTAG means copying to RAM 
and calling the IAP to do the actual programming.  This would be one of 
those places that hint at other possibilities.  I suspect that most of 
those hints are unintended.

><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>The second item is of interest, but I can not find anything about this
>in the docs. And there should be ITEM-3 but it is not there :-)
>And a bit more strange, the User Manual of the LPC2119 shows only
>paragraph-1 ....

I suspect that the 2119 documentation is correct.  As is often the case the 
documentation is lagging the silicon, and has its own errors.

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

Robert Adsett wrote:
> Some of the 
> documentation on the startup also seemed to suggest (when I last read it) 
> that the micros startup, such as checking the exception vectors, is done 
> with code from this segment so erasing or modifying the segment could 
> result in an inoperable chip.

However, one could read out the ISP/IAP code from the boot sector in 
FLASH (I know it won't let you read it out itself, but you could upload 
a program that DOES read it out to you), disassemble it, remove the 
restrictions on overwriting itself and so on, and then use the new 
version [relocated into RAM or whatnot] to overwrite the original.

> 
> Robert
> 

ABS

Hi,

after all what I read here and in the docs there must be some 
instructions
and mechanism to write/change any flash content. Of course protected
ones are excluded. But where can I find any docs how the application
itself can directly change some flash locations without using the 
API??

The API itself manages this and after a disassembly of this part one
can see how it works. But why is there such a secret??

rolf

Perhaps because if you write wrong things to the booter or abort writing, it
could be that you must throw away the chip, because you can't flash it
anymore...

Regards,

         Martin

----- Original Message ----- 

From: "rhpascaldodo" <rh@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, March 14, 2004 1:12 PM
Subject: [lpc2000] Re: Writing to Flash


> Hi,
>
> after all what I read here and in the docs there must be some
> instructions
> and mechanism to write/change any flash content. Of course protected
> ones are excluded. But where can I find any docs how the application
> itself can directly change some flash locations without using the
> API??
>
> The API itself manages this and after a disassembly of this part one
> can see how it works. But why is there such a secret??
>
> rolf
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

At 02:25 PM 3/14/04 +0100, you wrote:
>Perhaps because if you write wrong things to the booter or abort writing, it
>could be that you must throw away the chip, because you can't flash it
>anymore...

They may also wish to update the flash (and its programming algorithm) and 
that's harder to do if users have been programming the algorithm themselves 
while a callable version can remain the same despite underlying changes.  I 
belive ST changed their interface on the ST10 for just that reason.  They 
had to update the flash and rather than expose a new set of timing 
requirements they hid the details in a "callable" routine.

There are also support costs to consider.  I have heard that one of the 
largest support costs for flash based micros that expose the algorithm is 
supporting customers implementing the programming software.

Finally, the method that Philips uses to store the programming SW leaves 
open the possibility of tweaking the programming parameters on a batch by 
batch or even chip by chip basis.  If they were to do that it would 
obviously be much more difficult to expose to the public.

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