Forum Replies Created
-
AuthorPosts
-
September 4, 2020 at 06:24 in reply to: Unable to debug a Linux app after disabling serial console #28992
support
KeymasterHi,
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.
support
KeymasterHi,
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.
support
KeymasterThe 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.
support
KeymasterYes, 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.
support
KeymasterHi,
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/
support
KeymasterSorry, 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.
September 3, 2020 at 05:55 in reply to: Build errors after upgrading to VisualGDB 5.5 Preview 7 #28971support
KeymasterStrange, 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?
support
KeymasterHi,
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.
support
KeymasterHi,
No problem, please see the following page for detailed troubleshooting instructions: https://visualgdb.com/support/loadfail/
September 2, 2020 at 14:28 in reply to: Build errors after upgrading to VisualGDB 5.5 Preview 7 #28964support
KeymasterNo 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
support
KeymasterGenerally, 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.
September 2, 2020 at 06:32 in reply to: including startup_stm32*.c in project without absolute path #28962support
KeymasterThis is by design and comes from the VisualGDB general project structure. The VisualGDB startup file is functionally equivalent to the ST startup file and should work just fine.
support
KeymasterSorry, we don’t have an estimate yet. Feel free to follow us on Twitter to get notified about new tutorials.
support
KeymasterBased on our experiments, the Kendryte port of OpenOCD is extremely unreliable. You can find more details and possible workarounds in our Kendryte tutorial, or by contacting Kendryte for further help.
support
KeymasterHi,
Please see the following page for instructions on troubleshooting common OpenOCD issues: https://visualgdb.com/documentation/openocd/troubleshooting/
-
AuthorPosts