Forum Replies Created
-
Posts
-
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.
Hi,
Good to know it works. It is always good idea to install the latest VisualGDB updates, toolchains and packages.
Hi,
Sorry, we don’t have a ready-to-use visualizer of unordered_map yet. It is on the roadmap, however it’s hard to give any time estimates now. As a workaround, please consider creating one manually as shown in this tutorial.
Hi,
It looks like you are using a toolchain that outputs dependency files in a format incompatible with Ninja. Please try using our latest ARM toolchain instead and it will work out-of-the-box.
Hi,
We have rechecked the logic for detecting toolchain settings on the latest GNU ARM toolchain v10.2.1 and it worked as expected. It is hard to say what is causing the behavior your described, however it replacing the file manually works, we would simply advise doing so until we release a fully tested pre-packaged toolchain based on the latest GCC.
