Forum Replies Created
-
Posts
-
Hi,
The STM32CubeIDE uses a specialized ST fork of OpenOCD. You can configure VisualGDB to use it by selecting OpenOCD (ST Fork) instead of just OpenOCD as the debug method.
If this doesn’t help, most likely the OpenOCD script used by STM32CubeIDE does some additional board-specific initialization. In this case, we would advise locating the OpenOCD command line in the STM32CubeIDE debug logs, copying the script mentioned there to your project directory, and using the Advanced mode in VisualGDB Project Properties -> Debug Settings to use the same script instead of the default script. You can use expressions like $(ProjectDir) to refer to the project directory.
You can also configure VisualGDB to use the ST-Link server same way as STM32CubeIDE does (since it is somewhat undocumented and not available as a separate executable, VisualGDB doesn’t support it out-of-the-box). Simply locate the ST-Link server command line and the GDB connection command (typically target remote <…> or -target-select remote <…>) in the STM32CubeIDE debug logs and copy them under VisualGDB Project Properties -> Debug Settings -> Custom GDB Stub. VisualGDB will then launch the server with the same parameters and it should work exactly the same way.
Hi,
Most likely, when using the STM32CubeMX project, you select some settings that interfere with debugging. Please try checking if the project is debuggable with other tools (e.g. STM32CubeMX tool or by running OpenOCD manually). If not, please refer to your device datasheet to make sure all prerequisites for debugging are fulfilled.
For any questions about specific orders, licenses and payment issues, please contact our support directly.
Hi,
For any questions about specific orders, licenses and payment issues, please contact our support directly.
According to our records, the technical support on your license is not active. You are free to seek advice from other users, however we will not be able to provide further help.
According to our records, the technical support on your license is not active. You are free to seek advice from other users, however we will not be able to provide further help.
Hi,
@arrow201, thanks for your input! The STM32CubeMX indeed makes it easier to quickly explore STM32-specific functionality, but makes it harder to maintain the projects in the long term.
@Vlad, the importing methods you mentioned should all work for the scenario you described. VisualGDB can automatically import basic project settings (list of files, include directories, preprocessor macros, linker script), however STM32CubeMX sometimes generates buggy project files (e.g. references non-existing sources or headers), and also some advanced settings (e.g. optimization) would need to be imported manually.Most of the errors with imported STM32 projects come from duplication between the files provided by VisualGDB and the files imported from the project. We have a very detailed documentation page here that explains the typical STM32 project structure and gives an overview of different project subtypes (it does not mention the new STM32CubeMX Wizard yet).
We would advise first getting it working with an instance of gdb manually launched via command line. Once you can confirm that it works reliably, feel free to let us know the tools and commands lines involved, and we will help you configure VisualGDB to replicate that setup.
Hi,
VisualGDB should normally already use the relative paths as reported by CMake. However, if your codebase spans across multiple drive letters or some CMake files use absolute paths to refer to the source files, the absolute paths may indeed end up in the VisualGDB’s settings files.
If you can reproduce the problem on a clean project and share the steps we could follow on our side to get the same behavior, we will gladly look into it and try to suggest a workaround.
Hi,
This likely has something to do with the environment. A good starting point would be to dump the build command used by VisualGDB into a batch file as shown here, and to try running the application in the same environment.
If it doesn’t help, please try building the project manually and see if the executable produced via the manual build works differently.
Hi,
Thanks for pointing this out. We have reproduced the problem.
Turns out, when you select a different board in the STM32CubeMX, it re-creates the .ioc file from a different template, overriding the default source directory:
ProjectManager.MainLocation=Core/Src
Later on, VisualGDB asks STM32CubeMX to first generate a Makefile-based project, and then a GPDSC-based project:
project toolchain "Makefile" project generate project toolchain "Other Toolchains (GPDSC)" project generate exit
Apparently, if the source directory is overridden, STM32CubeMX will delete the Src folder during the second project generation.
You can work around it by commenting out the ProjectManager.MainLocation line in the .ioc file and regenerating the project once again via the context menu on STM32CubeMX Files the in Solution Explorer.
We will also add a warning about this to the next VisualGDB release.
Strange. VisualGDB does not delete any of the source files as a part of the importing process. Most likely, something else is going on.
Please share the complete steps we could follow on our side to reproduce the problem, including the screenshots of all relevant settings, and we will recheck what could be causing it.
Hi,
It could be a bug in the STM32CubeMX tool. Please try running it manually, creating a new project, and generating a .gpdsc file for it. Does the generated file reference all the relevant sources? Are they physically present?
No problem,
The “Cannot identify target as an STM32G0/G4/L4/L4+/L5/WB/WL family device” message means that the support for your device has not been added to OpenOCD yet.
Please consider waiting a couple of months for ST to add support for them, or try building OpenOCD manually as shown here and patching it manually. It typically involves searching for the error message and adding an entry for your device to the supported device list (the entry would map the flash ID to the parameters like page size taken from the device datasheet).
Another option would be to use Segger J-Link with the Segger software. It gets updated much more often than OpenOCD and hence gets to support new devices much faster.
