Forum Replies Created
-
Posts
-
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.
Hi,
No problem, please see the following page for detailed troubleshooting instructions: https://visualgdb.com/support/loadfail/
No problem, we have updated VisualGDB to not explicitly activate the advanced output window, if the build output is directed to the regular output window. Please try this build: VisualGDB-5.5.8.3779.msi
Generally, as it is a very rare scenario, VisualGDB will not have a direct support for it unless the problem starts affecting multiple users, sorry.
Since STM32CubeIDE also uses OpenOCD and GDB, you should be able to replicate the results you get there with VisualGDB, but that would require non-trivial research of the STM32CubeIDE internals. You would need to find the exact OpenOCD and GDB command lines, as well as the gdb startup commands. Unfortunately, we won’t be able to provide any STM32CubeIDE-specific instructions to obtain them, however if you do manage to obtain them, and get debugging to work by running gdb and OpenOCD manually, we can help you configure VisualGDB to replicate the same setup.
