Has anyone been able to debug a LPC23xx device from Flash?
RAM debugging seems to work fine…but I can’t get it working from flash.
(using OpenOCD 1.31 and Olimex ARM-USB-OCD on a Keil MCB2300)
Frank
Ok…some code to clearify the problem…
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_layout olimex-jtag
ft2232_vid_pid 0x15BA 0x0003
jtag_speed 12
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#target configuration
daemon_startup attach
#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little reset_run 0 arm7tdmi-s_r4
working_area 0 0x40000000 0x40000 nobackup
#flash configuration
flash bank lpc2000 0x0 0x7d000 0 0 lpc2000_v2 0 12000 calc_checksum
target remote localhost:3333
monitor arm7_9 dcc_downloads enable
monitor wait_halt
monitor sleep 500
monitor poll
monitor flash probe 0
monitor flash erase 0 0 10
monitor flash write 0 main.bin 0x0
monitor reset
monitor sleep 500
monitor poll
monitor soft_reset_halt
monitor arm7_9 force_hw_bkpts enable
thbreak main
symbol-file main.out
continue
Tried programming/debugging a tiny prog which runs fine from RAM…
Loader get stuck (10%) while trying to program Flash.
any suggestions?
Frank
Frank,
I haven’t had any luck in flashing my LPC2366 by using OpenOCD.
It seems to be writing to Flash incorrectly. Dump memory at location 0x0 (flash) and then do the same at 0x40000000 (ram). You’ll see that the data is different.
I’ve tried OpenOCD with both my Mac OS X version as well as Windows XP with no luck.
Using the lpc21isp utility to program the chip, I can use OpenOCD to debug my code from flash.
luis…
I am using revision 208 and can flash an lpc2368.
I do have a weird situation though where it seems I have to flash it twice with a reset in between to make it work. I do not know why.
I have tried flashing both an elf image and a binary file and neither work. It seems that after flashing and doing a reset run it looks like the chip is going back into the bootloader. If I flash it again it then runs the code.
Ben
ben_h:
I am using revision 208 and can flash an lpc2368.
Hmmm! Let me go back and try flashing again. But you also mention doing a reset in the middle…'k. I haven’t tried that.
Have you by chance looked at memory region 0x0 (for, say, 64words) and comparing that with a successful flash? Do they look the same?
luis…
The first 64 byte can be different depending on the memory mapping - if you have the exception vectors mapped to internal SRAM you won’t see the flash content at that location.
There are always some open issues with big endian hosts and targets, and i’ve just fixed another problem in my local tree (changes pending some testing) that causes problems with half-word writes, but basically this should work. It’s mostly a matter of finding time to test and fix the remaining issues, nothing fundamental.
Regards,
Dominic
For this, I'm comparing what is written by JTag vs lpc21isp, so I expect the contents of that location to be the same whether I use the JTag or lpc21isp.Dominic:
The first 64 byte can be different depending on the memory mapping
I haven’t tried the flash method Ben has described, maybe there’s something funky happening on the chip…?
Actually, in this case, I've been using a little-endian target and am using little-endian hosts (Intel Macbook Pro or AMD XP machine)Dominic:
There are always some open issues with big endian hosts and targets…
I’m still interested in the big-endian target solution though 
cheers!
luis…
my first thought was that the checksum was the problem.
however it is the same after the first program / reset as the second time.
I would like to get to the bottom of the problem. I think, although I will have to check to make sure, just programing the chip twice, without a reset run in between does not work either.
Ben
This is what I’m using on the latest YAGARTO+OpenOCD+LPC-2378-STK+ARM-USB-OCD and I’m able to debug from flash:
For ‘Initialize’ Commands
show remotetimeout
set remotetimeout 180
target remote localhost:3333
monitor reset run_and_halt
monitor sleep 500
monitor wait_halt
monitor poll
monitor flash probe 0
monitor flash erase 0 0 26
monitor reset run_and_halt
monitor sleep 500
monitor wait_halt
monitor poll
monitor flash write 0 main.bin 0x0
monitor soft_reset_halt
monitor arm7_9 force_hw_bkpts enable
set language c
symbol-file main.elf
break main
set remotetimeout 10
For ‘Run’ commands
continue
For large code, it seems necessary to extend the gdb timeout
sorry…i had deleted this comment as I started to see inconsistent results with my testing. I’ve slightly updated comments below.
hmm...some comments:dmi:
This is what I’m using on the latest YAGARTO+OpenOCD+LPC-2378-STK+ARM-USB-OCD and I’m able to debug from flash:[----8-<—snip]
-
I’ve been using the apparently the Depreciated Command flash write (i haven’t check up on the command changes for a while, I’ve been using svn for quite sometime :oops:)
-
ontop of that, I’ve been trying to write my .hex image instead of the .bin. I used the .bin file instead and magical things occurred: it worked!
-
I went back and tried to write my .hex image using the flash write_image image.hex 0: OpenOCD barked at me:
flash write error: failed buffering IHEX image, check daaemon output for additional information
finally, with my curiosity really piqued, I tried an **.elf** file: that worked fine.OpenOCD Daemon:
Debug: image.c:92 autodetect_image_type(): IHEX image detected.Error: image.c:302 image_ihex_buffer_complete(): unhandled IHEX record type: 2
Error: image.c:700 image_open(): failed buffering IHEX image, check daemon output for additional information
so! it is possible to write to the LPC2366 (for me at least) and here the telnet commands I used for testing the above.
telnet localhost 4444
poll
reset run_and_halt
flash probe 0
flash erase 0 0 14
flash write_image image.elf
soft_reset_halt
resume
You’ll notice that I did not reset in between the flash erase and flash write_image.
here’s my openocd.cfg:
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface ft2232
ft2232_device_desc "Amontec JTAGkey A"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
jtag_speed 10
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#target configuration
daemon_startup attach
#daemon_startup reset
#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little run_and_init 0 arm7tdmi-s_r4
run_and_halt_time 0 30
working_area 0 0x40000000 0x40000 nobackup
#flash configuration
#flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 4000 calc_checksum
flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 12000 calc_checksum
Okay. Learned one thing: The CPU MUST be in Supervisor mode before performing the Flash Write. Otherwise, the image will not work.
below is a shell script which I use within Eclipse to update my board.
The arguments to pass to the script is your image name.
sh ./upload image.elf
In the code you’ll see that I have commented out lines which perform a scp to another host. I’m currently running Leopard on my Mac, and unfortunately at this time, the FTDI D2xx library does not work and so OpenOCD does not work either. The folks at FTDI Inc are working on a fix. As such, I scp my images over to my XP box where OpenOCD and JTAGKey is located.
#!/bin/sh
#
#
#
host=localhost
port=4444
#scp $1 Luis@${host}:.
#echo scp $1 Luis@${host}:. RC=$?
expect <<EOF
spawn telnet ${host} ${port}
expect ">"
send "reset run_and_halt\r"
expect ">"
while {1} {
send "sleep 1000\r"
expect ">"
send "poll\r"
expect "*current mode: Supervisor" { break; }
send "reset\r"
expect ">"
}
send "flash probe 0\r"
expect ">"
send "flash erase 0 0 14\r"
expect ">"
send "flash write_image $1\r"
expect ">"
send "soft_reset_halt\r"
expect ">"
send "resume\r"
expect ">"
send "exit\r"
expect eof
EOF
actually, when I said the processor must be in Supervisor mode, the CPSR Flag status should be 0x2: eg:
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x0000027c
For some reason, if the CPSR register does not contain those values, writing to flash creates a “bad” image.
Can anyone out there explain to me why this would be so?
Thanks!
luis…