one breakpoint creates multiple breakpoints and debugging fails

[RChap.1]

I can no longer use breakpoints. When I insert 1 I get the banner complaining about too many breakpoints. I've cleared debug configurations, breakpoints, restarted, but the problem persists. I even went to the debugger console and inserted a single breakpoint there manually but it still inserted multiple breakpoints.

Here is the log from the debugger console. My typings are in bold. Initially there is a single temporary breakpoint but when I try to insert one, it inserts 64 breakpoints! What is going on and how do I fix it?

GNU gdb (GNU Tools for STM32 11.3.rel1.20230912-1600) 12.1.90.20220802-git

Copyright (C) 2022 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<https://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word".

info br

Temporary breakpoint 1, main () at ../Core/Src/main.c:89

89 HAL_Init();

info br

No breakpoints or watchpoints.

break cli.c:418

Breakpoint 2 at 0x8035ed0: cli.c:418. (32 locations)

info br

Num Type Disp Enb Address What

2 breakpoint keep y <MULTIPLE>

2.1 y 0x08035ed0 in safeEmit at /software/cli.c:418

2.2 y 0x08035fa0 in safeEmit at /software/cli.c:418

2.3 y 0x08036068 in safeEmit at /software/cli.c:418

2.4 y 0x080360f8 in safeEmit at /software/cli.c:418

2.5 y 0x080367c6 in safeEmit at /software/cli.c:418

2.6 y 0x0803689e in safeEmit at /software/cli.c:418

2.7 y 0x0803694a in safeEmit at /software/cli.c:418

2.8 y 0x080369d6 in safeEmit at /software/cli.c:418

2.9 y 0x08036a8c in safeEmit at /software/cli.c:418

2.10 y 0x08036b74 in safeEmit at /software/cli.c:418

2.11 y 0x08036c44 in safeEmit at /software/cli.c:418

2.12 y 0x08037034 in safeEmit at /software/cli.c:418

2.13 y 0x080370e8 in safeEmit at /software/cli.c:418

2.14 y 0x0803727e in safeEmit at /software/cli.c:418

2.15 y 0x08037318 in safeEmit at /software/cli.c:418

2.16 y 0x080373a6 in safeEmit at /software/cli.c:418

2.17 y 0x080373fc in safeEmit at /software/cli.c:418

2.18 y 0x08037504 in safeEmit at /software/cli.c:418

2.19 y 0x080375a8 in safeEmit at /software/cli.c:418

2.20 y 0x0803766e in safeEmit at /software/cli.c:418

2.21 y 0x08037700 in safeEmit at /software/cli.c:418

2.22 y 0x080377c4 in safeEmit at /software/cli.c:418

2.23 y 0x08037b58 in safeEmit at /software/cli.c:418

2.24 y 0x08037c08 in safeEmit at /software/cli.c:418

2.25 y 0x08038bce in safeEmit at /software/cli.c:418

2.26 y 0x08038f84 in safeEmit at /software/cli.c:418

2.27 y 0x08039312 in safeEmit at /software/cli.c:418

2.28 y 0x080393b4 in safeEmit at /software/cli.c:418

2.29 y 0x08039404 in safeEmit at /software/cli.c:418

2.30 y 0x080394e4 in safeEmit at /software/cli.c:418

2.31 y 0x08039562 in safeEmit at /software/cli.c:418

2.32 y 0x08039774 in safeEmit at /software/cli.c:418

3 breakpoint keep y <MULTIPLE>

3.1 y 0x08035ed0 in safeEmit at /software/cli.c:418

3.2 y 0x08035fa0 in safeEmit at /software/cli.c:418

3.3 y 0x08036068 in safeEmit at /software/cli.c:418

3.4 y 0x080360f8 in safeEmit at /software/cli.c:418

3.5 y 0x080367c6 in safeEmit at /software/cli.c:418

3.6 y 0x0803689e in safeEmit at /software/cli.c:418

3.7 y 0x0803694a in safeEmit at /software/cli.c:418

3.8 y 0x080369d6 in safeEmit at /software/cli.c:418

3.9 y 0x08036a8c in safeEmit at /software/cli.c:418

3.10 y 0x08036b74 in safeEmit at /software/cli.c:418

3.11 y 0x08036c44 in safeEmit at /software/cli.c:418

3.12 y 0x08037034 in safeEmit at /software/cli.c:418

3.13 y 0x080370e8 in safeEmit at /software/cli.c:418

3.14 y 0x0803727e in safeEmit at /software/cli.c:418

3.15 y 0x08037318 in safeEmit at /software/cli.c:418

3.16 y 0x080373a6 in safeEmit at /software/cli.c:418

3.17 y 0x080373fc in safeEmit at /software/cli.c:418

3.18 y 0x08037504 in safeEmit at /software/cli.c:418

3.19 y 0x080375a8 in safeEmit at /software/cli.c:418

3.20 y 0x0803766e in safeEmit at /software/cli.c:418

3.21 y 0x08037700 in safeEmit at /software/cli.c:418

3.22 y 0x080377c4 in safeEmit at /software/cli.c:418

3.23 y 0x08037b58 in safeEmit at /software/cli.c:418

3.24 y 0x08037c08 in safeEmit at /software/cli.c:418

3.25 y 0x08038bce in safeEmit at /software/cli.c:418

3.26 y 0x08038f84 in safeEmit at /software/cli.c:418

3.27 y 0x08039312 in safeEmit at /software/cli.c:418

3.28 y 0x080393b4 in safeEmit at /software/cli.c:418

3.29 y 0x08039404 in safeEmit at /software/cli.c:418

3.30 y 0x080394e4 in safeEmit at /software/cli.c:418

3.31 y 0x08039562 in safeEmit at /software/cli.c:418

3.32 y 0x08039774 in safeEmit at /software/cli.c:418

[Ghofrane GSOURI]

Hello @RChap.1 

First let me thank you for posting.

Could you please indicate which STM32CubeIDE version , STM32 board and OS that you are using in order to push further the investigation.

I will be waiting for your feedback .

Thx

Ghofrane

[RChap.1]

Version: Version: 1.14.1

Custom board with STM32L4R5ZIT-6 micro

Custom OS.

I've isolated the issue. It has to do with a macro that is used to create an atomic region of code. The breakpoint somehow decides that multiple breakpoints are necessary.

Here is a snippet of code with the macro and some example code:

#define ENTER_REGION()                                          \
	{                                                           \
		bool int_interrupt_enabled = __get_PRIMASK();           \
		if (int_interrupt_enabled) __disable_irq();

#define LEAVE_REGION()                                          \
		if (int_interrupt_enabled) __enable_irq();              \
	}

#define ENTER_SAFE_REGION() ENTER_REGION()
#define LEAVE_SAFE_REGION() LEAVE_REGION()

#define safe(code) 	\
	ENTER_SAFE_REGION() \
	code \
	LEAVE_SAFE_REGION()

void record_event(const char * e) {
	if (playback == false)
		safe(record(e);)
}

If I set breakpoints on the two lines in the function record_event() [19,20], I end up with 3 breakpoints. This is from the debugger console:

info br
4       breakpoint     keep y   0x0803b93c in record_event at tea.c:19
5       breakpoint     keep y   <MULTIPLE> 
5.1                         y   0x0803b950 in record_event at tea.c:20
5.2                         y   0x0803b96e in record at tea.c:20

[RChap.1]

Macros seem to be a problem in general. I set a breakpoint on line 4 with the BLACK_HOLE() macro and I get multiple breakpoints. This represents the extracted code under examination:

#define BLACK_HOLE(reason) system_failure(reason)

if (m == 0)
	BLACK_HOLE(ACTION_NULL);
if (m == no_action)

In the breakpoints panel it only shows up as 1 breakpoint. The only way to know that there are multiple breakpoints is to use the debugger console:

info br
1       breakpoint     keep y   <MULTIPLE> 
1.1                         y   0x0803ae3a in actionRun at tea.c:4
1.2                         y   0x0803aef0 in actionRun at tea.c:4
1.3                         y   0x0803b0bc in actionRun at tea.c:4
1.4                         y   0x0803b83a in actionRun at tea.c:4

The memory span from the first breakpoint to the last breakpoint is 2560 bytes and is curious. Seems like a large memory span for a breakpoint for a single function call. I checked the breakpoint addresses in the .map file to find out what functions they were in and only the 4th breakpoint (1.4) is in the function actionRun. The other 3 breakpoints are in different functions elsewhere in the file and will cause phantom breakpoints to happen. Which I was also noticing.