Forum Replies Created
-
Posts
-
Good to know it works. We are usually able to answer most inquiries within 24-48 hours (depending on the backlog).
Either way, if you encounter strange errors, we always advise searching our tutorials and documentation first. They contain detailed explanations for many common issues and can get you up and running faster than waiting for a support ticket to get through the queue.
Please see the following tutorials for examples on adding extra files to ESP-IDF and Arduino projects:
- https://visualgdb.com/tutorials/esp32/esp-idf/components/
- https://visualgdb.com/tutorials/arduino/libraries/
You can also add existing files directly to the project by right-clicking on it in Solution Explorer and selecting Add->Existing Item.
We do not limit the software you purchased in any way and you are welcome to troubleshoot the problem using our documentation. It provides detailed explanations on many topics, including troubleshooting instructions for common problems.
However, if you would like us to provide more detailed instructions, that would qualify as product support and hence we would kindly ask you to renew it.
Hi,
We are more than happy to provide detailed on-demand instructions and tutorials, as long as our customers cover the costs of doing that. In fact, many of the BSPs and tutorials for exotic devices and rare setups were created as paid customization projects and the companies using them are extremely happy, since they were able to bypass time-consuming troubleshooting and learning stage, and got directly to solving the their business problems.
We are simply not able to do it for free, as we receive a huge amount of project-specific inquiries, and a few minutes per inquiry would very quickly add up to a point where would not have any resources left for developing and maintaining our products.
Our regular product license includes support for issues with VisualGDB itself, because they scale. E.g. once we fixed the incorrect $(ToolchainDir) substitution you previously reported, the problem has been solved for all VisualGDB users. Unfortunately, this doesn’t work for project-specific issues, as there are numerous different setups and frameworks supported by VisualGDB, and detailed instructions for a relatively rare case will not be relevant to most of the users.
Please note that we are not able to provide project-specific instructions beyond our documentation and tutorials as, the only way for to do this would be to have an engineer do a detailed review of a specific project. The cost of doing that would very quickly exceed what we charge per VisualGDB license. Hence if we included this with our regular support, we would quickly come to a point where we would have to stop offering any kind of technical support, or raise our product prices more than 10x.
Instead, we offer technical support for reproducible VisualGDB issues and are happy to offer paid project-specific troubleshooting billed at an hourly rate. We are not able to do it for free, as we receive an overwhelming amount of project-specific inquiries and do not have any spare resources that could be allocated to handling them, sorry.
Hi,
It looks like your support period has expired. We will be happy to help you resolve this, however we would kindly ask you to renew your technical support first: https://sysprogs.com/splm/mykey
If you don’t mind patching the .vcxproj files manually and forgoing the VisualGDB GUI for configuring the device, you can reorganize your code as follows:
- Create a shared items project using the regular VC++ project wizard.
- Move the Device-Specific files from the main project to the shared items project.
- Move the definition of MCUPropertyListFile from the main .vcxproj file to the shared items project.
- Manually edit the MSBuild files to define multiple VisualGDB-based platforms (see this tutorial)
- Manually set a Condition tag on the Import statement in the main .vcxproj file that imports the shared project, so that it is imported for a specific platform only.
- Rename the .vgdbsettings files and explicitly update their names via VS Project Properties.
- Create a separate combination of the following items for each device you would like to target:
- A shared files project
- A renamed property list file
- Renamed debug + release .vgdbsettings files
This will allow having multiple platforms in the same .vcxproj file, however the VisualGDB GUI for configuring MCU parameters won’t work anymore (you can still use it on a separate project and then manually copy the updated property sheet file and references to the BSP-specific sources from it).
You can find more documentation on MSBuild property sheets and MSBuild-based project structure here:
- https://visualgdb.com/documentation/projects/msbuild/propertysheets/
- https://visualgdb.com/documentation/projects/msbuild/
- https://visualgdb.com/documentation/embedded/stm32/
Hi,
VisualGDB itself doesn’t provide any special tools for calculating checksums, however it should be relatively straight-forward to code a simple tool that would do that. You can use VisualGDB Project Properties -> Custom Build Steps page to invoke the custom tool that will patch the .bin file generated by VisualGDB.
Then you can convert the .bin file back to ELF as shown below:
arm-none-eabi-objcopy -I binary -O elf32-little --change-section-address .data=0x08000000 <file>.bin <file>-patched.elf
Note that the new ELF file will not contain any debugging symbols, so it should not replace the original ELF file. Instead, please add the following command to Additional GDB Startup Commands (before connecting to target);
exec-file <file>-patched.elf
This will make sure that VisualGDB uses the contents of <file>-patched.elf to program the FLASH memory, but still uses the regular ELF file to load the symbols.
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.
