Forum Replies Created
-
Posts
-
Please see the following page for a detailed overview of various settings for MSBuild projects: https://visualgdb.com/documentation/projects/msbuild/
Hi,
Visual Studio has a similar concept. Solutions (.sln files) can include multiple projects (.vcxproj files), one for every target.
You can also consider using the new Embedded CMake Project Subsystem (requires VisualGDB 5.5 RC1) that supports multiple targets within the same project, so you won’t need to setup the toolchain/debugging settings multiple times.
Sorry, we could not find any licenses associated with your company domain name.
If you know your previous license key, please forward it to our support and we will link it to your forum profile.
Edit: thanks for sending us your key information. We have linked it to your profile. Please use this link to renew your support and we will help you troubleshoot this.
Hi,
Please let us know the email associated with your license key so that we could check your support status.
Based on what we could tell from the Particle site, their main focus is on the cloud platform. I.e. providing higher-level APIs for centrally managing and communicating to the IoT devices. The on-device debugging (the only part where VisualGDB would come into play) isn’t used very often.
Also the Particle SDK is relatively complex, so properly supporting it by VisualGDB, similar to the nRFConnect SDK would only make sense if it had a much larger use base.
Our best advice currently would be to import the project into VisualGDB as an external Make-based project. You will still be able to build and debug it, although the Makefile contents won’t be automatically reflected in Solution Explorer the way it’s done for nRFConnect.
Hi,
This is supported starting from the new VisualGDB 5.5 RC1 using the Embedded CMake Project Subsystem. You can now define arbitrary platforms/configurations with arbitrary CMake variables and use the if() syntax in CMakeLists.txt to conditionally enable/disable various features. You can also have multiple targets per project (e.g. one unit test target and one regular application, both referencing a common library).
We will be publishing a few tutorials on the new Embedded CMake Project subsystem soon, explaining the new layout in details.
No problem, we can point out a setting that will allow replicating this behavior, however we would kindly ask you to confirm your support status first.
Please let us know the email associated with your license key so that we could link it to your profile. If you are using a trial, please update your forum profile to use your company email.
Looks like you are trying to import an Android Studio project without any native files. Please double-check that you have created the C/C++ sources with Android Studio, and that the original project builds and works before you try importing it into VisualGDB.
Thanks for sharing this. We have moved this post to a separate thread to make it easier for others to discover it.
The protect and mbatch commands come from the regular RISC-V debug logic and can be safely ignored for Kendryte devices.
BTW, thanks for sharing the solution you discovered with the JTAG pins. We have moved it to a separate thread to make it easier for other users to find it.
Please let us know the email associated with your license key so that we could check your support status. If you are using a trial, please update your forum profile to use your company email.
Hi,
This looks like a RaspberryPi issue and not something specific to VisualGDB. Please consider asking on the Raspberry Pi forums instead.
If the library you are using requires a different environment variable, please let us know more details and we will help you configure VisualGDB to set it.
Hi,
Looks like you are trying to use the GDB simulator that does not support your device. Generally, the built-in simulator is not usable for ARM targets and can only be used to verify that gdb is able to load the debugging symbols.
Please consider using one of the supported debug methods instead.
VisualGDB supports most Atmel devices via the Atmel START integration. If the device is supported by Atmel START, you can target it with VisualGDB as shown here.
If not, please follow our legacy device tutorial to setup a project.
You can also import an existing project and reuse the existing Makefile. As long as J-Link supports the device, you will be able to debug it with VisualGDB.
No problem. First of all, please try testing the session manually by running the following command from the Command Prompt window:
c:\sysgcc\kendryte\bin\riscv64-unknown-elf-gdb.exe <full path to the ELF file>
The path to ELF file is typically <project directory>\VisualGDB\Debug\<project name without extension>
Then, run the following commands in the gdb session:
target remote :3333 load break main continue
If this results in a usable debug session (i.e. breakpoint in main() hits), you can configure VisualGDB to replicate this as shown below:
Once the manual mode works, feel free to adjust the command line used by VisualGDB to match it:
If you can point specific command line differences that resolve the problem on your side, we will be happy to update VisualGDB to automatically apply them. Also if you can confirm that the OpenOCD from kendryte works, while the executable shipped VisualGDB doesn’t, we can double-check it on our side (it’s built from the official Kendryte sources, so it should be equivalent).
