Forum Replies Created
-
Posts
-
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).
Sorry, we are not the vendor for the Kendryte OpenOCD port.
If you can manage to get it working by running OpenOCD manually, please let us know the command line that worked and we will help you configure VisualGDB to use it as well. If OpenOCD is not working with the specific chip outside VisualGDB, it will not work when using VisualGDB either.
Hi,
The exact mechanics of step-in vs step-over is handled by the gdb debugger and not by VisualGDB directly. If it’s not working as expected, our best advice would be to try updating your toolchain, or running gdb directly on the target, if you are using gdbserver.
Thanks for renewing your license. We will explain how VisualGDB handles this.
Please try locating the CanInvokeSemihostingCalls() function in DebuggerChecker.h and searching for all references to it. This function is invoked each time your program tries to write anything via the fast semihosting mechanism. It normally just checks the C_DEBUGEN bit to see if a debugger is attached.
The easiest way to troubleshoot it is to set a breakpoint in the function and try outputting anything via the printf() call (don’t forget to end the printed line with “\n” as otherwise it will get buffered). Does the CanInvokeSemihostingCalls() get invoked? Does it return true as expected when running under debugger?
The contents of the /tmp folder is normally deleted when you restart the target. That said, normally, just building the project again would re-upload the files to it.
You can also change the remote folder used to upload the files via VisualGDB Project Properties -> Linux Project.
This might still indicate the missing BSP. Please try creating a new project using the same MCU/toolchain from scratch. It will check all the necessary tools and should display more information in case anything is missing.
If it doesn’t help, please share the entire output from the regular build output window (View->Output) and from the VisualGDB Build window as well, and we will help you narrow it down.
OK, thanks for confirming this. We have updated the output window activation logic to prevent it from gaining focus unless it directly receives output. Please try this build: <old link>
Update: we have tweaked the logic a bit more to handle skipped projects better. Here is the updated build: VisualGDB-5.5.8.3784.msi
Thanks for the pointer. We will assess the popularity of the new Qt for microcontrollers framework and will consider supporting it directly.
Currently, VisualGDB supports Qt for Linux targets. You can find out the necessary setup steps in our Qt tutorials: https://visualgdb.com/w/tutorials/tag/qt/
Hi,
This looks like the temporary directory where the project was built got deleted after a restart. Please try rebuilding the project and you should be able to debug it again.
Hi,
Sorry for the confusion. Unlike the GCC toolchain where VisualGDB would download all the packages automatically, using the Keil toolchain relies on the Keil pack manager to install the necessary packs.
Normally, if you can create a basic project for the same device using the Keil IDE, VisualGDB will find the related files as well (please make sure you use VisualGDB 5.5 Preview 7). If not, please let us know where the Keil pack files are located (e.g. the GPIO HAL driver) and we will help you configure VisualGDB to discover them as well.
The exact answer depends on the project type you are using. You can find more information about different project types here: https://visualgdb.com/documentation/projects/overview/
Generally, ignoring the directories with the binary files and the .visualgdb directory should be sufficient (please update to VisualGDB 5.5 Preview 7, as earlier versions used several more temporary directories dependent on the project type).
If the documentation doesn’t clarify it for your project type, please let us know which one it is and we will update it.
