starting the debugger : (Read)Failed determine breakpoint type

Evan .1 · ‎2020-05-12

When I start the debug environment in stm32CubeIde. I got the following error message:

STMicroelectronics ST-LINK GDB server. Version 5.5.0

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

InitWhile : Enabled

Waiting for debugger connection...

Debugger connected

-------------------------------------------------------------------

STM32CubeProgrammer v2.4.0

-------------------------------------------------------------------

ST-LINK SN : 003A001A3038510234333935

ST-LINK FW : V3J6M2

Voltage : 3.30V

SWD freq : 24000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x480

Device name : STM32H7A/B

Flash size : 2 MBytes

Device type : MCU

Device CPU : Cortex-M7

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a16304.srec

File : ST-LINK_GDB_server_a16304.srec

Size : 96 Bytes

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sector 0

Download in Progress:

File download complete

Time elapsed during download operation: 00:00:00.228

Verifying ...

Download verified successfully

(Read)Failed determine breakpoint type

Error! Failed to read target status

Debugger connection lost.

Shutting down...

Sugestions what is wrong?

Thanks!.

Uwe Bonnes · ‎2020-05-13

It look like your gdb server from 2019 does not know the STM32H7A/B release in 2020. Check for updates.

Evan .1 · ‎2020-05-13

I did check for updates. And I got the latest version.

STM32CubeIDE

Version: 1.3.1

Build: 6291_20200406_0752 (UTC)

OS: Windows 10, v.10.0, x86_64 / win32

Java version: 1.8.0_202

PVand.9 · ‎2020-12-16

How was this problem solved?

I have the same problem starting to debug with the Nucleo-L053R8 with STM32Cube v.1.5.0

PVand.9 · ‎2020-12-16

I was able to get one step further:

It seems that STM32CubeMX had failed to create a directory called "startup" in the directory "core" as it did in earlier days. (or my settings must have changed since)

By copying this directory with the one file in it from a previous program (and erasing the two lines that created errors on compiling), the program starts working, but I'm still not able to pause or step it.

The debugger seems to pause, but the real program on the Nucleo keeps running (flashing leds f.e.)

PVand.9 · ‎2020-12-17

I continues by choosing the OpenOCD as debug probe instead of the ST-link GDB server (in debug configurations - tab debugger). Here the debugging seems normal.

MPrud.3 · ‎2021-09-15

The "Startup" directory is used by the vendor code. Did you write your own Makefile and startup code?

I just had the same problem. I wrote my own Makefile + startup code. (Cortex-M0+)

I also noticed that if i use the vendor code, i don't get this problem.

I tracked it down to how I link.

I had to remove the -Wl,--gc-sections from my linker.

Interesting, because the vendor Makefile uses -Wl,--gc-sections when linking. The actual answer may be something else, but this worked for me.

Here is how I link.

MACH = cortex-m0plus

FPU = -mfloat-abi=soft

LIBGCC = -lgcc

LIBMATH = -lm

MAP = -Wl,-Map=final.map

LDFLAGS = -mcpu=$(MACH) -mthumb $(FPU) -T linker_script.ld $(MAP) -nostdlib -Wl,--start-group $(LIBMATH) $(LIBGCC) -lc -lnosys -Wl,--end-group

$(EXECUTABLE_WPATH): $(OBJ)

$(CC) -o $@ $^ $(LDFLAGS)