In the early years of OpenOCD, getting a setup to work was akin to magic. This was back, say, 10 years ago. Give or take...
I haven't tried since and probably never will again. But, yes, it's my fault... There were simply too many parameters and far too many combinations...
...
If I ever get to a point where I can't get my code to run and I am truly desperate, I might try again.
All you need to do (assuming you have OpenOCD and gdb installed):
1) Create a file called openocd.cfg to save you typing parameters (this is using the ST32F042 Nucleo board with built-in STLink):
---- cut ---
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f0x.cfg]
---- cut ---
The interfaces and targets you can find either in the documentation or just look in the folder where OpenOCD was installed - there are interface and target subdirectories containing files for both the interfaces (dongles) and targets. If you want JTAG transport, just put jtag instead of hla_swd. OpenOCD ships with these files for many common devboards, including the Nucleos and Discoveries, so just look there and adapt one if you don't find a matching one.
2) Run openocd in this folder (I am on linux, adapt to your OS as needed):
$ openocd
Open On-Chip Debugger 0.9.0 (2015-05-26-21:40)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.htmlInfo : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.238497
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
3) And that's all - OpenOCD is talking to the board. Now you can either connect to OpenOCD by using telnet and use the command line interface to do things like flash the board, start/stop the cpu, use boundary scan or whatever. That's:
$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>
4) Now you can flash your micro (it is possible to do it from gdb too, though). Type at the OpenOCD prompt:
init
reset halt
flash write_image erase absolute-path-to-your-bin-file 0x08000000
verify_image erase absolute-path-to-your-bin-file 0x08000000
reset run
And that's it. Just make sure you are not trying to flash the .elf file. You must flash a raw binary, not elf. And use full path, because otherwise it is relative to the folder where you have started OpenOCD from.
Most often you don't want to use that, except maybe for programming from a script.
However, gdb is just as simple:
1) Build your code with debug symbols (-g flag for GCC, you will likely want -O0 to disable optimization too)
2) Run ARM (or whatever you are debugging) gdb:
$ arm-none-eabi-gdb my-code.elf
GNU gdb (GDB) 7.10
<... snipped a lot of blurb ...>
Reading symbols from my-code.elf ...done.
(gdb)
3) now type at the (gdb) prompt:
(gdb) target extended localhost:3333
Remote debugging using localhost:3333
reset_handler () at ../../cm3/vector.c:68
68 for (src = &_data_loadaddr, dest = &_data;
(gdb) monitor reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080012e0 msp: 0x20001800
(gdb)
4) And that's all. The first (target) command connects gdb to OpenOCD which acts as a driver for the JTAG/SWD dongle talking to your target and the second (monitor) command resets and halts the target, so that you are starting from a defined state and not from somewhere in the middle of the code wherever the CPU was when it was halted by OpenOCD/gdb.
I have these commands in my .gdbinit file, so I don't have to retype them. If you are using an IDE, you can usually specify commands like this in the dialog box where one configures GDB (e.g. Eclipse has it)
5) Now you can start debugging - type "tb main" to set temporary breakpoint on main and "run" to start the code. The "load" command will flash the binary to the target.
Btw, CTRL+x a (press ctrl and x together, release, then press a) will give you a text UI in case you are debugging from command line directly.
There is nothing mysterious about these tools. The only problem used to be OpenOCD's documentation, but that has improved a lot in the recent years.