Forum Replies Created
-
Posts
-
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.
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.
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).
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.
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.
Hi,
VisualGDB always sets the environment based on the project settings, so there no need to worry about installing more tools manually.
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.
Hi,
Zephyr OS i a rather niche OS compared to mainstream RTOSes like FreeRTOS or mbed+RTX, and involves non-trivial setup steps that differ from target to target and from version to version. Hence, we will not be supporting it directly besides the NRFConnect integration.
If you can get all the device-specific setup done and get your project to build manually, you can simply import it into VisualGDB as an existing CMake project and make sure the CMake environment used by VisualGDB matches the environment used by Zephyr (see this page). You will be able to build and debug the project just fine once it is imported.
If the thread layout of your Zephyr configuration is compatible with the one used by NRFConnect, VisualGDB will display them automatically. If not, you can patch our Zephyr thread plugin to handle the changes. Again, as the specifics differ from target to target, we will only officially support it as a part of the NRFConnect SDK integration.
Hi,
You can achieve this by setting Tools->Options->Text Editor->C/C++(VisualGDB)->Other->Max. change-driven tags to 0. See this page for a comprehensive list of VisualGDB settings.
Hi,
Good to know it works. Overriding environment variables used by VS could indeed lead to strange behavior, so restoring the default values is always a good idea.
No problem, we can walk you through the various settings and try to suggest a few workarounds, however we would kindly ask you renew your technical support first, as it has expired a while ago.
Hi,
The VisualGDB’s IntelliSense engine internally uses Clang 6.0. Hence if you are relying on a setting that was added in a newer version, it will not work. We will update the Clang version used by our engine in one of the next VisualGDB releases.
Please make sure you can build the project outside VisualGDB first. Once you get it to build outside VisualGDB, please try comparing the command line that results in a successful build with the command line used by VisualGDB (you can find it out in the VisualGDB Build window as shown here).
If you need help locating the settings that will adjust the VisualGDB command line to match the manual build command line, please let us know more details about both command lines and we will be happy to point out the relevant settings.
Hi,
If the imported project doesn’t compile, we would advise first getting it to successfully build outside VisualGDB, and then proceeding with import.
If you are able to build a project outside VisualGDB, but it doesn’t build with VisualGDB, we can help you configure VisualGDB to replicate the manual build results. If the project doesn’t build outside of VisualGDB either, importing it into VisualGDB will not automatically solve the build problems.
