Forum Replies Created
-
Posts
-
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.
This 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.
Sorry, we don’t have an estimate yet. Feel free to follow us on Twitter to get notified about new tutorials.
Based 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.
Hi,
Please see the following page for instructions on troubleshooting common OpenOCD issues: https://visualgdb.com/documentation/openocd/troubleshooting/
Hi,
Most likely, the STM32CubeIDE is running some additional commands during the gdb startup, while VisualGDB doesn’t.
The easiest way to find it out would be to enable gdb tracing in Eclipse and turn on diagnostic GDB logs in VisualGDB. Then, simply locate the startup commands issued by the CubeIDE that could be related to updating these registers, and add them to VisualGDB Project Properties -> Additional Startup Commands.
Thanks for the suggestion. We have it on our radar and will publish it together with other tutorials covering the new Embedded CMake subsystem.
Sorry, not sure what you meant. If you have tried following the tutorial and VisualGDB is not working as expected, please share the screenshots of all the steps you take on your side (including all GUI settings) and the output you get (including any missing windows or differences compared to the tutorial), and we will try to check what is going on.
