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

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