Unable to debug with eclipse+openocd+custom board

Development Boards MicroMod
1

Hi everybody.

I need to debug an application over a custom board hosting an stm32f427 mcu. Flashing the board with st-link utility works, but when I try with eclipse+openocd and even via windows prompt something goes wrong. Basicly what I get in the eclipse console/windows prompt is

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Started by GNU ARM Eclipse
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.239050
Info : stm32f4x.cpu: hardware has 0 breakpoints, 0 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x00000000
Warn : Cannot identify target as a STM32 family.
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected

and openocd runs with the options

-f board\stm32f429discovery.cfg

while st-link is configured with SWD and “connect under reset” options.

I am not an expert, but since with st-link utility I can flash the board I think is something related with the openocd configuration also by considering the warning in the code above. Any help is really appreciated.

Regards.

2

Ok, this is for those who will hit the same problem. Basicly there was a misconfiguration: the external oscillator was set to 8khz while in my case is 25 mhz. Since I am using gnuarmeclipse plug-in template I forgot to modify accordingly some files. Because of this, the debugger was not able to operate correctly when called whithin eclipse.

I discovered this problem by debugging via prompt. I guess this happened because in the eclipse debug tool the initial breakpoint is inserted at main by default but according to the code arrangement of the gnuarmeclipse suite templates for stm32f4xx architecture the configuration files are called before the program enters the main.

It is possible to set the initial breakpoint at a different location but I forgot that because I have neve exploited this possibility so far.