cancel
Showing results for 
Search instead for 
Did you mean: 

How to get rid of cached/ghost/phantom breakpoint in STM32CubeIDE?

sdbbs
Associate II

This is somewhat similar to OpenSTM32 Community Site | Phantom Breakpoint - except in STM32Cube IDE.

I have managed to create a reproducible example. I use MSYS2 on Windows 10, so excuse the bashisms.

$ systeminfo
...
OS Name:                   Microsoft Windows 10 Home
OS Version:                10.0.19042 N/A Build 19042
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
...
 
$ cat /c/ST/STM32CubeIDE_1.6.1/STM32CubeIDE/.eclipseproduct
name=STM32CubeIDE
id=com.st.stm32cube.ide.mcu.rcp.product
version=1.6.1

First, creating a fresh directory for a workspace:

$ mkdir /c/tmp/temp_workspace

Start "clean slate" STM32CubeIDE, with this directory as a workspace:

$ /c/ST/STM32CubeIDE_1.6.1/STM32CubeIDE/stm32cubeide.exe -clean -clearPersistedState -data /c/tmp/temp_workspace

Click "Start new STM32 project". From the Target Selection wizard, I go to Board Selector, choose NUCLEO-G071RB, -select the board, Next. Project name: my_nucleo_proj, keep the rest at defaults, click Finish; say Yes to other defaults in dialogs during project creation.

At this point, I save this as a git project in another terminal:

$ cd /c/tmp/temp_workspace/my_nucleo_proj/
$ git init
hint: Using 'master' as the name for the initial branch. This default branch name
...
Initialized empty Git repository in /c/tmp/temp_workspace/my_nucleo_proj/.git/
$ git config user.name me
$ git config user.email me@example.com
$ git add .
$ git commit -m 'init commit'
[master (root-commit) 24114eb] init commit
 84 files changed, 105400 insertions(+)
 create mode 100644 .cproject
...
 create mode 100644 my_nucleo_proj.ioc

Back to STM32CubeIDE: click Run / Run once - as first time, the project "* Debug" configuration gets created; accept all defaults, click OK.0693W00000AMp7CQAT.png 

For me, this build & run proceeds without errors.

Back to git, a new "my_nucleo_proj Debug.launch" file got created, add it and commit:

$ git add '*.launch'
$ git add -u
$ git status -uno
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   .settings/stm32cubeide.project.prefs
        new file:   my_nucleo_proj Debug.launch
 
Untracked files not listed (use -u option to show untracked files)
$ git commit -m '.launch created'
[master cbd9b8b] .launch created
 2 files changed, 73 insertions(+)
 create mode 100644 my_nucleo_proj Debug.launch

Back to STM32CubeIDE: click Run / Debug Configurations / Startup (tab); confirm we have "Set breakpoint at: main" checked; click Debug. The debugger starts, and as expected, breaks at main - Debugger Console says:

Temporary breakpoint 1, main () at ../Core/Src/main.c:75
75	  HAL_Init();

Click Resume, then Terminate to stop this debug run. Back to git, our launch file has changed:

$ git diff
diff --git a/my_nucleo_proj Debug.launch b/my_nucleo_proj Debug.launch
index 1159a47..1ce3860 100644
--- a/my_nucleo_proj Debug.launch
+++ b/my_nucleo_proj Debug.launch
@@ -68,5 +68,6 @@
     <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES"><listEntry value="4"/></listAttribute>
+    <stringAttribute key="org.eclipse.dsf.launch.MEMORY_BLOCKS" value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot;?&gt;&#13;&#10;&lt;memoryBlockExpressionList context=&quot;reserved-for-future-use&quot;/&gt;&#13;&#10;"/>^M
     <stringAttribute key="process_factory_id" value="org.eclipse.cdt.dsf.gdb.GdbProcessFactory"/></launchConfiguration>
$ git add -u
$ git commit -m '.launch after first debug'
[master 1c70ff7] .launch after first debug
 1 file changed, 1 insertion(+)

Back to STM32CubeIDE: click Run / Debug Configurations / Startup (tab); uncheck "Set breakpoint at: main" ; click Apply, then click Debug. The debugger starts, and as expected does not break, but instead keeps going.

Click Terminate to stop this debug run. Back to git, our launch file has changed:

$ git diff
diff --git a/my_nucleo_proj Debug.launch b/my_nucleo_proj Debug.launch
index 1ce3860..a8091ad 100644
--- a/my_nucleo_proj Debug.launch
+++ b/my_nucleo_proj Debug.launch
@@ -48,7 +48,7 @@
     <stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.runCommands" value=""/><booleanAttribute key="org.eclipse.cdt.debug.gdbjtag.core.setPcRegister" value="false"/><booleanAttribute key="org.eclipse.cdt.debug.gdbjtag.core.setResume" value="true"/>
-    <booleanAttribute key="org.eclipse.cdt.debug.gdbjtag.core.setStopAt" value="true"/>
+    <booleanAttribute key="org.eclipse.cdt.debug.gdbjtag.core.setStopAt" value="false"/>^M
     <stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.stopAt" value="main"/><stringAttribute key="org.eclipse.cdt.dsf.gdb.DEBUG_NAME" value="arm-none-eabi-gdb"/><booleanAttribute key="org.eclipse.cdt.dsf.gdb.NON_STOP" value="true"/>
@@ -56,7 +56,7 @@
     <intAttribute key="org.eclipse.cdt.launch.ATTR_BUILD_BEFORE_LAUNCH_ATTR" value="2"/><stringAttribute key="org.eclipse.cdt.launch.COREFILE_PATH" value=""/><stringAttribute key="org.eclipse.cdt.launch.DEBUGGER_START_MODE" value="remote"/>
-    <booleanAttribute key="org.eclipse.cdt.launch.DEBUGGER_STOP_AT_MAIN" value="true"/>
+    <booleanAttribute key="org.eclipse.cdt.launch.DEBUGGER_STOP_AT_MAIN" value="false"/>^M
     <stringAttribute key="org.eclipse.cdt.launch.DEBUGGER_STOP_AT_MAIN_SYMBOL" value="main"/><stringAttribute key="org.eclipse.cdt.launch.PROGRAM_NAME" value="Debug\my_nucleo_proj.elf"/><stringAttribute key="org.eclipse.cdt.launch.PROJECT_ATTR" value="my_nucleo_proj"/>
$ git add -u
$ git commit -m '.launch after uncheck of main breakpoint'
[master 1fe7d2c] .launch after uncheck of main breakpoint
 1 file changed, 2 insertions(+), 2 deletions(-)

Back to STM32CubeIDE: click Run / Debug Configurations / Startup (tab); check again "Set breakpoint at: main" ; then under "Run Commands", type or copy/paste the following:

b main
b SystemClock_Config

0693W00000AMp7RQAT.png 

... then click Apply, then click Debug. The debugger starts, and as expected, breaks at main; click Resume, then as expected, debugger breaks at SystemClock_Config; click Resume, and as expected, debugger does not break anymore. In Debugger Console, we have:

Temporary breakpoint 1, main () at ../Core/Src/main.c:75
75	  HAL_Init();
 
Breakpoint 3, SystemClock_Config () at ../Core/Src/main.c:112
112	  RCC_OscInitTypeDef RCC_OscInitStruct = {0};

(text is too large - continued in reply)

1 ACCEPTED SOLUTION

Accepted Solutions
alister
Lead

Sorry haven't read your post carefully and I may be well off the mark.

I'm not using CubeIDE but I'm familiar with Eclipse.

Is the rough breakpoint in memory inconsistent with what Eclipse's Breakpoint window shows?

Could you merely clear it in the Breakpoint window?

View solution in original post

3 REPLIES 3
sdbbs
Associate II

(cont'd)

Click Terminate to stop this debug run. Back to git, our launch file has changed:

Note that our Run Commands were added as part of the org.eclipse.cdt.debug.gdbjtag.core.runCommands key in the .launch file.

Final step: Back to STM32CubeIDE: click Run / Debug Configurations / Startup (tab); then under "Run Commands", erase all previous commands; click Apply, then click Debug.

The debugger starts, and as expected, breaks at main (because of the checkbox); click Resume, then UNEXPECTEDLY, debugger BREAKS at SystemClock_Config again:

Breakpoint 1, main () at ../Core/Src/main.c:75
75	  HAL_Init();
 
Breakpoint 2, SystemClock_Config () at ../Core/Src/main.c:112
112	  RCC_OscInitTypeDef RCC_OscInitStruct = {0};

,,, although note this time it is Breakpoint 1 and 2, as opposed to previous Temporary breakpoint 1 and Breakpoint 3.

Click Terminate to stop this debug run. Back to git, our launch file has changed - and it confirms that the "Run Commands" have been removed:

$ git diff
diff --git a/my_nucleo_proj Debug.launch b/my_nucleo_proj Debug.launch
index 5623209..1ce3860 100644
--- a/my_nucleo_proj Debug.launch
+++ b/my_nucleo_proj Debug.launch
@@ -45,7 +45,7 @@
     <stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.jtagDevice" value="ST-LINK (ST-LINK GDB server)"/>
     <stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.pcRegister" value=""/>
     <intAttribute key="org.eclipse.cdt.debug.gdbjtag.core.portNumber" value="61234"/>
-    <stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.runCommands" value="b main&#13;&#10;b SystemClock_Config"/>
+    <stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.runCommands" value=""/>^M
     <booleanAttribute key="org.eclipse.cdt.debug.gdbjtag.core.setPcRegister" value="false"/>
     <booleanAttribute key="org.eclipse.cdt.debug.gdbjtag.core.setResume" value="true"/>
     <booleanAttribute key="org.eclipse.cdt.debug.gdbjtag.core.setStopAt" value="true"/>

So, something must be caching these breakpoints that were entered previously in Run Commands - so now they hit as "ghost" breakpoints - even if the "Run Commands" script has been deleted!

But what is caching these breakpoints, and how can I get rid of this caching (without extreme steps, like deleting the workspace directory and restarting the project from scratch, like I had to do several times now, to be able to claim that the procedure in this post is reproducible)?

Bonus: close STM32CubeIDE, confirm Exit is asked. Now there is no more of that process - however:

$ tasklist | grep -i stm3
 
$ tasklist | grep -i stl
stlinkserver.exe              3464 Console                    1      7,688 K

... for some reason, stlinkserver.exe is still hanging in the process / task list? Is this expected? Should stlinkserver.exe remain as a running process, even after STM32CubeIDE has been closed?

alister
Lead

Sorry haven't read your post carefully and I may be well off the mark.

I'm not using CubeIDE but I'm familiar with Eclipse.

Is the rough breakpoint in memory inconsistent with what Eclipse's Breakpoint window shows?

Could you merely clear it in the Breakpoint window?

sdbbs
Associate II

Thanks a ton, @alister,

> Could you merely clear it in the Breakpoint window?

Yup, that was it - I was unaware of the Breakpoint window (just started with STM32CubeIDE) - and so I did Run/Debug again, when the debugger halted, I did Window > Show View > Breakpoints (the Breakpoints entry seemingly shows up only while debugging); and indeed - I could see those two breakpoints there:

0693W00000AMpENQA1.png 

Since it turns out, you can type in Debugger Console as well, info br confirms it is the same two breakpoints!

So, all I had to do was to Ctrl-A in the Breakpoints window to select them all, right-click, then choose Remove All - they were gone!

Terminated that debug, did Run / Debug again - and finally, they do NOT hit anymore (only the Temporary Breakpoint 1, that corresponds to the checkbox for breakpoint at main in Debug Configuration, hits - as expected); so, problem solved!

Many thanks again for the answer!