Lpc2000

> 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