Forum Replies Created
-
Posts
-
Hi,
Normally, the sizes for FLASH and RAM would be automatically derived from the db\mcu\families.xml in the STM32CubeMX directory when you generate the project.
If it doesn’t happen, please try updating to VisualGDB 5.6 Beta 1, and the latest STM32CubeMX. If this still doesn’t work, please let us know the exact device name you are using and we will recheck it.
Hi,
If the ST Fork of OpenOCD does not appear in VisualGDB GUI, please try attaching a screenshot of the debug method list, and a screenshot of the debug packages showing that the ST Fork package has been installed, so that we could see what is going on.
If OpenOCD works differently under VisualGDB vs. STM32CubeIDE, please try comparing its command lines and make sure that all involved scripts are the same. If this doesn’t help, please try replacing the OpenOCD executable used by VisualGDB with the executable from the STM32CubeIDE. This should ensure that it works exactly the same way in both cases.
Hi,
We would advise first getting it to work with the command-line tools per PicoSDK documentation. Once you can confirm that it works, feel free to let us know more details and we will help you configure VisualGDB to replicate your setup.
Hi,
Normally this should work. If it doesn’t, please try reproducing the problem on a fresh project created from scratch. If it happens reliably and you could share the steps we could follow to reproduce it, we can gladly investigate it further.
If the problem only happens on a specific project, please try comparing its .vgdbcmake file against the one created from scratch. Some of the options set there might be interfering with this.
Another thing to check would be the GDB command line shown in the GDB Session window. If it got overridden at any point, the command-line arguments would indeed not reach the application.
Hi,
Please try updating to VisualGDB 5.6 Beta 1 and then use Tools->VisualGDB->Manage VisualGDB Packages to get the latest list of debug methods.
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.
