1. 技术文章
  2. How to use the GDB (Gnu Debugger) and OpenOCD for microcontroller debugging - from the terminal?

How to use the GDB (Gnu Debugger) and OpenOCD for microcontroller debugging - from the terminal?

由 泄露秘密 提交于 2019-11-28 15:19:41

As I remember it I had some trouble with the straight load command too, so I switched to "flash write_image erase my_project.hex 0 ihex" .. obviously I was using hex files but it looks like elf files should work to, see http://openocd.org/doc/html/Flash-Commands.html ... the good thing about this command is it also erases only the flash sections that are being written to which is really handy and you don't need an erase

Before you run the above command you will need to run "stm32f1x unlock 0" to ensure the chip is unlocked and your allowed to wire to the flash ... See The datasheet about this

Also for getting started the command "stm32f1x mass_erase 0" will erase the chip fully and quickly so it's good to ensure you start in a known state

I know some of these commands say they are for the f1's but trust me they work for the f4 series to

Btw this file contains most of the command I use to flash my f4 so it might be a good reference https://github.com/othane/mos/blob/master/hal/stm32f373/stm32f373.mk

I Hope that gets you unstuck

This is a little brief and not great stackoverflow style but I would point you to my code where I have set this up for my "mos" library for the STM32F4 and STM32F1 (https://github.com/othane/mos) ... This is a big topic to answer so I though an example might be better

In short, my project is a tree of Makefiles, since you have your code compiling the main one of interest for you is found here https://github.com/othane/mos/blob/master/hal/stm32f373/stm32f373.mk ... basically you need openocd and then I have a series of commands to allow erasing the chip, or flashing and debugging the new code etc by simply typing make .erase or make .flash or make .debug

finally if you look in my unit tests (these are basically example programs) you will find the Makefile to build it + a gdbinit file like this one https://github.com/othane/mos/blob/master/utest/gpio/debug_gpio_utest.gdbinit ... then you simply do "make && make .flash && make .debug" in one terminal, and call your cross compilers gdb like this "arm-none-eabi-gdb -x ./debug_gpio_utest.gdbinit" in another ... this will start gdb after flashing the code and you can use the normal break and list commands from gdb etc to interact with the code (note how I defined a reset command in the .gdbinit file, checkout the help for the mon command ... basically it will let you send commands through gdb directly to openocd and is really useful)

Sorry the answer is quite brief and lots of links, but I hope it gets you going.

At first sight the distribution on gnutoolchains.com should be good enough. There are a number of build script to brew your own version. I do have mine to include the ARM7TDMI. It works fine under Linux and FreeBSD but MinGW failed last time I tried it :-(

Regarding OpenOCD, I would recommend to start it in the same directory as your GDB instance, so that the binary download seems transparent if you invoke it from within GDB (the easiest way). You also have the option to create a script that starts OpenOCD and load the code but then you would have to restart it after each compilation.

You now just invoke "gdb" and connect it to the "remote server" (localhost if the server and gdb are running on the same machine). Configure GDB such that it knows the location of the source code and the location of the ELF file. There are a ton of websites that go through the basic usage of GDB..

There seems to be a GDB for Windows (http://www.equation.com/servlet/equation.cmd?fa=gdb)

The following commands in GDB should get you started:

target remote localhost:3333

directory /path/to/project

symbol-file /path/to/project.elf

Apparently it was a hardware issue. I had never thought that my chip would be defect, since loading the binary onto the chip with the STLink Utility tool worked without problem. Only OpenOCD was complaining and giving errors. So naturally I blamed OpenOCD - and not the chip itself.

Today I tried the same procedure on with a new chip on the board, and now it works!

I get the following output in GDB when issuing the load command:

    (gdb) load
       Loading section .isr_vector, size 0x1c8 lma 0x8000000
       Loading section .text, size 0x39e0 lma 0x80001c8
       Loading section .rodata, size 0x34 lma 0x8003ba8
       Loading section .init_array, size 0x4 lma 0x8003bdc
       Loading section .fini_array, size 0x4 lma 0x8003be0
       Loading section .data, size 0x38 lma 0x8003be4
       Start address 0x8003450, load size 15388
       Transfer rate: 21 KB/sec, 2564 bytes/write.
    (gdb)

Thank you to everyone who did his/her best to help me :-)

标签
gdb
gnu
jTag
openocd
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!