[support]

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.

[support]

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

[support]

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:

1. Create a shared items project using the regular VC++ project wizard.
2. Move the Device-Specific files from the main project to the shared items project.
3. Move the definition of MCUPropertyListFile from the main .vcxproj file to the shared items project.
4. Manually edit the MSBuild files to define multiple VisualGDB-based platforms (see this tutorial)
5. 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.
6. Rename the .vgdbsettings files and explicitly update their names via VS Project Properties.
7. 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/

 

[support]

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.

[support]

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).

[support]

Please follow this tutorial to diagnose the “undefined reference” errors: https://visualgdb.com/tutorials/linux/libraries/diagnosing/

[support]

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/

[support]

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.

[support]

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.

[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.

 

[Author]

Posts