has anyone got debugging for STM32 working?

[PerennialNovice]

I am trying to activate debugging capabilities for STM32duino

I found that the instructions on the wiki are not quite up to date, but I roughly followed them with some modifications

I installed the GNU MCU plugin, though I was not able to deselect things as suggested in the above linked wiki.
${openocd_path}` had not been set, so I searched my system and the only openocd.exe I found was stored in

C:\Sloeber443\arduinoPlugin\packages\STMicroelectronics\tools\xpack-openocd\0.12.0-1\bin

and set it in Window -> Preferences -> MCU -> Global OpenOCD Path

As for the executable name, ${A.COMPILER.PATH}/arm-none-eabi-gdb did not give a path, so I looked at the environment variables and found that ${A.COMPILER.PATH} does not exist in my installation.
But I found another environment variable named ${compiler.path}, so I used that.
I got the OCD server running and working somehow.

But, when I run the debug configuration, I get a lot of output and on start, the source code does not appear, but instead a window with a button to open disassembly.

Not quite what I expected...

Sadly, Sloeber is not supported by the official STM32 Arduino core
stm32duino/Arduino_Core_STM32#2280

[jantje]

A.COMPILER.PATH is from really old Sloeber when CDT uppercased all environment variables.
The A. prefix has been removed as well.
So A.COMPILER.PATH is now compiler.path as it always should have been. compiler.path comes from the json and .txt files. You can see all environment variables created from these input in project->properties->c/C++ build->environment variables

gnu mcu has become part of the eclipse community and is now embedded C/C++ https://marketplace.eclipse.org/content/eclipse-embedded-cc
I'm not sure you need the embedded C/C++ plugin but it is probably the best documented for you.

Also note #1625
Assuming that STM32 has supports debug and release I would make 2 configurations (debug and release)
In release create the environment variable
compiler.optimization_flags=${compiler.optimization_flags.release}
In debug create the environment variable
compiler.optimization_flags=${compiler.optimization_flags.debug}
Note I haven't tested this but this is how I'd start and if this doesn't work it should be something very similar.

As to not supported.
This basically means they will not actively look for things to work.

[PerennialNovice]

Thanks!

will give it a try

[PerennialNovice]

I just checked the envrionment variables and found this:

looks kinda weird to me...

[jantje]

Looks normal to me.
This is basically the processed .txt and jason file content as environment variables.
Not sure what you think is weird about it.

[PerennialNovice]

this one:

compiler.optimization_flags=${compiler.optimization_flags}

[jantje]

As this is in the platform.txt
compiler.optimization_flags={compiler.optimization_flags}
You should talk to STMicroelectronics on why they do something like this.
I'm just happy it doesn't cause havoc and the environment variable extraction seems recursive safe.

[PerennialNovice]

seems they have found out already:

fix(platform): wrong optimization_flags for Arduino 1.8.x

[jantje]

That is good.
Less reassuring is they seem to fail to understand what this is all about. If they did they would have done
compiler.optimization_flags={compiler.optimization_flags.release}
Not that it makes a difference in the build result. But it does in showing you understand that compiler.optimization_flags is actually a switch to switch between debug/release(and maybe others) optimization flags.
Also note how the following line is confusing
compiler.optimization_flags.release={build.flags.optimize} {build.flags.debug}
It basically explicitly states states that the release optimizations flags contain debug flags.
Given the definition of build.flags.debug
build.flags.debug=-DNDEBUG
I wonder does the N means Not?
I'm confused.
And that is why I only look at this with a specific reproducible problem.

[PerennialNovice]

And that is why I only look at this with a specific reproducible problem.

absolutely understandable!

Nevertheless your comments help me get an idea what is going on and - hopefully - to get debug running...

I'm a bit short of time, but if I should manage to get a reproducible behaviour I'll keep you posted.
Thanks for your help so far

[PerennialNovice]

Made some progress on this and thought I'd share my findings

• I started with a fresh install of Sloeber 4.4.3 product

• then added STM32 platform from

  https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json

• then go to Help -> Install New Software and search for openOCD which yields exactly one result which I installed

• create blink example for STM32 (Nucleo-L412KB in my case) with debug options enabled
  Optimize on Debug (-Og) and Debug symbols and core logs set to Core logs and Symbols enabled(-g)

• build project by hitting Ctrl-R (takes an awful lot of time on Windows - blessed are the Lunix-users ;) )

• Then create a run/debug configuration by right-click on the project -> Debug as -> Debug configurations -> double-click on GDB OpenOCD Debugging

• leave Main unchanged and go to Debugger-tab and follow the link to the global preferences for the openOCD path and set it to

  "SLOEBER_HOME"\arduinoPlugin\packages\STMicroelectronics\tools\xpack-openocd\0.12.0-1\bin (for Windows)

• set config options to

  -s "${openocd_path}/../scripts" -f interface/stlink-v2-1.cfg -f target/stm32l4x.cfg

• set the GDB exectuable name to

  ${compiler.path}/arm-none-eabi-gdb

• on the Startup tab, set Pre-run/Restart reset commands to

  monitor reset halt
  monitor reset init

• click apply and the debug

Now, all should run without error, but no source is shown!
Instead the source not found window appears stating that main() could not be found

This is essentially what I described when starting this discussion here.

Now, go to Project -> Properties -> Sloeber -> Compile Options and add -ggdb to append to C and C++ and run the freshly created Debug Configuration again (which takes an awful lot of time on windows because a complete build has to be done)

The binary is downloaded to the µC and execution halts at the beginning of main() AND the corresponding source file is shown in the editor !
Using the debug controls in the toolbar you now can jump in/over/out of functions at will and set some breakpoints, watch expressions, etc...

Happy debugging :)

Credits go to Zach Wilcox over there on the Eclipse Forums for finding this back in 2018

[jantje]

1. congratulations
   2)I'm not sure why you call it "made some progress" as it seems it is working.

[PerennialNovice]

at the time of writing it was like a "one of" and it only works in the exact way described. I didn't get my "old" installation of sloeber with the actual projects to correctly run debug.
And, there are some minor flaws like the perspective not switching back when stopping debug execution...

But yes, you are right, it is a success

[jantje]

the perspective not switching back when stopping debug execution.

I think this is default behaviour

[PerennialNovice]

Ah! Good to know, thanks