Oddly enough guys, this time when I flashed with OpenOCD, everything
worked out flawlessly.

I think it had something to do with how I was compiling the code (I
made some changes to the makefile that may have screwed things up). Or
maybe I just did everything right this time.

In the process of preparing the data and logs from OpenOCD fro
Dominic, I realized that the program was running (I hadn't gotten it
to work before). So the I reset the board and to my surprise the
program ran after the reset.

Well, I'm glad it's working now, and here is the package of files for
the OpenOCD flashing anyway (includes demo2148_flash_led source code,
compiled elf/hex/bin, log of erasing/flashing/dumping, flash dump
after an erase, and flash dump after flashing):
http://www.breezynet.com/electronics/stuff/LEDJTAGFlash.zip

I guess it just serves as evidence that OpenOCD flashes the LPC2148
correctly.

Thanks a lot Richard and Dominic!

Thanks sixtyfivebit.

--- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@...> wrote:
>
> 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
> 
and
> 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
	

--- 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
	

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
>
>
>

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
	

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.
> > > >
> > >
> >
>
	

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.
> > >
> >
>
	

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.
> >
>
	

--- 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.
>
	

> 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.
	

> 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