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
Getting my LPC2148 to boot by itself ! (JTAG Flashing, Openocd, hard reset)
Started by ●February 2, 2007
Reply by ●February 3, 20072007-02-03
Reply by ●February 3, 20072007-02-03
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 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.
>
>
Reply by ●February 3, 20072007-02-03
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 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
Reply by ●February 3, 20072007-02-03
On Sat, 2007-02-03 at 16:14 +0100, Dominic Rath wrote:
> 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 ".
I checked the device flash memory and its the same whether I use
lpc2K_pgm or open-ocd to program it. I'll double check this. It would
be great if that was the problem.
>
> 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 ".
I checked the device flash memory and its the same whether I use
lpc2K_pgm or open-ocd to program it. I'll double check this. It would
be great if that was the problem.
>
Reply by ●February 3, 20072007-02-03
The problem was that I was feeding openocd a hex file
instead of a binary file. Now my code runs.
I did check the first 64 bytes of the device when programmed by
lpc2k_pgm and JTAG/openocd and they were the same. I did this several
times. I can't figure out how that could be.
Anyway, my code runs. Thanks for replying to my posts and listening to
my blatherings.
instead of a binary file. Now my code runs.
I did check the first 64 bytes of the device when programmed by
lpc2k_pgm and JTAG/openocd and they were the same. I did this several
times. I can't figure out how that could be.
Anyway, my code runs. Thanks for replying to my posts and listening to
my blatherings.
