Unreliable flashing of LPC1769 using olimex-arm-usb-tiny-h

Development Boards MicroMod
1

I’m trying to create a configuration file for flashing an LPC1769 using the Olimex USB tiny-h adaptor, but so far I’m only able to make it work some of the time and absolutely only the first time after plugging the adaptor into USB, the second time I try to flash without re-plugging it will fail.

My configuration looks like this:

jtag_khz 1

# This is the JTAG connector I use
source [find interface/olimex-arm-usb-tiny-h.cfg]

# This is close enough to the board I use
source [find target/lpc1768.cfg]

adapter_khz 500

init
sleep 200
soft_reset_halt
wait_halt
mww 0x400FC040 0x01
sleep 200

flash write_image erase main.bin
verify_image main.bin
reset run

When it works it looks liket this:

> openocd -f openocd-flash.cfg
Open On-Chip Debugger 0.5.0 (2011-08-26-10:36)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
1 kHz
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
10 kHz
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
requesting target halt and executing a soft reset
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
auto erase enabled
wrote 98304 bytes from file main.bin in 10.767429s (8.916 KiB/s)
verified 69748 bytes in 0.559875s (121.658 KiB/s)
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Warn : Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals

When it fails it looks like this:

openocd -f openocd-flash.cfg
Open On-Chip Debugger 0.5.0 (2011-08-26-10:36)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
1 kHz
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
10 kHz
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
requesting target halt and executing a soft reset
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x01000000 pc: 0x000005f8 msp: 0x10008000
auto erase enabled
wrote 98304 bytes from file main.bin in 10.403347s (9.228 KiB/s)
Error: checksum mismatch - attempting binary compare
diff 0 address 0x00000000. Was 0xff instead of 0x00
diff 1 address 0x00000001. Was 0xff instead of 0x80
diff 2 address 0x00000002. Was 0xff instead of 0x00
diff 3 address 0x00000003. Was 0xff instead of 0x10
diff 4 address 0x00000004. Was 0xff instead of 0xf9
diff 5 address 0x00000005. Was 0xff instead of 0x05
diff 6 address 0x00000006. Was 0xff instead of 0x00
diff 7 address 0x00000007. Was 0xff instead of 0x00
diff 8 address 0x00000008. Was 0xff instead of 0x01
diff 9 address 0x00000009. Was 0xff instead of 0x06
diff 10 address 0x0000000a. Was 0xff instead of 0x00
diff 11 address 0x0000000b. Was 0xff instead of 0x00
diff 12 address 0x0000000c. Was 0xff instead of 0x03
diff 13 address 0x0000000d. Was 0xff instead of 0x06
diff 14 address 0x0000000e. Was 0xff instead of 0x00
diff 15 address 0x0000000f. Was 0xff instead of 0x00
diff 16 address 0x00000010. Was 0xff instead of 0x05
diff 17 address 0x00000011. Was 0xff instead of 0x06
diff 18 address 0x00000012. Was 0xff instead of 0x00
diff 19 address 0x00000013. Was 0xff instead of 0x00
diff 20 address 0x00000014. Was 0xff instead of 0x07
diff 21 address 0x00000015. Was 0xff instead of 0x06
diff 22 address 0x00000016. Was 0xff instead of 0x00
diff 23 address 0x00000017. Was 0xff instead of 0x00
diff 24 address 0x00000018. Was 0xff instead of 0x09
diff 25 address 0x00000019. Was 0xff instead of 0x06
diff 26 address 0x0000001a. Was 0xff instead of 0x00
...

As you can see nothing was programmed in the second round, but the flash was erased ok.

The clock and jtag connections to the controller is set up exactly like the LPCxpresso LPC1769 board (32768 kHz RTC xtal and 12 MHz main xtal) and I’m able to reproduce the problem with that board as well, so I’m pretty sure there is some problem with either my openocd configuration or my adaptor.

I’m using OpenOCD 0.5.0 from the Ubuntu repo.

Another strange datapoint: When I press my reset button on my own target board it only comes up correctly about one time out of ten and the same is true when doing a “reset run” via jtag.

The full schematic of my project is online here, the only strange thing I can think of is that I’ve left ~TRST unconnected:

https://github.com/openspaceaarhus/Phot … f?raw=true

If anyone has OpenOCD working with LPC17xx and/or olimex-arm-usb-tiny-h, then please post your configurations here.

Any ideas as to what is going on with the strange reset problem?

2

I’ve ignored the JTAG problem for a bit to concentrate on the reset problem I noticed that “reset run” would cause the lockup, so that meant that jtag was still working during the lockup, so I started poking around via jtag and found that:

> halt
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x41000003 pc: 0x00000602 msp: 0x10007eb8

# Read hard Fault Status Register:

> mdw 0xe000ed2c
0xe000ed2c: 40000000 

# Bit 30 is: Forced, so read the other fault status registers:

> mdw 0xe000ed28
0xe000ed28: 00000400 

# This means imprecise data bus error, with no address of the fault.

Notice that this problem never happened on my LPCexpresso reference board using the exact same firmware.

At this point I’ve been going insane for several hours trying to track down this bug, so I yanked the chip and put in a fresh one, since then I have not seen the problem, so I’m inclined to think I semi-broke the MCU some how, which makes this a first for me.

Anyway, I still have the problem re-initializing the JTAG so it will work without re-plugging it all the time.

3

I found the solution to my problem and rather than keep it secret as tradition seems to dictate around here, I’m posting to let others know how to solve the problem.

It seems openocd defaults to resetting only the CPU core using jtag commands, that leaves all the peripherals alone and causes flash to fail the second time around.

The solution is to instruct openocd to reset using the system reset, this is done by adding the commands:

adapter_nsrst_assert_width 10
adapter_nsrst_delay 2
reset_config srst_only

… to the configuration file, the first two have to do with the timing of the reset signal, here I have it pull reset low for 10 ms and wait 2 ms after releasing it before taking control of the CPU.

The third line tells openocd to use the reset signal, this should always be done IMHO, unless the signal isn’t available.

This is my full configuration file:

# This file is for use with the PhotonSaw LPC1769 based laserctrl board.
# The script will flash the main.bin file to the board and run it.
# To flash the board call with:
#  $ openocd -f openocd-flash.cfg

jtag_khz 1

# This is the JTAG connector I use
source [find interface/olimex-arm-usb-tiny-h.cfg]

# This is close enough to the board I use
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 erase main.bin
verify_image main.bin

reset run
4

You, my good sir, are my hero!

I bought an lpc1768 board with a openocd replica in november 2011.

Since then I had the same issue as you, an was unable to find a solution for this problem!

I still was able to program, since this board has an ISP port…

But… today I decided to search a second time and finaly found a post like yours and was able to solve this kinda crappy issue.

Thank you so much !!! :smiley: :smiley: :smiley: :smiley: :smiley:

PS: I just registered only to thank you !

5

Thank you so much for this ! :smiley: :smiley: :smiley:

I bought an openocd replica in november 2011. And since then I had only isp programming as I had the same issue as you !

Sometimes I tried to solve it by googling. Yesterday I finally found a post like you.

And its working like a charm…

How did you get these infos for solving ?

How high can you set the clock ?

Edit: I first wondered, that the post didn’t showed up. This is the reason for my double post…

6

Seriously, thanks! I was stuck with the JTAG flash failing every other time with:

Error: lpc1768.cpu -- clearing lockup after double fault

and using those lines in the OpenOCD config fixed it. It also increased the flashing speed tremendously, from like 0.3KB/s to 4+.

I’m also curious how you discovered this, because I really am having a hard time finding any definitive references about how to use these tools. The OpenOCD docs are well written, but seem to leave a lot of important information out.

It looks like I’m able to increase the adapter_khz up to 1200KHz with the Olimex ARM-USB-OCD (not the tiny version). The only documentation from Olimex I can find is this: https://www.olimex.com/dev/soft/arm/JTA … RAMMER.pdf where in the screenshot, you can see them using 1200Khz. Is this the actual max? Who knows. I can’t get it to work any faster.

7

peplin:
It looks like I’m able to increase the adapter_khz up to 1200KHz with the Olimex ARM-USB-OCD (not the tiny version). The only documentation from Olimex I can find is this: https://www.olimex.com/dev/soft/arm/JTA … RAMMER.pdf where in the screenshot, you can see them using 1200Khz. Is this the actual max? Who knows. I can’t get it to work any faster.

The max JTAG clock for ARM-USB-OCD would be 6MHz, and for ARM-USB-OCD-H 30MHz.

However it is unlikely your target would cope with these speeds.

Cheers

Spen

8

dren.dk:
It seems openocd defaults to resetting only the CPU core using jtag commands, that leaves all the peripherals alone and causes flash to fail the second time around.

Depends on the target and arch.

Normally this would not matter, other cortex-m3 based targets (stm32, luminary) use SYSRESETREQ to perform a software reset - this will also reset the peripherals. However the LPC17x does not support this, and so needs a hardware (SRST) to achieve the same result.

OpenOCD does issue a warning when SYSRESETREQ is not supported:

“Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals”

For info newer LPC devices are due to support SYSRESETREQ.

As you have suggested the best solution is to just use SRST to reset the target.

Cheers

Spen