GDB load of lpc2103 versus arm-elf-insight load

Development Boards MicroMod
1

I’m trying to load (flash) my lpc2103 using the slick and cool gdb interface. It works awesomely through insight. I invoke arm-elf-insight (arm-elf-insight main.elf) and hit “run” and it somehow knows to load automatically, which it does, giving the output below:

software breakpoints enabled
Loading section .text, size 0x2e5c lma 0x0
Loading section .data, size 0x4 lma 0x2e5c
Start address 0x0, load size 11872
Transfer rate: 37027 bits/sec, 5936 bytes/write.

Doing what I believe to be the same thing from gdb directly causes a data abort that I can’t explain:

bash-3.1$ arm-elf-gdb build/main.elf
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
service_uart () at ./src/main.c:138
138     }
(gdb) monitor halt
(gdb) load
Loading section .text, size 0x2e5c lma 0x0
Memory access error while loading section .text.
(gdb)

What gives? Is insight doing something under the covers that I don’t understand? Here’s the output of openocd, in case that’s helpful:

Warning:memory write caused data abort (address: 0x00000000, size: 0x4, count: 0x51)
Warning:memory write caused data abort (address: 0x00000000, size: 0x4, count: 0x51)

I can of course provide the openocd file, or even source code if that helps. I can’t help but feel though that this is a n00b mistake, and I’m just forgetting to do something obvious here.

(For extra context, this is leading up to me moving to DDD instead of arm-elf-insight as my debugger, so if anyone has additional information on that, that would be great!)

Cheers!

-R

2

I’m going to go ahead and paste my openocd config file here, since my reading suggests that it might be my problem:

#daemon configuration
telnet_port 4444
gdb_port 3333
tcl_port 6666

#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG TINY"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0004
jtag_speed 3
gdb_memory_map enable
gdb_flash_program enable
target_script 0 gdb_program_config lpc2xxx_preflash.script

#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 reset
#daemon_startup attach

#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little 0 arm7tdmi-s_r4
#run_and_halt_time 0 30

working_area 0 0x40000000 0x4000 nobackup
#working_area 0 0x00000000 0x4000 nobackup


# Cut this line if you want to be able to use software breakpoints (if you're debugging from RAM)
#arm7_9 sw_bkpts enable

#flash configuration
#flash bank lpc2000 <base> <size> 0 0 <target#> <variant>
flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 14765 calc_checksum

# For more information about the configuration files, take a look at:
# http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger

And here’s my preflash script, which I’m not sure is necessary:

halt
wait_halt
sleep 10

I’ve read that you have to communicate the memory map to GDB somehow so it knows which areas of memory to flash, and which to load like RAM. I thought the way to do this was to just use the gdb_memory_map enable command in the config file, but enacting it doesn’t change anything in my configuration.

3

hi,

ryansturmer, i am also getting the same error …

DCC write failed, expected end address 0x020003e0 got 0x20002b4

unexpected error -4

DCC write failed, expected end address 0x020003e0 got 0x20002b4

unexpected error -4

hav u got the solution ? can u help me here ?

Thanks n advance

4

Hi,

I haven’t used gdb directly but [here is the link to the OpenOcd config files that were sucessfully used to program lpc2103. I’ll try to set up dgb as well and report on how that goes.

Dean](http://www.omnima.co.uk/forums/index.php?s=236ebb6fa450d2c9818cfecd4c4d98c8&showtopic=50)

5

thanks for the post…

actually i hav setup the config file correctly for s3c2410 and started the openocd successfully. but the thing is i need to flash the NAND with the firmware so that i can boot the target.

it aint happening … :slight_smile:

i have even added the RAM initialization values in the cfg file …

yet to find a break thru …

i shall post the config files when i have finished it completely …

6

hi,

openocd now works fine for me with s3c2410 :D. i used wiggler (http://www.macraigor.com/wiggler.htm) for debugging the s3c2410 soc.

now i can use gdb to load programs ther.

if u need the config files just place a post here i shall give the config file.

7

kasi:
hi,

openocd now works fine for me with s3c2410 :D. i used wiggler (http://www.macraigor.com/wiggler.htm) for debugging the s3c2410 soc.

now i can use gdb to load programs ther.

if u need the config files just place a post here i shall give the config file.

hi,

I think I need that file… I am trying to debug u-boot on my s3c2410 board but I always get everything work well, there are always some errors here and there.

8

Hello ,

i have a different qeusetion .

i am using a combination of imx6q-based kit and using a USB-Wiggler from Macraigor systems : http://www.macraigor.com/usbWiggler.htm

Q: is there a support/configuration script for usb wiggler . and how i can make sure of support/nonsupport of this JTAG adapter

thanks and best regards,