[support]

Hi,

Normally, the partitions would be handled by the ESP-IDF build scripts directly and VisualGDB would pick up the FLASH images reported by them. So as long as the FLASH gets progammed when you run “make flash”, it should get programmed with VisualGDB as well. If this doesn’t happen, please let us know if you are using GNU Make or CMake and we can show you how to troubleshoot this.

You can also use the VisualGDB Project Properties -> Debug Settings -> Additional FLASH Resources settings to explicitly tell VisualGDB to program a specific image at a specific address.

[support]

Hi,

The build error happens because VisualGDB incorrectly used the $(ToolchainDir) syntax that is not supported by ESP-IDF projects. We have fixed it in the following build: VisualGDB-5.5.6.3657.msi.

That said, trying to use header discovery to reference missing ESP-IDF functionality will likely not work because ESP-IDF projects use their own system of components and configuration entries. You can find extensive documentation on ESP-IDF here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/.

Please note that ESP-IDF is a huge and very complicated development framework and we advise taking time to go through various samples included with it to make sure you fully understand how it works. While VisualGDB can automate many routine tasks along that way, it will not replace the understanding of the underlying tools and technologies. If you would like to get personalized training with ESP-IDF or other frameworks, please feel free to contact our sales to get a quote.

[support]

Hi,

Good to know it works. For your reference, we have recently posted very detailed instructions on troubleshooting common ESP-IDF problems here: https://visualgdb.com/documentation/espidf/#troubleshooting

Feel free to look through them if you encounter further issues.

[support]

Hi,

Indeed, the regular Visual Studio’s Output window is read-only. You can find various VisualGDB-specific windows that simplify the debug workflow under the Debug->Windows menu.

[support]

Hi,

Normally, #include_next<> should work. Please try following our IntelliSense diagnostics tutorial to see the exact options used by VisualGDB’s IntelliSense for the project and for clues why it may not work.

[support]

We have tried reproducing the problem with the following directory structure:

E:\projects\temp\Libs\2.cpp
E:\projects\temp\Libs\STM32\1.cpp
E:\projects\temp\Libs\sub\3.txt

It did get uploaded as expected (STM32 got excluded):

/tmp/xyz/2.cpp
/tmp/xyz/sub/3.txt

If you expect  different behavior, please let us know the exact full paths of files on the Windows machine that get uploaded despite being excluded and the full path of the solution file.

 

[support]

Hi,

This behavior happens because VisualGDB builds the target path template before it expands all variables (i.e. it would be internally defined as $(BuildDir)/../build/app1 and $(BuildDir) will get expanded later).

Normally, using the relative path syntax (“../build/app1”) should work. We have tested it with both GNU Make and Ninja and it worked as expected (the /mnt/hgfs/git/master/../build/app1 path does look awkward, but it should not cause any problems).

If it doesn’t work due to some project-specific tools, we can add a variable syntax that will resolve the “..” in paths (i.e. you would need to use something like $(TargetPath.fullpath)). Would that work for you?

Alternatively, please consider using the Advanced CMake Project Subsystem. It sets the $(TargetPath) variable based on the path reported by CMake, and that path is usually fully resolved.

[support]

Hi,

Normally, VisualGDB would try to inherit the regular C/C++ colors, however depending on the VS version and other installed plugins, this may not always work perfectly. The easiest way would be to simply change the color from “default” to anything you prefer via the Tools->Options window.

[support]

Sorry, we do not have any plans to support QML on the VisualGDB side.

We can help you configure QML for Raspberry Pi as a part of our consulting services. Please feel free to reach out to our sales if you would like to get a quote.

[support]

Hi,

Sorry, QML (Qt Quick) is based on a completely different technology stack, compared to the regular Qt projects, and is hence not supported by VisualGDB.

[support]

Hi,

VisualGDB indeed uses its own settings to control every aspect for formatting. You can find out a searchable list of settings on the following page: https://visualgdb.com/settings/. It is automatically updated when VisualGDB settings are changed. E.g. try searching for “auto-format” for a detailed list of settings that control when VisualGDB would format code.

[support]

Hi,

Our regular Raspberry Pi toolchain is compatible with Raspberry Pi 4. That said, please make sure you are using a compatible SD card image (see this page for details).

[support]

Thanks, the problem might be caused by incorrect encoding of some of the QuickSync settings.

Please try this build: VisualGDB-5.5.5.3629.msi (you would need to re-enter the excluded subfolders via VisualGDB Project Properties).

If it still doesn’t help, please attach the updated .vgdbsettings file.

 

[support]

No problem, we have updated VisualGDB to use UTC times for folders, similar to files: VisualGDB-5.5.5.3628.msi

[support]

Thanks for clarifying everything. We have pinpointed and fixed the problem in the following build: VisualGDB-5.5.5.3626.msi

[Author]

Posts