Forum Replies Created
-
Posts
-
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.
Yes, as long as the amount of activations is within the fair use limits, we can handle it for you even if support has expired. Please contact our support with your key information and we will get back to you shortly.
Hi,
This looks like some device-specific issue. Please try creating a project with Android Studio and make sure it can be installed on the device. Then, try importing it into VisualGDB as shown in this tutorial: https://visualgdb.com/tutorials/android/cmake/
Sorry, we don’t have any ideas why the Kendryte OpenOCD port would not work with a specific Kendryte chip. We do our best to integrate the tools from different vendors with our products, but sometimes the underlying tools just won’t work.
Strange, could you please double-check the Tools->Options->VisualGDB->Advanced Build->Show build output from VisualGDB projects setting?
Is it still set to “Regular VS Build Output Window”? Does setting Tools->Options->VisualGDB->General->GUI->Build Results Window Stickiness to 0 solve it?
Hi,
You can do that with a custom debug method definition. The easiest way to do it would be to select PyOCD in the debug settings, and then locate and copy the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.pyocd directory under a different name. You can then edit the EDP.XML file inside the new method directory to change the startup commands, stub location, or even define extra configuration properties.
