Hi,

I am trying to flash my LPC2148 through JTAG using openOCD, which
turns out to work, but the program doesn't seem to run.

The program is the stock demo2148_blink_flash from Lynch's ARM/Eclipse
tutorial. I took the elf file and converted it to binary with
arm-elf-objdump: "arm-elf-objdump -O binary demo2148_blink_flash.elf
demo2148_blink_flash.bin"

JTAG seems to work very well, and I have never encountered an error
throughout the use of ocdcommander or openocd. 

My openocd configuration line for the LPC flashing looks like this:
flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v2 0 12000 calc_checksum

Although I'm pretty sure the flash part of the chip is greater than
0x40000, I didn't bother to change it yet. The JTAG emulator I am
using is the popular wiggler clone (in this files section).

After starting openOCD, and telneting in for the command console. I
issue the command: "flash write 0 demo2148_blink_flash.bin 0x0"
(demo2148_blink_flash.bin is of course in the same directory as the
openOCD executable).

It flashes the chip without a hitch, and then I disconnect JTAG/close
openOCD, unplug the JTAG jumper and reset the board. ... the LED isn't
flashing ...

So for investigation, I readback the flash from 0x40000000 to
0x400003B0 to see that the data was flashed, but some parts seem to
be "rearranged?" Here are the raw binary files:

http://www.breezynet.com/BinaryFile   (632bytes)
http://www.breezynet.com/FlashOnChip  (944bytes)

Is what I see in the flash due to the checksum insertion routines
OpenOCD executes? Does everything look good in general?

I'm new to all of this JTAG flashing business so please bear with me.
If there is any other sample code or detailed instructions on this
type of flashing that would be appreciated as well.. I can't seem to
find much information online about JTAG flashing for the LPC series
chips, probably because most are using the bootloader/rs-232 method
(which I can't do in my case).

Thanks-sixtyfivebit.
	

> It flashes the chip without a hitch, and then I
disconnect JTAG/close
> openOCD, unplug the JTAG jumper and reset the board. ... the LED isn't
> flashing ...

If the program doesn't run properly, how do you know you are flashing?
 I don't know anything about your environment but I don't have to
remove my DEBUG jumper or reset the board.  The Rowley CrossConnect
does the flashing and either hangs around for debugging or just resets
the ARM.  It will debug out of RAM or flash - a very nice feature!

> 
> So for investigation, I readback the flash from 0x40000000 to
> 0x400003B0 to see that the data was flashed, but some parts seem to
> be "rearranged?" Here are the raw binary files:

Why are you looking at RAM addresses if the program is to run out of
flash?

Or, are you using the RAM demo?

> 
> http://www.breezynet.com/BinaryFile   (632bytes)
> http://www.breezynet.com/FlashOnChip  (944bytes)
> 
> Is what I see in the flash due to the checksum insertion routines
> OpenOCD executes? Does everything look good in general?

Only at address 0x00000014 should there be a difference for the
checksum.  I didn't open the links...

> 
> I'm new to all of this JTAG flashing business so please bear with me.
> If there is any other sample code or detailed instructions on this
> type of flashing that would be appreciated as well.. I can't seem to
> find much information online about JTAG flashing for the LPC series
> chips, probably because most are using the bootloader/rs-232 method
> (which I can't do in my case).

Too bad about not being able to use serial programming.  It is a good
place to start before adding the complication of JTAG.  Frankly, I
would find a way to make it work if for no other reason than to get a
cross check on JTAG.

I did a lot of development with ISP on the LPC2106 before I moved to
Rowley CrossWorks.  JTAG is a wonderful thing but it isn't a required
thing.

Richard
	

> Why are you looking at RAM addresses if the program is to run out of
> flash?
> 
> Or, are you using the RAM demo?

I was flashing the demo2148_blink_flash, but I was unaware I was
looking in the RAM addresses... Sorry about that. I must have loaded
the code in the RAM at some point when I was messing with
ocdcommander, or mayber OpenOCD puts the data in the RAM before
flashing it. Anyway, I'll look up the flash addresses and check for
the program there (you can do this right, read back from the flash?)

In that case, please disregard the links...

Thanks for the info Richard. I'll also check out CrossWorks.

Thanks-sixtyfivebit.
	

--- In lpc2000@lpc2..., "sixtyfivebit" <sixtyfivebit@...>
wrote:
>
> > Why are you looking at RAM addresses if the program is to run out of
> > flash?
> > 
> > Or, are you using the RAM demo?
> 
> I was flashing the demo2148_blink_flash, but I was unaware I was
> looking in the RAM addresses... Sorry about that. I must have loaded
> the code in the RAM at some point when I was messing with
> ocdcommander, or mayber OpenOCD puts the data in the RAM before
> flashing it. Anyway, I'll look up the flash addresses and check for
> the program there (you can do this right, read back from the flash?)

I haven't tried OpenOCD although I did download it.  With CrossConnect
you definitely can read flash or RAM.

> 
> In that case, please disregard the links...
> 
> Thanks for the info Richard. I'll also check out CrossWorks.
> 
> Thanks-sixtyfivebit.
>
	

I found a program called "CrossLoad" apart of the CrossWorks ARM
Kickstart 32k version. It seems to do everything I need it to do:

c:\Program Files\Rowley Associates Limited\CrossWorks for ARM
1.5\bin>crossload -target wiggler20 -solution
Externally_Built_Executable_1.hzp -project
Externally_Built_Executable_1 -config Flash main.hex

Programming completed in 141.0 milliseconds (26326.2 bytes/sec)
Erasing completed in 360.0 milliseconds (2166.7 bytes/sec)
Programming completed in 47.0 milliseconds (16595.7 bytes/sec)
Verifying completed in 46.0 milliseconds (16956.5 bytes/sec)

Externally_Built_Executable_1 are dummy solutions/projects. Even
though it seems to have flashed successfully, the program doesn't run: 

When I made the dummy solution/projet I chose the target device to be
LPC2104. The solution file has references to the memory map and other
device-specific information of the LPC2104, so I'm sure this is what
the program crossload looks to when flashing. 

Does anyone know if Rowley have these definitions for LPC2148?

Thanks-sixtyfivebit.

--- In lpc2000@lpc2..., "rtstofer" <rstofer@...> wrote:
>
> --- In lpc2000@lpc2..., "sixtyfivebit" <sixtyfivebit@>
wrote:
> >
> > > Why are you looking at RAM addresses if the program is to run out
of
> > > flash?
> > > 
> > > Or, are you using the RAM demo?
> > 
> > I was flashing the demo2148_blink_flash, but I was unaware I was
> > looking in the RAM addresses... Sorry about that. I must have loaded
> > the code in the RAM at some point when I was messing with
> > ocdcommander, or mayber OpenOCD puts the data in the RAM before
> > flashing it. Anyway, I'll look up the flash addresses and check
for
> > the program there (you can do this right, read back from the flash?)
> 
> I haven't tried OpenOCD although I did download it.  With CrossConnect
> you definitely can read flash or RAM.
> 
> > 
> > In that case, please disregard the links...
> > 
> > Thanks for the info Richard. I'll also check out CrossWorks.
> > 
> > Thanks-sixtyfivebit.
> >
>
	

Richard,

I just used the LPC2138 memory map file, which has the same flash
memory bounds as the LPC2148. I flashed with "CrossLoad" and my LED
now blinks!

Thanks a lot, I'm glad I can finally get my code running on this chip,
especially with this convenient program.

Thanks, sixtyfivebit.

--- In lpc2000@lpc2..., "sixtyfivebit" <sixtyfivebit@...> wrote:
>
> I found a program called "CrossLoad" apart of the CrossWorks ARM
> Kickstart 32k version. It seems to do everything I need it to do:
> 
> c:\Program Files\Rowley Associates Limited\CrossWorks for ARM
> 1.5\bin>crossload -target wiggler20 -solution
> Externally_Built_Executable_1.hzp -project
> Externally_Built_Executable_1 -config Flash main.hex
> 
> Programming completed in 141.0 milliseconds (26326.2 bytes/sec)
> Erasing completed in 360.0 milliseconds (2166.7 bytes/sec)
> Programming completed in 47.0 milliseconds (16595.7 bytes/sec)
> Verifying completed in 46.0 milliseconds (16956.5 bytes/sec)
> 
> Externally_Built_Executable_1 are dummy solutions/projects. Even
> though it seems to have flashed successfully, the program doesn't run:

> 
> When I made the dummy solution/projet I chose the target device to be
> LPC2104. The solution file has references to the memory map and other
> device-specific information of the LPC2104, so I'm sure this is what
> the program crossload looks to when flashing. 
> 
> Does anyone know if Rowley have these definitions for LPC2148?
> 
> Thanks-sixtyfivebit.
> 
> --- In lpc2000@lpc2..., "rtstofer" <rstofer@> wrote:
> >
> > --- In lpc2000@lpc2..., "sixtyfivebit" <sixtyfivebit@>
wrote:
> > >
> > > > Why are you looking at RAM addresses if the program is to
run
out of
> > > > flash?
> > > > 
> > > > Or, are you using the RAM demo?
> > > 
> > > I was flashing the demo2148_blink_flash, but I was unaware I was
> > > looking in the RAM addresses... Sorry about that. I must have
loaded
> > > the code in the RAM at some point when I was messing with
> > > ocdcommander, or mayber OpenOCD puts the data in the RAM before
> > > flashing it. Anyway, I'll look up the flash addresses and
check for
> > > the program there (you can do this right, read back from the
flash?)
> > 
> > I haven't tried OpenOCD although I did download it.  With
CrossConnect
> > you definitely can read flash or RAM.
> > 
> > > 
> > > In that case, please disregard the links...
> > > 
> > > Thanks for the info Richard. I'll also check out CrossWorks.
> > > 
> > > Thanks-sixtyfivebit.
> > >
> >
>
	

On the other hand, when I reset the chip, the program no longer runs.

It seems that although I set my configuration to be "Flash" or
"ARM
Flash Release" or anything that has "Flash" in it, it still
stores to
the RAM!?

Is there something I missing? Does the CrossWorks project
configuration itself need to be configured somewhere?

Thanks sixtyfivebit

--- In lpc2000@lpc2..., "sixtyfivebit" <sixtyfivebit@...> wrote:
>
> Richard,
> 
> I just used the LPC2138 memory map file, which has the same flash
> memory bounds as the LPC2148. I flashed with "CrossLoad" and my
LED
> now blinks!
> 
> Thanks a lot, I'm glad I can finally get my code running on this chip,
> especially with this convenient program.
> 
> Thanks, sixtyfivebit.
> 
> --- In lpc2000@lpc2..., "sixtyfivebit" <sixtyfivebit@>
wrote:
> >
> > I found a program called "CrossLoad" apart of the CrossWorks
ARM
> > Kickstart 32k version. It seems to do everything I need it to do:
> > 
> > c:\Program Files\Rowley Associates Limited\CrossWorks for ARM
> > 1.5\bin>crossload -target wiggler20 -solution
> > Externally_Built_Executable_1.hzp -project
> > Externally_Built_Executable_1 -config Flash main.hex
> > 
> > Programming completed in 141.0 milliseconds (26326.2 bytes/sec)
> > Erasing completed in 360.0 milliseconds (2166.7 bytes/sec)
> > Programming completed in 47.0 milliseconds (16595.7 bytes/sec)
> > Verifying completed in 46.0 milliseconds (16956.5 bytes/sec)
> > 
> > Externally_Built_Executable_1 are dummy solutions/projects. Even
> > though it seems to have flashed successfully, the program doesn't
run: 
> > 
> > When I made the dummy solution/projet I chose the target device to be
> > LPC2104. The solution file has references to the memory map and other
> > device-specific information of the LPC2104, so I'm sure this is
what
> > the program crossload looks to when flashing. 
> > 
> > Does anyone know if Rowley have these definitions for LPC2148?
> > 
> > Thanks-sixtyfivebit.
> > 
> > --- In lpc2000@lpc2..., "rtstofer" <rstofer@> wrote:
> > >
> > > --- In lpc2000@lpc2..., "sixtyfivebit"
<sixtyfivebit@>
wrote:
> > > >
> > > > > Why are you looking at RAM addresses if the program is
to run
> out of
> > > > > flash?
> > > > > 
> > > > > Or, are you using the RAM demo?
> > > > 
> > > > I was flashing the demo2148_blink_flash, but I was unaware I
was
> > > > looking in the RAM addresses... Sorry about that. I must
have
loaded
> > > > the code in the RAM at some point
when I was messing with
> > > > ocdcommander, or mayber OpenOCD puts the data in the RAM
before
> > > > flashing it. Anyway, I'll look up the flash addresses
and
check for
> > > > the program there (you can do this
right, read back from the
flash?)
> > > 
> > > I haven't tried OpenOCD although I did download it.  With
CrossConnect
> > > you definitely can read flash or RAM.
> > > 
> > > > 
> > > > In that case, please disregard the links...
> > > > 
> > > > Thanks for the info Richard. I'll also check out
CrossWorks.
> > > > 
> > > > Thanks-sixtyfivebit.
> > > >
> > >
> >
>
	

Hi, 

> I found a program called "CrossLoad"
apart of the CrossWorks 
> ARM Kickstart 32k version. It seems to do everything I need it to do:

Bugger me.  I didn't know we'd introduced a 32K KickStart CrossWorks. 
I
must talk to the engineers to see how that slipped out...

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
	

Hello,

if you're still having problems (you mentioned issues with CrossLoad, too),
it 
would be nice if you could send me a memory dump from flash (address 0x0 to 
0x7ffff) together with the binary you wanted to flash, and maybe even the elf 
file you've built.

OpenOCD should work, I've just verified that I could successfully flash Jim

Lynch's blinking led example to a LPC2294. After resetting the board, the
LED 
started flashing. I would be very interested to find out why it didn't work

for you.

Regards,

Dominic

On Thursday 23 March 2006 02:39, sixtyfivebit wrote:
> > Why are you looking at RAM addresses if the program is to run out of
> > flash?
> >
> > Or, are you using the RAM demo?
>
> I was flashing the demo2148_blink_flash, but I was unaware I was
> looking in the RAM addresses... Sorry about that. I must have loaded
> the code in the RAM at some point when I was messing with
> ocdcommander, or mayber OpenOCD puts the data in the RAM before
> flashing it. Anyway, I'll look up the flash addresses and check for
> the program there (you can do this right, read back from the flash?)
>
> In that case, please disregard the links...
>
> Thanks for the info Richard. I'll also check out CrossWorks.
>
> Thanks-sixtyfivebit.
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>

--- In lpc2000@lpc2..., "sixtyfivebit" <sixtyfivebit@...>
wrote:
>
> On the other hand, when I reset the chip, the program no longer runs.
> 
> It seems that although I set my configuration to be "Flash" or
"ARM
> Flash Release" or anything that has "Flash" in it, it still
stores to
> the RAM!?
> 
> Is there something I missing? Does the CrossWorks project
> configuration itself need to be configured somewhere?
> 
> Thanks sixtyfivebit

I built my program for various configurations just to test things like
code size (Thumb vs ARM), execution speed (flash vs RAM) and type
(debug vs release).  It was very interesting.

Nevertheless, when I program the device with ARM Flash Release, it
does set up the flash.  I can remove the JTAG cable and cycle power
(no simple reset button for me!) and it works properly.

Keep kicking until you find the problem.  You're getting close!

Richard