[support]

Hi,

Sorry for the delay. We have investigated this and it turns out NRFConnect 2.4+ requires a newer version of Python (we tested 3.11.5 and it worked). However, older NRFConnect versions, and some other frameworks used by VisualGDB are not compatible with Python 3.11 and require older versions (3.8 works).

We have updated VisualGDB to keep separate track of several Python installations and pick them based on the project type and the SDK version.

Please try installing this build [VisualGDB-6.0.2.4929.msi] and updating the package catalog via Tools->VisualGDB->Manage VisualGDB Packages->Online. It should fetch the correct package definitions and pick the correct Python package compatible with the NRFConnect version you are using.

[support]

Hi,

We are not aware of any known problems that would cause this. A good starting point would be to try reproducing the problem on a clean project created from scratch. If you can reproduce it there, please share the repro steps that we could follow in order to reproduce the problem on our side.

If not, please try comparing the broken project files against the working one – the difference is likely caused by some setting or something particular about the project structure.

 

[support]

Hi,

OK, we have investigated the issue with MSBuild projects. Turns out, it was a combination of the Visual Studio bug we reported in May, and a change in the STM32IDE project structure, that referenced the headers in a different way, that interfered with one of the workarounds used for older projects.

We have fixed it in this build: VisualGDB-6.0.2.4922.msi

With CMake, VisualGDB would normally group the source files by their physical paths, hence the source/header filters would indeed be linked to each other. If you wish, you can disable the splitting into sources/headers entirely, or disable grouping by paths and group by virtual folders instead (similar to MSBuild). See this page for more details.

In general, CMake projects support multiple targets (applications/libraries) within the same project. If you are importing a large external library with a non-trivial folder structure, we would advise putting it into a separate static library (see this tutorial). It will appear under a separate node in Solution Explorer (side-by-side with the application node, but within the CMake project node). If you have multiple such libraries, you can organize them arbitrarily by creating virtual target folders (target grouping is separate from source file grouping, so you can group targets by their function, and keep path-based grouping for files).

The best of organizing the code this way is that the library-specific settings will be stored in the library’s CMakeLists.txt file, separate from the rest of the project. E.g. if the library has some public include directories and expects certain preprocessor macros, you will only need to specify it once, and can then reference that library from any other embedded project, and VisualGDB will automatically combine the project-level settings (e.g. target device) with library-level settings (which sources to build and which include directories to use).

[support]

Hi,

This one is a bit hard to tell. The error message mentions converting QFile to QIODevice, but the code doesn’t look like it’s doing anything similar.

Please try simplifying the repro example until you can narrow down a specific missed part, i.e.:

1. Try closing the project, deleting the .visualgdb directory, and opening it again. This will clear all IntelliSense caches.
2. Remove all code after the error. Ensure the problem persists. Check if there are other errors listed in the Errors window that could make more sense (e.g. some declaration or header file missing).
3. Try moving the error into a separate .cpp file with a minimum set of includes and just 1 function inside the file itself. If the problem no longer reproduces, it was triggered by some include file, or another function above the error in the original source file. Moving it around the source file should help locate the part that causes the issues.
4. If the problem still persists, try breaking down the expression. E.g. does just calling “styleFile.readAll()” trigger the IntelliSense error? If yes, how is readAll() declared? Does calling other methods declared nearby also trigger IntelliSense errors?

[support]

Hi,

This should not normally happen, however it’s hard to determine the exact cause of it from the screenshot. Normally, we would advise using Advanced CMake – it is fully controlled by VisualGDB and should work better in most cases.

If you specifically would like to use MSBuild and it’s not working, feel free to attach the sample project that you are importing, and we can recheck if we can reproduce the issue.

[support]

Hi,

This looks like a legacy CMake project that is not fully compatible with Qt5. Please turn on the “Use the Advanced CMake Project Subsystem” checkbox on the very first screenshot and it should work just fine.

[support]

Hi,

It looks like you specified both command and arguments together:

<Command>cmd /c "echo test"</Command>

Please use this syntax instead:

<Command>cmd</Command>
<Arguments>/c "echo test"</Arguments>

If you are using the VisualGDB Project Properties window, simply put the /c “echo test” part in the Arguments field.

[support]

Hi,

Following the tutorials should normally work as expected, as long as you follow all the steps correctly. Strange errors are usually caused by changing some settings to unexpected values, and unfortunately, it is practically impossible for us to suggest anything meaningful without seeing what exact settings you are changing.

Please try following the tutorial again, taking screenshots of each step. If the problem persists, please attach the screenshots allowing us to reproduce the same steps on our side, and we will try to suggest what could be causing it.

[support]

Hi,

Sorry, there’s not much we can suggest without a precise description of the problem as the diagnostic log doesn’t show anything out of the ordinary.

Our best advice would be to narrow down a specific function that is not working, reproduce the issue on a clean project and describe the desired/observed behavior along with a screenshot demonstrating it.

[support]

Hi,

Most likely, you are using a toolchain that is not compatible with your SD card image. Please try using a clean SD card image that matches your toolchain (see this page).

[support]

Hi,

Advanced CMake projects can group targets and sources in numerous ways configurable via VS project properties for the top-level project node (see this page). The default behavior is grouping by types and paths. However, if you start adding virtual folders on either target level or project level, it stops grouping them by physical paths and uses virtual folders instead.

As long as you don’t have any virtual folders defined and have not disabled grouping by physical path, it should work just fine. If not, please share a screenshot of your Solution Explorer, grouping settings from the VS Project Properties, and let us know the actual physical paths of the underlying objects.

[support]

Hi,

OK, we have reviewed our tutorials and indeed found a few confusing things. The most confusing part is that the older tutorials are showing the GNU Make build system and don’t show many features introduced later. We created a list of the most outdated tutorials and started updating them. So far, we have updated these tutorials:

• Developing firmware for EFM32 devices – showed the Advanced CMake workflow and the new Live Watch GUI.
• Using Visual Studio to develop Linux Apps – showed MSBuild instead of GNU Make and explained the differences between MSBuild and CMake.
• Developing a Raspberry Pi app with Visual Studio – showed MSBuild instead of GNU Make and the new Code Jumps GUI.
• Adding External Memories to Embedded projects – showed the new OpenOCD configuration GUI and the new Memory Explorer.
• Developing OpenOCD FLASH drivers for External Memories – showed the improved CMake workflow (instead of GNU Make) and the use of Software Tracing to record the issued QSPI commands.
• Using WiringPi library with Raspberry PI cross-compiler – showed MSBuild instead of GNU Make and gave examples on using automatic header file discovery and library discovery.

We will be updating more tutorials to show features like the new Software Tracing, and will also remove references to GNU Make that has been superseded by CMake.

As for VS Code, it follows somewhat different design principles. Instead of providing GUI for many repetitive tasks, it forces you to change many things manually by editing JSON files. On one hand, it is less productive because it involves more repetitive work. On the other hand, that extra work makes it harder to accidentally change the wrong setting.

VisualGDB is built around a different philosophy – it provides powerful tools for common tasks, but needs more attention when using them. A fairly characteristic example would be the Header Discovery that we showed in the updated wiringPi tutorial. Instead of manually finding the header file, manually computing the relative path, and manually finding and patching the correct CMakeLists.txt file, you can let VisualGDB find all these things for you, review them and commit everything with a few clicks. But if you end up referencing a wrong directory (e.g. for a different target) and then attempt fixing it by referencing several other wrong directories, it would break the project to the point where it’s impossible to tell what’s going on anymore.

We could theoretically try to reduce damage from changing incorrect settings on our side by maintaining a history of what was changed and having an undo button for settings, but it is harder that it seems. Some options (like the configurations/platforms mentioned earlier here) are controlled by the VS directly and hare hard to monitor on our side. Also, the majority of unrecoverable projects are caused by changing something very unexpected and unique (e.g. overwriting a toolchain definition while attempting to fix another issue for another project). The good news is that you can avoid most of such quirks by using source control (or at least, frequent backups) and taking notes when you change something globally (like overwriting global files).

Either way, if you decide to give VisualGDB another try, feel free to get back to us. We can extend your license by the amount of months you skipped. We still can’t promise to fix broken projects without having the repro steps, but we will assign a higher priority to updating the old tutorials and will make sure they match the current GUI.

[support]

Hi,

Thanks for the stack trace. The crash actually happens inside the Visual Studio’s own language service assembly that implements helper functions for IntelliSense back-ends. It is hard to say what exactly triggers it, but AccessViolationException typically indicates corrupt DLLs somewhere.

Doing a fresh complete reinstall of VS should normally fix it.

 

[support]

Hi,

This is a tricky one.  In our experience, the Visual Studio color storage is prone to sometimes resetting/mixing up colors. Normally, VisualGDB can automatically detect it and reset the cache, but it could be that the One Dark Pro uses some other workaround that interferes with it.

Our best advice would be to try the regular VS dark color theme, and tweaking it to match the colors from One Dark Pro.

[support]

Hi,

Thanks for pointing this out. The new Gecko SDK indeed provided its own implementation of _sbrk() that was not fully compatible with the VisualGDB-generated linker scripts.

Since VisualGDB provides its own implementation, it is not really needed. We have updated the BSP removing it. Feel free to re-download it via Tools->VisualGDB->Manage VisualGDB Packages.

[Author]

Posts