JTAG Programming with LPC4330

Question

Because the Example Virtual Serial Device project from NXPUSBLib contains a space in it's directory structure (specifically Example_VirtualSerialDevice/LPC43xx M4/...) I can not successfully download code through the GUI programming tool in LPCXpresso.

So, I have attempted to compile a binary file, and download to my LPCXplorer4330's M4 core. This results in the error included at the end of this post.

Do you have any suggestions as to how I can get some code downloading? I'm running Ubuntu 12.10 x32, and the LPC-Link JTAG programmer.

I have quadruple checked file permissions, and have tried multiple combinations of AXF files or BIN files.

Thank You!

$ crt_emu_lpc18_43_nxp -wire=winusb -pLPC4330 -vendor=NXP -flash-load-exec=~/Desktop/Example_VirtualSerialDevice.bin -load-base-address=0x14000000
Ni: LPCXpresso Debug Driver v4.0 (Sep 19 2012 09:15:29)
Nc: Looked for chip XML file in /usr/local/lpcxpresso_4.3.0_1025/lpcxpresso/bin/LPC4330.xml

Nc: Looked for vendor directory XML file in /usr/local/lpcxpresso_4.3.0_1025/lpcxpresso/bin/nxp_directory.xml

Nc: Found generic directory XML file in /usr/local/lpcxpresso_4.3.0_1025/lpcxpresso/bin/crt_directory.xml

Nc: Emu(0): Conn&Reset. DpID: 2BA01477. Info: LPCLINK_1_1
Nc: SWD Frequency: 3000 KHz. RTCK: False. Vector catch: False.
Nc: Packet delay: 0  Poll delay: 0.
Nc: NXP: LPC4330  Part ID: 0x00000000
Cr:v Registered license, download limit of 128K
Et:58: Cannot open binary file 'Example_VirtualSerialDevice.bin'

Answer 1

I'm not sure which development board you are using here, so YMMV with this, but:

1) Use straight JTAG with a tool like OpenOCD. If you have the lpc4330-xplorer, like I do, however, this can be a little tricky (if you are trying to debug the flash boot configuration of this board (1-on, 2-off, 3-off, 4-off on the configuration dipswitch), then it requires a double reset 99.9% of the time (I have seen one or two times where this was NOT the case.) According to everything I've come across, this was due to a silicon bug. At any rate, I usually don't load code this way.

2) Use the NXP onboard bootrom to load your code. It works with USB0 of the lpc4330. As you likely need to power your development board, this is probably already connected (unless you have a separate power plug). The tools you will need are these:

http://www.lancos.com/lpc_dfu-1.02.tar.gz

This talks to the SPIflash bootloader from NXP (which is included in the tar). You will also need a recent copy of dfu-util. I use 0.7, but there are much newer versions. At any rate, to write to RAM:

dfu-suffix -a filename -v 0x1fc9 -p 0x000c
dfu-prefix -a filename -L
dfu-util -D filename

This will put your code directly into RAM and it will be runnable. The first command provides DFU with the info for finding your dev board (so you may have a different vid and pid here). The second command puts the LPC header on the binary so that the bootloader will be able to use it. The final command sends it. Remember, this ONLY WORKS if you use a RAM configuration. This means, ANY LINKER FILE YOU USE MUST PUT YOUR CODE INTO RAM! Read that last one again. If you build something and link it for FLASH, then write it to RAM, this will FAIL and your processor will sit there looking about as active as the sand it was made from. If you want to FLASH the code:

1) dfu-util -d 0x1fc9:0x000c -D iram_dfu_util_spiflash.bin.hdr

2) lpcdfu -d 3 -e -D "filename" -U -L "logfile name" -C "command logfile" -A 0x14000000

This will first send over the spiflasher. Secondly, it uses lpcdfu to talk to the spiflasher code. Now, this works for an lpc4330-xplorer. If you have a DIFFERENT development board that does NOT have an spiflash, this likely will not work, but the first method will still allow you to run out of RAM. As before, MAKE SURE YOUR LINKER SCRIPT IS APPROPRIATELY CONFIGURED FOR FLASH HERE. Read that again. If you don't, your processor will again look like so much beach sand as it won't boot appropriately.

Since you are using LPCXpresso, you might dig around their files (I have not done this, but they have to have this stuff somewhere) and see if you can find what files they are using for linker files. I wrote my own as I don't really believe in using these weird tools for embedded development, but I really like knowing exactly where my code is going.

Good luck programming your device.