Newbie here. I would like to use STM32CubeIDE to debug the Marlin 3D printer software running on a STM32F429 via an ST-Link. I don't want to compile. Pointers to the right docs to read, what project type to use, debug setup would be appreciated.

[Danish1]

You’ll need to compile the code so that the IDE can relate machine-code instructions that the stm32 actually executes with the program source code. I don’t think there’s any way around that.

And any code that controls real-time hardware, such as a 3D printer, will be difficult to debug simply because the hardware won’t take kindly to the drive from the stm32 being frozen. But debugging often involves detecting an unexpected situation and then freezing things while you gather evidence as to how the situation arose.

You describe yourself as a newbie. If at all possible, try to learn stm32 debugging first on a much simpler system ( i.e. without printer hardware). It might not sound like much, but there’s an amazing number of things you need to get right just to flash an LED. And it is necessary to learn-by-doing.

Hope this helps,

Danish

[Nikita91]

One of the most useful ways to debug a real-time application whose timing must not be disturbed (like when driving a motor) is to add traces. Sometimes the display (on UART or SWO) of a single character placed in the appropriate places makes it possible to see what the application is really executing, without notably disturbing its timing.

To do this, you must modify the source of the application. So it seems to me necessary to have a complete project in the IDE for what you want to do.

[BKuhn]

I'm a newbie to STM32CubeIDE.

I've done a blinkey on a Nucleo board via STM32CubeIDE so I have a tiny bit of experience.

What I want to do is point STM32CubeIDE at an existing Marlin program (including the ELF) and be able to do source line debugging.

Marlin already has a nice method of compiling so I don't need to use STM32CubeIDE to modify & compile the code.

I've tried to create a C++ project, point it at the ELF and then use the C++ application debugger defaults. The result was a "Failed to execute MI command: .... error 193". I can't find anything on what that means.

I expect that there'll be a significant learning path. I don't know how to find the docs that'll help me select the proper project type and proper debug configuration.

I was hoping for something like "Most externally developed C++ programs use xyz project type. Debug configuration abc has been useful. Docs for these are at link". Quite a lot to ask.

Bob

[Nikita91]

It doesn't work like that.

In the .elf file you have paths to source files to guide the debugger. If your environment doesn't have the files in exactly the same location they won't be found.

AFAIK if you want to use CubeIDE, you must create a CubeIDE project with the sources of your application.

Otherwise, use the tool used to generate the application!

[BKuhn]

Thanks

[Markus GIRDLAND]

"Marlin already has a nice method of compiling so I don't need to use STM32CubeIDE to modify & compile the code."

If you don't need to modify or compile the code then I would suggest that in STM32CubeIDE you use the import method of "File -> Import -> Cortex-M exectuable". It's a nice way to just get started with some debugging without all the configuration usually needed.

[BKuhn]

That was easy. Took me to a debug configurations screen. Clicked debug. The screen went away and nothing happened.

Ideas/suggestions?

[Markus GIRDLAND]

Do you get some sort of output from a console about what is happening? You might need to configure the debug configuration to reflect the debug probe you are using.

I would assume the first step would be STM32CubeProgrammer that will flash the application to your board which should be output to the console. Either it should show an error or it will have done the process and the error should be visible in the next step in the process, probably ST-Link/J-Link log output.

[BKuhn]

I have auto build disabled. There is no feedback in the build console or anywhere else.

The only feedback I get is when the target is disconnected and then a pop up says it couldn't find the ST-Link.

Later I tried to start the server in a command window. No joy. Here's what happened with those attempts.

I copied the command line and started the ST-LINK GDB server in a command window. It connected to the target (ST-Link lights started flashing) but sits there forever with "Waiting for debugger connection...". In this case i clicked on connect to remote server and made sure the port numbers matched. Again it pops up the can't find ST-Link message and then closes.

I also tried the same think with st-link (open OCD) probe selected. Similar results. Open On-Chip Debugger started, connected to the ST-Link and just sits there waiting for the gdb connection. This time clicking on debug does NOT complain about not being able to find the ST-Link.