Forum Replies Created
-
Posts
-
Sorry, we have tried just that when you first reported it, and it built successfully. As you have not provided the complete screenshots of all related wizard and settings pages per our previous reply, it is hard to suggest anything else.
Most likely, you have edited some code on your side at some point. Either way, we will keep an eye on it and will investigate it further in case other users report similar issues.
If you can confirm that a project created from the VisualGDB template without any modifications doesn’t build out-of-the-box, we can gladly investigate and fix it.
If this is the case, please provide complete and full steps to reproduce the problem from scratch, including a screenshot of every wizard page and every settings page involved in the repro. See our problem reporting instructions for more details.
Hi,
Just wanted to point out that this is outside the scope of the VisualGDB support. You are welcome to ask for advice from other users, however we won’t be able offer any help with this issue.
Please feel free to contact Espressif, or post on the ESP32 forums for all questions about the internals of ESP-IDF or the ESP32 Arduino core.
We will move further out-of-scope inquiries on the topic into this thread to avoid duplication.
Hi,
This is by design. The project you are trying to build contains an error and VisualGDB displays it. Please make sure you can build the project outside VisualGDB first, and you will be able to build it with VisualGDB as well.
You can find various tutorials on many different setups on the following page: https://visualgdb.com/tutorials/
That said, we publish our tutorials to show how to use various VisualGDB functionality in complex real-world scenarios, so that our users would know how to efficiently automate similar tasks with the demonstrated VisualGDB features. Many tutorials involve external components maintained by other vendors (e.g. the ESP32 Arduino core) and we are not able to take over the maintenance and troubleshooting of these components, or guarantee that every version of these external components will always work flawlessly and will be 100% compatible with other components. If you encounter errors in code that is not maintained by us, please consider containing the maintainer of the code (e.g. Espressif) for help.
This can be caused by the differences in how STM32CubeIDE and VisualGDB handle OpenOCD scripts.
STM32CubeIDE generates a per-device OpenOCD script that sets various variables and includes one of the regular scripts (e.g. stm32h7x.cfg). VisualGDB instead allows overriding these variables via command line (it automatically shows GUI for supported variables) and then includes one of the regular scripts directly via the “-f” argument. This works well for the devices we tested, however might miss some undocumented variables that could be set by STM32CubeIDE for your device.
The easiest way to get everything working would be to copy the OpenOCD script generated by STM32CubeIDE into your project directory and reference it from the OpenOCD settings. You can also try reviewing its contents and comparing it with the setup when you select one of the scripts via VisualGDB GUI. If there is any obvious difference, we might be able to add a GUI setting accommodating it.
Hi,
Thanks, indeed the ST fork of OpenOCD would not appear for STM32CubeMX-based projects. We have fixed it in this build: VisualGDB-5.6.1.4114.msi
You would also need to delete and re-download the ST fork of OpenOCD via Tools->Manage VisualGDB Packages.
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.
