Hi all,
I’ve got a working openocd-eclipse setup for my lpc3131 dev system, but just trying to make it more streamlined. I’m running windows 7 x64, cygwin was used to compile openocd but it’s compiled without dependencies (it’s also a x32 binary). I’m using proprietary ftdi driver and a fairly generic dongle (the TI ICDI). My gdb is from codesourcery lite, but I tried yagarto with same results.
I’ve previously used the normal “External Tools” method of launching openocd before starting a debug but with the addition of openocd pipe setting in GDB Hardware Debugging in Eclipse Helios I’d really like to use this to cut out the extra step.
To avoid having to add openocd to my PATH (I want a portable installation) I found the working directory for the “| openocd” command box (in Debug Configurations) is the eclipse directory. So I put my copy of openocd folder in the eclipse directory. Then I can use arm-none-eabi-gdb.exe as my debugger, and “| openocd\openocd0.4_ftdi.exe -s openocd\ -f lpc3131_ft2232.cfg --pipe” as my OpenOCD (via pipe) command. This way I can copy the eclipse installation and workspace to different computers (with different filesystem structures) and not have to change any of the debug settings.
My other normal settings for debug are:
Reset And Delay (ticked) [ 0 ]
Halt (ticked)
[custom commands blank]
Load Image - Use project binary
offset: [ 11029000 ]
Load Symbols - Use project binary
offset: [ 11029000 ]
Set Program Counter [ 11029000 ]
Set Breakpoint [ c_entry ]
Resume (ticked)
This is a ram only part, so this is just loading the app into ram, not flashing anything at all.
This setup does works when debug mode is set to GDB (DSF) Hardware Debugging Launcher. When set to Standard GDB Hardware Debugging Launcher however it seems to get stuck at set $pc=0x11029000. I’ve found that if I set the pc in openocd reset-init script instead and not try to set it from gdb it’ll usually load in standard mode.
Regardless of mode however, my problem is it’s very slow. As in single stepping usually takes ~2 seconds. This is compared to seeming instantaneous single steps in generic tcpip port mode (with same openocd binary and config files). It’s a very noticeable lag when doing a lot of debugging.
Does anyone know why the pipe communication would work but be so slow? And more importantly if there’s any way to get better speed out of it? I realise pipes aren’t as well build into windows as they are in *nix, but I don’t see why there should be such a speed constraint on an otherwise operational communication method.
Cheers,
Andrew