Hi,

On Saturday 03 February 2007 15:58, armdeveloper wrote:
>[snip]
> I've been using lpc2k_pgm and yes that works. I need to start testing
> my device as a stand alone unit now. It needs to start running on its
> own.
>
> I cannot figure out why it boots when programmed with the lpc2k_pgm
> software and not when programmed with the JTAG unit. Its the very same
> hex file.

The OpenOCD expects a binary, not an Intel HEX file. When using the GNU tools,
you can create a binary out of the ELF executable with "arm-xxx-objcopy -O
binary ".

Regards,

Dominic

On Sat, 2007-02-03 at 14:36 +0000, rtstofer wrote:
> The UM indicates that MEMMAP = 0 on reset and discusses how the
> vectors are overlayed at startup so that the bootloader gets initial
> control. Then it describes how the bootloader tests the checksum and
> eventually branches to 0x00000000 and the user' reset entry point.
>
> The one fact that is omitted is that MEMMAP = 0x01 by the time the
> user code gets control.

I checked MEMMAP with my JTAG debugger and its 0x01 for both of the
situations, ie when it runs and when it doesn't.

> I just printed the value of MEMMAP in a
> working program after the chip is fully initialized and main() is
> running. It is indeed 0x01 and my code doesn't touch it.
>
Same here.

> So, if your program is not running after reset, it is not because you
> need to diddle with MEMMAP. It should start as long as the checksum
> is correct and P0.14 is high coming out of reset.

Good to know, but I looked at the bottom 64 bytes of code using my JTAG
pod and they are the same for the situation where it runs and it doesn't
run.

And I have a voltmeter on P0.14 and its high.

I'm totally scratching my head on this.
> One way to test all of this is to back up to the lowest common
> denominator and use lps21isp to program the flash. This guarantees
> that the checksum is correct. It isn't the fastest way to set up the
> flash and it doesn't support debugging but it is useful for a test.
>

I've been using lpc2k_pgm and yes that works. I need to start testing
my device as a stand alone unit now. It needs to start running on its
own.

I cannot figure out why it boots when programmed with the lpc2k_pgm
software and not when programmed with the JTAG unit. Its the very same
hex file.

>

>

The UM indicates that MEMMAP = 0 on reset and discusses how the
vectors are overlayed at startup so that the bootloader gets initial
control. Then it describes how the bootloader tests the checksum and
eventually branches to 0x00000000 and the user' reset entry point.

The one fact that is omitted is that MEMMAP = 0x01 by the time the
user code gets control. I just printed the value of MEMMAP in a
working program after the chip is fully initialized and main() is
running. It is indeed 0x01 and my code doesn't touch it.

So, if your program is not running after reset, it is not because you
need to diddle with MEMMAP. It should start as long as the checksum
is correct and P0.14 is high coming out of reset.

One way to test all of this is to back up to the lowest common
denominator and use lps21isp to program the flash. This guarantees
that the checksum is correct. It isn't the fastest way to set up the
flash and it doesn't support debugging but it is useful for a test.

Richard

--- In l..., armdeveloper wrote:
>
> On Sat, 2007-02-03 at 00:15 +0000, derbaier wrote:
> > --- In l..., armdeveloper wrote:
> > >
> > >
> > > Pardon me, to get user flash mode, one should write 0x01 to MEMMAP.
> > >
> > > So where do I place the code to do that when the processor comes out
> > of
> > > reset in boot mode ?
> > >
> > > Thanks
> > >
> > >
> > >
> >
> > The LPC2148 will come of reset in boot mode and run the LPC
> > bootloader. When the bootloader is finished doing it's thing, it will
> > switch your vectors into the map itself, and jump to your reset
> > vector. When your code starts to run, MEMMAP will already be set to
> > one. You can then remap the vectors to RAM if your code needs to be
> > able to modify the vectors in normal operation. The main point is,
> > that coming out of reset the Phillips bootloader is always going to
> > run before your code runs. That is part of how Phillips implements
> > it's Code Read Protection.
>
> Are you sure about that ?
>
> http://www.hitex.co.uk/arm/lpc2000book/
>
> On page 50, section 3.6.2 says this:
>
> "Every time the LPC2000 comes out of reset its memory map will be in
> boot mode, so the instruction on the reset vector will cause it to jump
> into the bootloader code entry point at 0x7FFFFFFF. This can be the
> bane of new users if they load their code into FLASH with a JTAG., reset
> and single step the first instruction only to find that the program
> counter is at some wild high address. If this happens, you need to
> program the MEMMAP register to 0x00000002, to force the chip into FLASH
> mode and return the user vector table."
>
> So this doesn't sound like anything happens automatically.
>
> So how do I program MEMMAP ?
>
>
I can assure you that your program WILL start from flash without
changing MEMMAP. In fact, upon review of a couple of my projects, I
don't change MEMMAP at all even on programs using interrupts.

But I do see an example where I commented out setting MEMMAP just
after setting up MAMCR and MAMTIM by just MEMMAP = 0x01;

You know, section 21.4 and more specifically section 21.4.2 of the
User Manual covers all this.

On reset the bootloader maps its' own vectors to force startup of the
bootloader code. During the process, the bootloader disables the
overlaying and does the checksum on the user's vectors and, if
correct, branches to 0x00000000 and, at that point, the user's vectors
are in place.

AFAIK, nothing needs to be done to MEMMAP to get your program to run
out of flash. You can set it to 0x01 if you wish but it doesn't seem
to be required. Or maybe the bootloader does it for you; I can't say
that I have ever read the contents of MEMMAP to see what it contains.

In any event, it just doesn't matter. I just write the code, stuff it
in flash and it runs.

Richard

I just programmed the flash on my 2148 with lpc2k_pgm and with my JTAG
using openocd.

I then used openocd to read the first 64 bytes of memory for each using
dump_binary from telnet. I compared the files and they are binary
equals. I take this to mean that lpc2k and the JTAG programmer
calculated the same value for 0x14.

Yet the lpc2K loaded file will run from reset and the JTAG won't.
Also, the lpc2k WILL boot with "Reboot" but will not boot with
"Bootloader"

So the device is being programmed the same by the lpc2K and the JTAG
(openocd). The security code appears to be the same for the lpc2K and
JTAG programming.

It runs with an lpc2K Program/Reboot. After that is done, it will run
with a hardware reset.

It won't run with
- JTAG program/reset
- lpc2K Bootloader
- hardware reset

WHY ?

On Sat, 2007-02-03 at 01:25 +0000, Brendan Murphy wrote:

>
> The description above is correct. The LPC book quote is referring to
> the difficulty of setting a breakpoint at the very start of a
> program, as (in normal operation) the first thing that runs is the
> boot loader. It's only when it's done it's stuff the application
> runs. Unless you want to single step through the bootloader, there
> has to be a better way of debugging teh startup code. The better way
> is to use the debugger to set MEMMAP so that the bootloader is
> effectively bypassed when reset by the debugger. It's really only
> relevent when debugging though.
>
> Although it takes a while to understand and get used to, it's a
> fairly flexible setup as ARMs go.
>
> Brendan.
>
Thanks for taking the time to explain that, late on a Friday no less.
>

--- In l..., armdeveloper wrote:
>
> On Sat, 2007-02-03 at 00:15 +0000, derbaier wrote:
> > --- In l..., armdeveloper
wrote:
> > >
> > >
> > > Pardon me, to get user flash mode, one should write 0x01 to
MEMMAP.
> > >
> > > So where do I place the code to do that when the processor
comes out
> > of
> > > reset in boot mode ?
> > >
> > > Thanks
> > >
> > >
> > >
> >
> > The LPC2148 will come of reset in boot mode and run the LPC
> > bootloader. When the bootloader is finished doing it's thing, it
will
> > switch your vectors into the map itself, and jump to your reset
> > vector. When your code starts to run, MEMMAP will already be set
to
> > one. You can then remap the vectors to RAM if your code needs to
be
> > able to modify the vectors in normal operation. The main point is,
> > that coming out of reset the Phillips bootloader is always going
to
> > run before your code runs. That is part of how Phillips implements
> > it's Code Read Protection.
>
> Are you sure about that ?
>
> http://www.hitex.co.uk/arm/lpc2000book/
>
> On page 50, section 3.6.2 says this:
>
> "Every time the LPC2000 comes out of reset its memory map will be in
> boot mode, so the instruction on the reset vector will cause it to
jump
> into the bootloader code entry point at 0x7FFFFFFF. This can be the
> bane of new users if they load their code into FLASH with a JTAG.,
reset
> and single step the first instruction only to find that the program
> counter is at some wild high address. If this happens, you need to
> program the MEMMAP register to 0x00000002, to force the chip into
FLASH
> mode and return the user vector table."
>
> So this doesn't sound like anything happens automatically.
>
> So how do I program MEMMAP ?
>
>
The description above is correct. The LPC book quote is referring to
the difficulty of setting a breakpoint at the very start of a
program, as (in normal operation) the first thing that runs is the
boot loader. It's only when it's done it's stuff the application
runs. Unless you want to single step through the bootloader, there
has to be a better way of debugging teh startup code. The better way
is to use the debugger to set MEMMAP so that the bootloader is
effectively bypassed when reset by the debugger. It's really only
relevent when debugging though.

Although it takes a while to understand and get used to, it's a
fairly flexible setup as ARMs go.

Brendan.

On Sat, 2007-02-03 at 00:15 +0000, derbaier wrote:
> --- In l..., armdeveloper wrote:
> >
> >
> > Pardon me, to get user flash mode, one should write 0x01 to MEMMAP.
> >
> > So where do I place the code to do that when the processor comes out
> of
> > reset in boot mode ?
> >
> > Thanks
> >
> >
> > The LPC2148 will come of reset in boot mode and run the LPC
> bootloader. When the bootloader is finished doing it's thing, it will
> switch your vectors into the map itself, and jump to your reset
> vector. When your code starts to run, MEMMAP will already be set to
> one. You can then remap the vectors to RAM if your code needs to be
> able to modify the vectors in normal operation. The main point is,
> that coming out of reset the Phillips bootloader is always going to
> run before your code runs. That is part of how Phillips implements
> it's Code Read Protection.

Are you sure about that ?

http://www.hitex.co.uk/arm/lpc2000book/

On page 50, section 3.6.2 says this:

"Every time the LPC2000 comes out of reset its memory map will be in
boot mode, so the instruction on the reset vector will cause it to jump
into the bootloader code entry point at 0x7FFFFFFF. This can be the
bane of new users if they load their code into FLASH with a JTAG., reset
and single step the first instruction only to find that the program
counter is at some wild high address. If this happens, you need to
program the MEMMAP register to 0x00000002, to force the chip into FLASH
mode and return the user vector table."

So this doesn't sound like anything happens automatically.

So how do I program MEMMAP ?

>

An Engineer's Guide to the LPC2100 Series