Forum Replies Created
-
Posts
-
This happens because VisualGDB is trying to use the ARM debugging tools rather than RISC-V toolset. We will update VisualGDB to handle this properly once we get the board, and will show the necessary setup in the tutorial (given that the board has JTAG pins exposed).
Please follow this tutorial to diagnose the “undefined reference” errors: https://visualgdb.com/tutorials/linux/libraries/diagnosing/
Just wanted to share an update that we have added full support to the nRFConnect SDK to VisualGDB 5.5 Preview 6. You can find a detailed tutorial here: https://visualgdb.com/tutorials/arm/nrfconnect/nrf9160/
Hi,
We haven’t tested Maixduino with VisualGDB yet, so it’s hard to give any specific recommendations. We would advise trying both ways and see which one works the best.
That said, the Maixduino looks like a promising platform, so we have ordered one as well and will publish a tutorial in the next couple of weeks. Feel free to follow us on Twitter to get notified once the tutorial is available.
Hi,
Indeed, the VC++-based embedded projects only support one target per project. This happens because different targets would have different subsets of source files, and the Visual C++ project system doesn’t have a good way to deal with it (other than always including all files and setting the ‘exclude from build’ flag for each configuration).
That said, we have just added support for custom configurations and platforms to the Advanced CMake Project Subsystem (see the announcement) and will include support for creating CMake-based embedded projects (that will support multiple targets) in the final v5.5 release (around a month more), so you will be able to configure the multi-platform layout you described.
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.
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.
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.
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.
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.
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.
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.
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.
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.
