cancel
Showing results for 
Search instead for 
Did you mean: 

Why doesn't gdb reach a breakpoint in main?

matt2399
Associate II
Posted on December 17, 2014 at 17:43

Hello,

I'm trying to debug a simple test program (

http://developer.mbed.org/teams/ST/code/Nucleo_blink_led/

) on my Nucleo board. I've successfully compiled it using GCC-ARM (arm-none-eabi-gcc), flashed my device over USB, and saw the light blink on and off. The trouble arises, however, when I try to actually step through my program. And yes, I made sure to enable debugging with the ''-g'' compile flag.

Here's my terminal output. I start the gdb server daemon using OpenOCD...

matt@ubuntu:~/Nucleo_blink_led$ openocd -f board/st_nucleo_f401re.cfg

Open On-Chip Debugger 0.8.0 (2014-05-10-23:20)

Licensed under GNU GPL v2

For bug reports, read

        http://openocd.sourceforge.net/doc/doxygen/bugs.html

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : This adapter doesn't support configurable speed

Info : STLINK v2 JTAG v19 API v2 SWIM v3 VID 0x0483 PID 0x374B

Info : using stlink api v2

Info : Target voltage: 3.257255

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

...execute gdb in another window...

matt@ubuntu:~/Nucleo_blink_led$ arm-none-eabi-gdb Nucleo_blink_led.elf

GNU gdb (7.8-0ubuntu1+6) 7.8

Copyright (C) 2014 Free Software Foundation, Inc.

...

Reading symbols from Nucleo_blink_led.elf...done.

(gdb)

...enter a few commands...

(gdb)

tar ext :3333

Remote debugging using :3333

gpio_write (obj=0x20000268 <myled>, value=1)

    at ./mbed/TARGET_NUCLEO_F401RE/TARGET_STM/TARGET_NUCLEO_F401RE/gpio_object.h:55

55            *obj->reg_set = obj->mask;

(gdb) b main

Breakpoint 1 at 0x80002a2: file main.cpp, line 7.

(gdb) r

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: /home/matt/Downloads/Nucleo_blink_led/Nucleo_blink_led.elf

Note: automatically using hardware breakpoints for read-only addresses.

...and get this output from OpenOCD.

Info : accepting 'gdb' connection from 3333

Info : device id = 0x10006433

Info : flash size = 512kbytes

target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x01000000 pc: 0x080004a4 msp: 0x20018000

Would somebody please tell me how to make sure that my program actually gets to main before halting, so I can step through it like I had originally meant to? Thanks in advance.

#openocd #debug #arm-none-eabi-gdb
2 REPLIES 2
Posted on December 17, 2014 at 18:07

In the CMSIS model the SystemInit() code in system_stm32fxxx.c is called long before it gets to your main() function, and before the C run time code does it's start up work.

If it doesn't get to main() you'd perhaps want to look at clock and PLL settings, and rather than ''run to main()'' you should step code from the ResetHandler on in.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
matt2399
Associate II
Posted on December 17, 2014 at 18:22

Thanks, I didn't realize that gdb would take me straight to main and pause--I thought it failed to start up altogether. I found that simply stepping through with ''n'' and setting breakpoints at line numbers (rather than the main function header) gets me to where I need to go. No need to look at the settings you suggested. 🙂