Flashing a LPC1768 with OpenOCD and ARM-USB-TINY-H

[pacman]

I've been working on it ever since you helped me getting my ARM-USB-TINY-H up and running with my SAM7-P256 board.

-Now it seems I'll need to move to a faster chip, so I dug out one I had on stock and soldered it onto an adapter board.
The adapter board has been placed on a breadboard with a 3.3V power supply. I've added a JTAG connector and a single LED.

After spending some time with it, I found out that two pins were not soldered properly.
I went over all the pins and checked for connections and short circuits; now there should be no errors of those kind.

I've successfully communicated with the 'board' using OpenOCD.

Code Select Expand

openocd -c "telnet_port 4444" -f interface/olimex-arm-usb-tiny-h.cfg -f target/lpc1768.cfg

From a new terminal window:

Code Select Expand

$ telnet localhost 4444
> adapter_khz 500
adapter speed: 500 kHz
> reset halt
JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
> flash banks
#0 : lpc1768.flash (lpc2000) at 0x00000000, size 0x00080000, buswidth 0, chipwidth 0
> dump_image old_image.bin 0x0 0x80000
dumped 524288 bytes in 18.999392s (26.948 KiB/s)
> poll
background polling: on
TAP: lpc1768.cpu (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc


Let's see what's in the flash memory:

Code Select Expand


$ hexdump -C old_image.bin
00000000  fc 1f 00 10 81 00 ff 1f  00 00 00 00 00 00 00 00  |?.....?.........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  df f8 18 40 df f8 10 50  26 68 05 ea 06 06 26 60  |??.@??.P&h.?..&`|
00000090  df f8 00 f0 01 02 ff 1f  ff bf ff ff c0 c3 0f 40  |??.?..?.??????.@|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
00080000

Looks good to me; so far, so good, no problems.

Now I'd like to flash my own image onto the chip...

Code Select Expand

> flash write_image erase LED-Blinker.bin 0x0 bin
auto erase enabled
lpc1768.cpu -- clearing lockup after double fault
lpc2000 prepare sectors returned 50331840
failed erasing sectors 0 to 0
in procedure 'flash'


Notice the line...
lpc1768.cpu -- clearing lockup after double fault

What am I doing wrong ?
I know my adapter is fully working, because it works flawlessly with the SAM7-P256 board.
OpenOCD seem to be able to communicate with the chip just fine.
I can read the contents of the LPC1768 flash memory completely.
I should not have to set the reset_config, because the JTAG is fully connected, including the ~RESET pin (with a 10K pull-up and a 100nF capacitor).

I have 10K pull-ups on JTAG pins 3,5,7,13 and 15
I have 10K pull-downs on JTAG pins 9,17,19

I have a 10K pull-up on pin 53 of the LPC1768, and a 100nF capacitor on each VCC pin.
Voltage is measuring 3.3076V.

I have tried what's suggested here with no luck. Here's a slightly modernized version:

Code Select Expand

$ cat bare_1768.cfg

adapter_khz 1

source [find interface/olimex-arm-usb-tiny-h.cfg]

source [find target/lpc1768.cfg]

adapter_nsrst_assert_width 10
adapter_nsrst_delay 2
reset_config srst_only

adapter_khz 500

init
sleep 200
reset halt
wait_halt
mww 0x400FC040 0x01
sleep 200

flash write_image LED-Blinker.bin
verify_image LED-Blinker.bin

reset run

...And these are my results, when trying to flash:

Code Select Expand



$ openocd -f bare_1768.cfg
Open On-Chip Debugger 0.6.1 (2012-11-30-00:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1 kHz
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 10 kHz
cortex_m3 reset_config vectreset
adapter_nsrst_assert_width: 10
adapter_nsrst_delay: 2
srst_only separate srst_gates_jtag srst_open_drain
adapter speed: 500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1768.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
Warn : Verification will fail since checksum in image (0x00000000) to be written to flash is different from calculated vector checksum (0xefff78c8).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
Error: lpc1768.cpu -- clearing lockup after double fault
Warn : lpc2000 prepare sectors returned 50331840
Error: error writing to flash at address 0x00000000 at offset 0x00000000
Runtime Error: bare_1768.cfg:21:
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'flash' called at file "bare_1768.cfg", line 21

Notice the error from above:
Error: lpc1768.cpu -- clearing lockup after double fault
I'm a bit stuck now. What did I miss out ?

[maria_olimex]

Have you tried

flash write_image erase unlock (...)

Also for some reason it says
lpc2000 prepare (...)

Also, OpenOCD had problems with lpc2000 drivers in version 0.6.0 - they fixed them in 0.6.1, but you can still take a look at the blog post:
http://openocd.sourceforge.net/2012/10/openocd-0-6-1-bugfix-release/

Take a look at the scripts/board/ dir, there are .cfg files for several lpc1768 boards, you could see which one is closest to your setup and see if there is something missing from your .cfg files.


Best regards,
Maria/OLIMEX

[pacman]

Have you tried

flash write_image erase unlock (...)

Definitely.
-I also tried with just erase and just unlock.

Also for some reason it says
lpc2000 prepare (...)

I noticed that, and after searching on the Web, I figured that it'll say that with almost any LPC chip, so that should probably be fine (unless you know otherwise, of course).

Also, OpenOCD had problems with lpc2000 drivers in version 0.6.0 - they fixed them in 0.6.1, but you can still take a look at the blog post:
http://openocd.sourceforge.net/2012/10/openocd-0-6-1-bugfix-release/

Hmm, interesting. Freddy Chopin (quite cool guy) seem to have a LPC1769, which he has working.
I could ask him to try making a flash-test, to see if something is broken.

Take a look at the scripts/board/ dir, there are .cfg files for several lpc1768 boards, you could see which one is closest to your setup and see if there is something missing from your .cfg files.

Yes, there are quite a few. grep '1768' * gives me 6 results.
I found keil's mcb1700, which is just a 'source [find target/lpc1768.cfg]' - I don't think I can get any closer, as my 'board' is more or less just the chip itself.

Unfortunately, it didn't bring me much closer to a solution. I wonder if my chip is damaged. Of course, it could be a problem somewhere in OpenOCD.

Today I also tried rebuilding my OpenOCD with usblib 1.0 (and I failed). I had to build it again using libusb 0.1; still the same result, although I tried changing the configure options.

[maria_olimex]

In my experince, the LPC + OpenOCD combination has its quirks and is not always by the book.

Those are the commands I've used to flash the L2294:

target remote localhost:3333
jtag arp_init-reset
arm7_9 fast_memory_access disable
halt
wait_halt
flash write_image erase unlock main.bin 0
sleep 100
jtag arp_init

Note that I'm using jtag arp_init-reset rather that reset halt; You can read on it in the OpenOCD manual.

Also, you may want to take a look at this thread:
https://www.olimex.com/forum/index.php?topic=164.0

Best Regards,
Maria/OLIMEX

[pacman]

In my experince, the LPC + OpenOCD combination has its quirks and is not always by the book.

I experienced that as well.

Those are the commands I've used to flash the L2294:

target remote localhost:3333
jtag arp_init-reset
arm7_9 fast_memory_access disable
halt
wait_halt
flash write_image erase unlock main.bin 0
sleep 100
jtag arp_init

Note that I'm using jtag arp_init-reset rather that reset halt; You can read on it in the OpenOCD manual.

The reset works, but it says 'invalid command name "arm7_9"'; and still report that double-fault.

Also, you may want to take a look at this thread:
https://www.olimex.com/forum/index.php?topic=164.0

I've been there prior to starting this thread.

I've tried asking on Sparkfun, what could cause this double-fault error message. Hopefully one of the OpenOCD developers will have a clue on what's going on.
To me, it looks like there might be something wrong with the chip, as I've tested all pins, and am very sure the connections are alright.
-And since OpenOCD works fine with my other board, I believe that at least one of the flash commands would have succeeded.

[pacman]

I bought a new adapter and LPC1768, made an exact duplicate (and this time hand-soldered the chip onto the adapter board using a Weller soldering iron).

New chip works with the exact same setup. Old chip was most likely fried.
-So if anyone gets the above error when flashing, it may be because the chip no longer works.
This may apply to some chips other than LPCxxxx as well.