How to set up debugging for Neucleo-64 board in STM32CubeIDE?

[SRogers]

I need some assistance in setting up a valid debugging environment in STM32CubeIDE using a Neucleo-64 STM32F103RB board.

I have wide experience in C, C++, and C#. I have also experience in the Arduino IDE, having made several projects there. After my initial setup of a valid toolchain, I planning to develop on STM32 parts commonly available on the Blue Pill development board.

I purchased a Neucleo-64 STM32F103RB because it appeared to be the closest STM32 part in the Neucleo-XX line to the Blue Pill development board. 

I also purchased the book Beginning STM32 and the book Mastering-STM32.pdf as reference guides to setting up an appropriate toolchain for STM32 development. My primary requirement in the toolchain is to have inline debuging capability.

Each of the toolchain reference guides I purchased provided me some insight into the setup of a toolchain. There exist several toolchains that I supposed could be used, but each toolchain has its own complexities in setup. I went to the blog of the of the author for the reference Mastering-STM32.pdf reference where he essentially indicated that his reference for a Windows setup is more complicated than that which would be needed to setup the STM32CubeIDE and that one probably should adopt that free toolchain in place of the toolchain he recommends in his reference and skip the more complex setup information therein because a single installation of the STM32CubeIDE should suffice for his reference without a lot of setup nuances. This is the path I have taken.

Right now, I have succeeded in rewriting the blinky program for my STM32 Nucleo-64 in a way that I know that my code changes have taken because I can run the new code and it works as it should. What I cannot do is to debug it. I get an error regarding the I would have thought that the debugging in the STM32CubeIDE would be very tightly integrated and require minimum setup for the Neucleo-64 STM32F103RB board with its integrated debugging capability. But when I try to debug I get the error "Error launching GDB Server. Session terminated".

I need to find some instructions on how to set up the debugging so that this error does not occur. Hopefully there is a document somewhere that indicates the debugging setup for a novice, or there is a sample blinky program that would include all of the setup needed for the Neucleo-64 STM32F103RB board.

There are a few other issues, such as I do not seem to see how to get the generated bin file from a project loaded directly from the development environment, but rather must drag it from the project folder to a separate drive-like icon on File Manager that appears as a result of installing the drivers for the on-board ST-Link hardware on the Neucleo-64 board.

I'm sure that there are just a few debug setup issues that have fallen through the cracks, but I do not seem able to find the information I need to pin these issues down.

Any help gladly accepted.

[KnarfB]

Its hard to tell what your problem is.

STM32CubeIDE surely has its quirks, but if installed with default settings (no paths changed,...) on a healthy Win10 or Ubuntu, I never had problems running and debugging a blinky or such.

Here is my recommendation for getting started:

• Watch the video How to use STM32CubeIDE
• Read UM2563 STM32CubeIDE installation guide and UM2553 STM32CubeIDE quick start guide, see https://www.st.com/en/development-tools/stm32cubeide.html#resource
• follow that path

There is no need to setup or tweak a toolchain upfront.

good luck

KnarfB

[O. Mz. - 7 · Accepted solution]

In the STM32CubeIDE you can click Run->Debug Configurations->Debugger (tab) and select ST-LINK (OpenOCD) instead of GDB server.

You can also use the CoolTerm, the free tool to view the Serial port communications. For this you have to activate in the System Core the SYS -> Debug:Serial wire and the correct UART in the Connectivity. And send variables' values to the serial port with:

HAL_UART_Transmit(&huart3, (uint8_t*)bfr, strlen(bfr), 1000);

On your board it could be not UART3, but some other one. Look at the schematics to see which UART.

[SRogers]

Thank you for this information. I did change the default location (path) for the STM32CubeIDE because I was following the path suggested for toolchain installation by the author of the Mastering-STM32.pdf guide. I thought that I might want to use some of that author's examples (which would have had paths referenced to his toolchain path). I shall remove the current STM32CubeIDE installation at this odd path and install it again at the default location. I have little currently invested in this STM32CubeIDE installation, so I think I can get the STM32CubeIDE to a point where it has the default path easily.

Will hopefully be able to report my success shortly.

[SRogers]

Thanks so much for this reply.

So the STM32CubeIDE provides two different debug approaches, one for a GDB server, and one for OpenOCD? For a beginner, would there be any specific advantage to using one or the other approach?

I was wondering about the integration of Serial port communications into debugging on the STM32CubeIDE. I thought it might be built in like it is on the Arduino IDE. I suppose that there will be times in which one would rather have the Serial port for debugging. I was hoping that using inline debugging would practically eliminate the need for Serial port debugging, but I suppose there are some good use cases for debugging with lots of data that might still lend itself to Serial port debugging.

[KnarfB]

I'm about to summarize some general documentaion here: https://gitlab.com/stm32mcu/wiki/-/wikis/home, see Debugging (in progress).

[SRogers]

Thank you for this hint to use OpenOCD. After reinstalling, I still had the same problem trying to debug with GDB Server. So I switched to OpenOCD, and it all just worked. It turns out that the book I'm using to get up to speed on STM32, Mastering-STM32.pdf , specifically recommends using OpenOCD, so all is well. In any case, I really don't care which one I use as long as I get good debuging--and I have that now. Thanks to all responders.

[MEwen.1]

I had exactly the same problem with my Nucleo-H743ZI2, and it worked as soon as I changed to OpenOCD.

Thanks a million for the advice.

Incidentally, I had to re-select OpenOCD again after I deleted my project in desperation and started again.