Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
I still am stuck and no breaky points ! Really? I'm confused. I'm seeing other problems - that are some what related - but I'm not sure (see earlier email subject: Clearing all breakpoints watch points) I see you only setting one breakpoint. I see the breakpoint working. If I look at the log - vrs - the source code - I see the following: Debug: 454 1297182 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 509 1352651 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' Debug: 515 1627149 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 570 1867380 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' Debug: 629 5711327 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 684 5723749 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' 1) All received packets are always printed during debug logs. see: gdb_server.c - line 2050 - 2) All Z (upper case) packets *set* breakpoints 3) All z (lower case) packets *clear* breakpoints The fields are: Z type COMMA address COMMA size See: gdb_breakpoint_watchpoint_add() - line 1375 of gdb_server.c GDB is always using the hardware breakpoint, type 1. Why? Because GDB knows the breakpoint location is in *FLASH* GDB knows this because of the memory map that was sent. ie: gdb_memory_map enable It is always setting/clearing the break point at address 0x196, always a thumb break point (length is 2) I don't see errors in your log - I see them in my log... -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Now I have completely taken Eclipse out of the picture, and am just using openOCD and GDB 6.8. I still am stuck and no breaky points ! I am following a template that was provided, this was helpfull but is not my solution it seems. // Joe, Try adding this to your configuration file # gdb_memory_map enable # This tells openocd to inform GDB where 'flash lives' - thus GDB will attempt to use hardware breakpoints. = Specify the ELF file... = (gdb) file ./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf Reading symbols from /home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas ic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf...done. = Specify the target = (gdb) target remote 192.168.0.100: Remote debugging using 192.168.0.100: 0x in ?? () !! in my case (gdb) target remote localhost: = Tell openocd to HALT the target = (gdb) mon halt = Tell openocd to RESET the target. = (gdb) mon reset JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) JTAG Tap/device matched = And i tell it to halt again... = (gdb) mon halt target state: halted target halted due to debug-request, current mode: Handler BusFault xPSR: 0x2105 pc: 0x000817dc = Load my program - this actually programs the flash = (gdb) load Loading section .fixed, size 0x133c lma 0x8 Loading section .relocate, size 0xf4 lma 0x8133c Start address 0x811dc, load size 5168 Transfer rate: 4 KB/sec, 2584 bytes/write. = Set a breakpoint at main() = (gdb) break main Breakpoint 1 at 0x800c0: file main.c, line 168. = Tell GDB to continue - see the NOTE from GDB... = (gdb) cont Continuing. Note: automatically using hardware breakpoints for read-only addresses. = I hit my breakpoint.. = Breakpoint 1, main () at main.c:168 168 TRACE_CONFIGURE(DBGU_STANDARD, 115200, BOARD_MCK); (gdb) = Works for me :-) = // Does not work for me, yet anyways. Please check out my attachements, incuded is 1) June26AttemptsB1.pdf== Screen shots of exactly what I sent to gdb. 2) openocdLog26B1.txt== Level 3 debug trace, for tracking communications between gdb and openOCD. 3) ConfigFiles_June26Attempt.7z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Looks like my .cfg files were in a 7zip format I will send them individually so they are more visible to more people In some cases I did not use UploadPgmAtZero.cfg when I used (gdb) load instead... Sincerley, Joe On Fri, Jun 26, 2009 at 6:39 PM, Joseph Kuss jmk.engin...@gmail.com wrote: Gmail sent without my promised attachments. Please check them out. Sincerely, Joe 1) June26AttemptsB1.pdf== Screen shots of exactly what I sent to gdb. 2) openocdLog26B1.txt== Level 3 debug trace, for communications between gdb and openOCD. 3) ConfigFiles_June26Attempt.7z == All my openOCD config files for 0.1.0 On Fri, Jun 26, 2009 at 6:32 PM, Joseph Kuss jmk.engin...@gmail.comwrote: Now I have completely taken Eclipse out of the picture, and am just using openOCD and GDB 6.8. I still am stuck and no breaky points ! I am following a template that was provided, this was helpfull but is not my solution it seems. // Joe, Try adding this to your configuration file # gdb_memory_map enable # This tells openocd to inform GDB where 'flash lives' - thus GDB will attempt to use hardware breakpoints. = Specify the ELF file... = (gdb) file ./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf Reading symbols from /home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas ic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf...done. = Specify the target = (gdb) target remote 192.168.0.100: Remote debugging using 192.168.0.100: 0x in ?? () !! in my case (gdb) target remote localhost: = Tell openocd to HALT the target = (gdb) mon halt = Tell openocd to RESET the target. = (gdb) mon reset JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) JTAG Tap/device matched = And i tell it to halt again... = (gdb) mon halt target state: halted target halted due to debug-request, current mode: Handler BusFault xPSR: 0x2105 pc: 0x000817dc = Load my program - this actually programs the flash = (gdb) load Loading section .fixed, size 0x133c lma 0x8 Loading section .relocate, size 0xf4 lma 0x8133c Start address 0x811dc, load size 5168 Transfer rate: 4 KB/sec, 2584 bytes/write. = Set a breakpoint at main() = (gdb) break main Breakpoint 1 at 0x800c0: file main.c, line 168. = Tell GDB to continue - see the NOTE from GDB... = (gdb) cont Continuing. Note: automatically using hardware breakpoints for read-only addresses. = I hit my breakpoint.. = Breakpoint 1, main () at main.c:168 168 TRACE_CONFIGURE(DBGU_STANDARD, 115200, BOARD_MCK); (gdb) = Works for me :-) = // Does not work for me, yet anyways. Please check out my attachements, incuded is 1) June26AttemptsB1.pdf== Screen shots of exactly what I sent to gdb. 2) openocdLog26B1.txt== Level 3 debug trace, for tracking communications between gdb and openOCD. 3) ConfigFiles_June26Attempt.7z Eagle100_jtag_tiny-setup.cfg Description: Binary data DebugPgm.cfg Description: Binary data ErasePgm.cfg Description: Binary data UploadPgmAtZero.cfg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Continued call for help !
It still seems that these are hard to read on the posting, I will just
inline them here
1)
Eagle100_jtag_tiny-setup.cfg===
# From Source file: olimex-jtag-tiny-a.cfg
# REFERENCE: http://www.olimex.com/dev/arm-usb-tiny.html
interface ft2232
ft2232_device_desc Olimex OpenOCD JTAG TINY A
ft2232_layout olimex-jtag
#--
# From Source file: joes_Eagle100BoardTrial1.cfg--
# My test board has a Rev1 tap id.
set BSTAPID 0x16410041
# source [find target/jmk_lm3s6918.cfg] (will just include into this..)
#--
# From Source file: jmk_lm3s6918.cfg (in target directory)
# script for luminary lm3s6918
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME lm3s6918
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
# this defaults to a little endian
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# force an error till we get a good number
set _CPUTAPID 0x3ba00477
}
# jtag speed
jtag_khz 500
jtag_nsrst_delay 100
jtag_ntrst_delay 100
#LM3S6918 Evaluation Board has only srst
reset_config srst_only
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0xf -expected-id
$_CPUTAPID
# THIS WAS IN THE makeController-debug.cfg but is deprecated in
openOCD0.10
#daemon startup reset
#this config option has been removed, simply adding `init' and `reset halt'
to the end
#of your config script will give the same behaviour as using `daemon_startup
reset'
#and `target cortex_m3 little reset_halt 0'.
#
# the luminary variant causes a software reset rather than asserting SRST
# this stops the debug registers from being cleared
# this will be fixed in later revisions of silicon
set _TARGETNAME [format %s.cpu $_CHIPNAME]
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position
$_TARGETNAME -variant lm3s
# 4k working area at base of ram
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x2000
-work-area-size 0x4000 -work-area-backup 0
#flash configuration
flash bank stellaris 0 0 0 0 0
#recommded by Duane Ellis of openOCD
#This tells openocd to inform GDB where 'flash lives' - thus GDB will
attempt to#use hardware breakpoints.
#
gdb_memory_map enable
#
Eagle100_jtag_tiny-setup.cfg===
Then the following of these is sent next to openOCD:
2) DebugPgm.cfg:
telnet_port
gdb_port
init
reset
Or
3) ErasePgm.cfg
#define our ports
telnet_port
gdb_port
tcl_port
echo before init
init
halt
sleep 200
wait_halt
flash probe 0
flash erase_check 0
# This cmd below seems not to work (but it did not really matter):
# Error: failed setting protection for areas 8 to 255 (-901)
#flash protect 0 8 255 off
# But this did work:
flash erase_sector 0 0 255
sleep 200
#
flash erase_check 0
reset run
shutdown
If the chip was already programmed:
openocd -d 3 -f Eagle100_jtag_tiny-setup.cfg -f DebugPgm.cfg -l
openocdLogj26.txt
To see if gdb could directly program a blank chip - this did work.
openocd -d 3 -f Eagle100_jtag_tiny-setup.cfg -f ErasePgm.cfg -l
openocdLogErase.txt
Then I open gdb in a separate dos window.. and got stuck with no
working breakpoints as described.
Joe
On Fri, Jun 26, 2009 at 7:00 PM, Joseph Kuss jmk.engin...@gmail.com wrote:
Looks like my .cfg files were in a 7zip format I will send them
individually so they are more
visible to more people
In some cases I did not use UploadPgmAtZero.cfg when I used (gdb) load
instead...
Sincerley,
Joe
On Fri, Jun 26, 2009 at 6:39 PM, Joseph Kuss jmk.engin...@gmail.comwrote:
Gmail sent without my promised attachments.
Please check them out.
Sincerely,
Joe
1) June26AttemptsB1.pdf== Screen shots of exactly what I sent to
gdb.
2) openocdLog26B1.txt== Level 3 debug trace,
for communications between gdb and openOCD.
3) ConfigFiles_June26Attempt.7z == All my openOCD config files for
0.1.0
On Fri, Jun 26, 2009 at 6:32 PM, Joseph Kuss jmk.engin...@gmail.comwrote:
Now I have completely taken Eclipse out of the picture, and am just using
openOCD and GDB 6.8.
I still am stuck and no breaky points !
I am following a template that was provided, this was helpfull but is not
my solution it seems.
//
Joe,
Try adding this to your configuration file
#
gdb_memory_map enable
#
This tells openocd to inform GDB where 'flash lives' - thus GDB will
attempt to use hardware breakpoints.
=
Specify the ELF file...
=
(gdb) file
./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf
Reading symbols from
/home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Joe, Try adding this to your configuration file # gdb_memory_map enable # This tells openocd to inform GDB where 'flash lives' - thus GDB will attempt to use hardware breakpoints. You are also not paying attention to what GDB is telling you - when it cannot find the bounds of the current function - not much is going to work.. This is very true of the command step - which - is a *source*level* step. Read back through what I told you about how GDB steps ... if the current PC is not within the bounds of your code - GDB has no way to figure out how to STEP - it can - however stepi - which is an instruction step, but *you* the human need to type stepi - not step. === I start GDB - without a configuration file, and type various commands - below is a transcript of what I am typing with embedded comments. I am using an atmel at91sam3u4E chip on a SAM3U-EK eval board, I do not have a Luminary Micro - however both are cortex-M3 parts. === [du...@borgcube basic-internalflash-project]$ ../../../install/bin/arm-none-eabi-gdb GNU gdb (GDB) 6.7.50.20080107-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as --host=i686-pc-linux-gnu --target=arm-none-eabi. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. === I did not specify a CONFIG file on the command-line and I did not specify an ELF file on the command line. therefore I must type commands and specify the ELF file I want to debug. === = Specify the ELF file... = (gdb) file ./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf Reading symbols from /home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas ic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf...done. = Specify the target = (gdb) target remote 192.168.0.100: Remote debugging using 192.168.0.100: 0x in ?? () = Tell openocd to HALT the target = (gdb) mon halt = Tell openocd to RESET the target. = (gdb) mon reset JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) JTAG Tap/device matched = And i tell it to halt again... = (gdb) mon halt target state: halted target halted due to debug-request, current mode: Handler BusFault xPSR: 0x2105 pc: 0x000817dc = Load my program - this actually programs the flash = (gdb) load Loading section .fixed, size 0x133c lma 0x8 Loading section .relocate, size 0xf4 lma 0x8133c Start address 0x811dc, load size 5168 Transfer rate: 4 KB/sec, 2584 bytes/write. = Set a breakpoint at main() = (gdb) break main Breakpoint 1 at 0x800c0: file main.c, line 168. = Tell GDB to continue - see the NOTE from GDB... = (gdb) cont Continuing. Note: automatically using hardware breakpoints for read-only addresses. = I hit my breakpoint.. = Breakpoint 1, main () at main.c:168 168 TRACE_CONFIGURE(DBGU_STANDARD, 115200, BOARD_MCK); (gdb) = Works for me :-) = -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Joseph Kuss wrote: To All, I am using openOCD 0.1.0, GDB 6.8 and Eclipse Ganymede For the Eagle100 board, using LM3S6918: I can download my program into flash ok I can start/continue the program, I just can not get breakpoints to work. Please Help. If I need to send this message in a different format or to a different person or group, please let me know. (a) Try your program in *RAM*, see if breakpoints work there, this rules out RAM vrs FLASH breakpoint problems. (b) Where are the breakpoints being placed? Flash or RAM? (c) GDB often tries to keep track of your earlier breakpoints - how many do you have active? With Insight (GDB-TK) one often must cleanup and delete the cached list of break points when code changes, otherwise they get put in rather strange places. (d) Enable the debug log level 3 - what does the log tell you when you set a break point and run (read the openocd manual about this) (e) Where did you get OpenOCD from? Did you build it, or did you download a pre-built version? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
