Forums

OpenOCD+GDB (stepi. Unable to single step)

Started by dwx November 16, 2009
Hello,
I've a small "problem". I first describe the situation:::

I have a AT91 microcontroller connected with the host by a amontec JTAG...
I start OpenOCD and everithing run OK.
In the gdb script (to connect to openocd) i set a hardware breakpoint (with
hbreak main), and a continue command...

-------------------------------------------------------------
>THIS IS THE OPENOCD SCRIPT:
#daemon configuration telnet_port 4444 gdb_port 3333 # tell gdb our flash memory map # and enable flash programming gdb_memory_map enable gdb_flash_program enable #interface interface ft2232 ft2232_device_desc "Amontec JTAGkey A" ft2232_layout jtagkey ft2232_vid_pid 0x0403 0xcff8 jtag_speed 0 jtag_nsrst_delay 200 jtag_ntrst_delay 200 reset_config srst_only srst_pulls_trst if { [info exists CHIPNAME] } { set _CHIPNAME $CHIPNAME } else { set _CHIPNAME sam7s256 } if { [info exists ENDIAN] } { set _ENDIAN $ENDIAN } else { set _ENDIAN little } if { [info exists CPUTAPID ] } { set _CPUTAPID $CPUTAPID } else { set _CPUTAPID 0x3f0f0f0f } jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID set _TARGETNAME [format "%s.cpu" $_CHIPNAME] #target configuration target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x4000 -work-area-backup 0 #flash bank <driver> <base> <size> <chip_width> <bus_width> flash bank at91sam7 0 0 0 0 0 init reset -------------------------------------------------------------
>THIS IS THE GDB SCRIPT:
target remote localhost:3333 monitor soft_reset_halt monitor armv4_5 core_state arm monitor mww 0xFFFFFF60 0x00320100 monitor mww 0xFFFFFD44 0x00008000 monitor mww 0xFFFFFC20 0x00000601 monitor sleep 100 monitor mww 0xfffffc2c 0x0048100e monitor sleep 200 monitor mww 0xfffffc30 0x7 monitor sleep 100 monitor mww 0xfffffd08 0xa5000401 set remote memory-write-packet-size 1024 set remote memory-write-packet-size fixed set remote memory-read-packet-size 1024 set remote memory-read-packet-size fixed symbol-file /home/dwx/dev/arm/DWX-0.1/bin/dwx.elf hbreak main continue ---------------------------------------------------------- Everithing works fine one time yes and one time NOT. In the sense: The first time i start gdb with the script over and it stop @ main correctly. If i stop immediatly gdb leaving the Program counter @ main (without stepping or continue) and i restart gdb it say:
> SIGINT, UNABLE TO STEPI, GDB WILL NOW FETCH INTRUCTIONS FROM TARGET <
And the PC is @ 0x0 If I stop GDB again and a rerun it i get the first situation described... What is the problem??? I think that is a gdb bug that if i stop gdb immediatly after he reached the breakpoint and i restart it with the same breakpoint he crash... Any suggestion? --------------------------------------- This message was sent using the comp.arch.embedded web interface on http://www.EmbeddedRelated.com
On Mon, 16 Nov 2009 07:01:05 -0600, dwx wrote:

> Hello, > I've a small "problem". I first describe the situation::: > > I have a AT91 microcontroller connected with the host by a amontec > JTAG... I start OpenOCD and everithing run OK. In the gdb script (to > connect to openocd) i set a hardware breakpoint (with hbreak main), and > a continue command... > > <snip> >
Hi Davide, This looks to be an issue with the AT91 GDB implementation over Remote Serial Protocol. Possibly the Remote Serial Protocol server held some state and sent spurious responses to the restarted GDB, confusing the client. I'm not familiar with the AT91 implementation. You would be better asking this question on one of the GDB mailing lists (http://sourceware.org/gdb/ mailing-lists/). In the meantime, some of the Embecosm application notes on porting GDB and the Remote Serial Protocol may give you an understanding of why you are seeing this behavior. http://www.embecosm.com/download/application_notes.html HTH Jeremy