[support]

Hi,

For any questions about specific orders, licenses and payment issues, please contact our support directly.

[support]

Hi,

According to our records, this order has been refunded and the license is no longer active.

[support]

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.

[support]

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.

[support]

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).

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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?

[support]

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.

[support]

No worries. As the problem did not happen when building the project manually per Pico SDK instructions, there was a chance that it could be a VisualGDB bug, so we investigated it further.

As the underlying bug ended up rather trivial and could affect other VisualGDB users (we still believe that disabling optimization for debug builds does more good than harm), we reported it to the Pico SDK maintainers.

[support]

We will be happy to point out the differences between different RTOSes and explain the level of integration offered for each one. However, it looks like your trial period has expired. Please let us know the email associated with your license key so that we could check your support status and we will be happy to provide further clarifications.

[support]

Thanks, we have reproduced the problem and found the root cause. In order to improve debugging experience, VisualGDB configures the Pico SDK to completely disable optimization in debug builds by passing the PICO_DEOPTIMIZED_DEBUG=1 parameter to CMake.

This disables substitution of inline functions and triggers a bug in the Pico SDK.

We have created a Github issue describing the bug and a suggested fix here: https://github.com/raspberrypi/pico-sdk/issues/371. Feel free to upvote it.

As a workaround, please consider patching the address_mapped.h file per our description, or disabling the VisualGDB Project Properties -> Raspberry Pi Project -> Raspberry Pi SDK -> Disable optimization for debug builds setting.

[Author]

Posts