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 0x20000000 -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 4444 gdb_port 3333 init reset Or 3) ErasePgm.cfg #define our ports telnet_port 4444 gdb_port 3333 tcl_port 6666 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.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.com>wrote: >> >>> 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:3333 >>> Remote debugging using 192.168.0.100:3333 >>> 0x00000000 in ?? () >>> !!!!!!!!!! in my case !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >>> (gdb) target remote localhost:3333 >>> ===== >>> 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: 0x21000005 pc: 0x000817dc >>> ===== >>> Load my program - this actually programs the flash >>> ===== >>> (gdb) load >>> Loading section .fixed, size 0x133c lma 0x80000 >>> 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
