Forum Replies Created
-
Posts
-
Hi,
Please see the following pages:
No problem. It looks like the mbed cache on your machine could be corrupt. Please try deleting the %USERPROFILE%\.mbed folder with all contents.
If it doesn’t help, please try opening View->Other Windows->VisualGDB Diagnostics Console, and then run the wizard. The diagnostics console will show the command used by VisualGDB to clone the mbed repository. Please try running it manually in the Command Prompt window and check if it works as expected.
If it doesn’t help, please let us know the command recovered from the Diagnostics Console, as well as the result of running it manually, and we will help you get it running.
Hi,
Most likely, the program you are trying to debug is built without debugging symbols, hence gdb cannot set any breakpoints.
Although we don’t have a MinGW-specific tutorial for this, we do have a very detailed one showing how this works on Linux: https://visualgdb.com/tutorials/linux/symbols/
OK, we have added out-of-the-box support for MaixDuino to VisualGDB. Please make sure you update to v5.5 Preview 7 and then follow this tutorial: https://visualgdb.com/tutorials/arduino/maixduino/
Hi,
This looks like a generic Raspberry Pi question and not something VisualGDB-specific.
Please consider posting it on Stack Overflow or Raspberry Pi forums instead.
Hi,
This looks like either a broken Python environment, or a 3rd-party tool (e.g. antivirus) is interfering with mbed.
Please try installing the latest VisualGDB 5.5 Preview. Then please try resetting your Python environment as shown here: https://visualgdb.com/support/mbedpython/
Hi,
Most likely, this happens because the project is referencing entire source directories instead of specific files, and we have not fully tested this case yet.
Please try this build: VisualGDB-5.5.6.3661.msi. It should be able to handle the directory-level references correctly.
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.
