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

[support]

Hi,

The STM32CubeMX tool indeed sometimes references non-existing sources or headers in the .gpdsc files. It appears to be a bug in the STM32CubeMX that affects some device/library combinations.

VisualGDB would normally skip the non-existing files automatically, as long as you are using the latest version (please try updating to VisuaLGDB 5.6 Beta 1 if you are not using it already).

Either way, patching the .gpdsc file and BSP.cmake should work just fine as well.

[support]

Based on what we could tell, the Azure RTOS integration has been moved out of Beta status, but is still somewhat experimental, only supporting a few select devices, and is not a part of the mainstream SDKs, requiring a separate downloadable package.

Until it is included in the regular SDKs, we would advise using the STM32CubeMX workflow together with the downloadable package you linked. As the project generation will be handled by the STM32CubeMX tool, there is no need for any special support for it on the VisualGDB side.

 

[support]

Hi,

The 20210407-0.10.0 version is based on the snapshot of the OpenOCD’s master branch from 2021-04-07 that does correspond to OpenOCD 0.11.0, so other than the older version number, it should be equivalent to 0.11.

Either way, we have released another package (20210503-0.11.0) based on the current git snapshot. Feel free to update to it.

If it still doesn’t contain support for the necessary devices, 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).

[support]

Hi,

The VisualGDB project templates come from the original devices SDKs provided by the device vendors. As soon as ST includes the Azure RTOS project templates into their SDKs, our BSP will include them as well.

[support]

No problem, we can investigate it further.

First of all, please try double-checking that uploading the .uf2 file generated by VisualGDB yields different results than uploading the .uf2 file generated manually. If not, the problem might be related to running the code under a debugger in general.

If the two .uf2 files behave differently, please double-check that they use the same version of the SDK. If not, the bug could be specific to the SDK version used by VisualGDB.

If the SDK is the same, please try extracting the configuration/build command lines used by VisualGDB (see this page) and comparing them with the CMake/Ninja command lines used when built manually. If there are any differences, please let us know and we will recheck it further.

You can also try comparing both ELF files (the one produced by VisualGDB and the one produced via manual build) via Memory Explorer, or simply attaching them here so that we could recheck for any clear differences.

[support]

Hi,

VisualGDB always sets the environment based on the project settings, so there no need to worry about installing more tools manually.

[support]

Hi,

This looks like an possible bug in the the Raspberry Pi SDK or example library, rather than a VisualGDB-specific issue. Please feel free to post this on the Raspberry Pi forums – perhaps other Raspberry Pi users have encountered the same issue.

That said, if you can confirm that the project works as expected when built manually and doesn’t work when built with VisualGDB, we can gladly investigate this further and make sure VisualGDB produces the same results as the manual build.

[Author]

Posts