Forum Replies Created
-
Posts
-
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.
Hi,
It looks like your support period has expired a while ago. Please kindly renew it here and we will be happy to point you to the relevant documentation.
OK, thanks for you patience. We have managed to reproduce the problem. I turns out, in some cases MSBuild would not invoke the logic responsible for updating VisualGDB’s floating license state, leading to an expiration of the temporary session key.
We have fixed the problem in the following build: VisualGDB-5.5.8.3774.msi
Sorry, the line looked a bit confusing due to the comment before code.
It’s generally hard to say what would cause this, as VisualGDB would simply pass the breakpoint commands to the underlying low-level tools and would not directly control which of the breakpoints get hit.
If the optimization level is already set to -O0, our best advice would be to try switching to the disassembly mode, and experimenting with setting breakpoints there.
Also the “pill” boards often come with the Chinese clones of the STM32 chips, that do often behave unpredictably. If the problem does not happen on the regular STM32 boards, it is very likely the glitch of the chip.
Hi,
This can be caused by optimization, or the way gcc handles debug symbols. Please make sure the optimization is set to -O0 (and not -Og). You can also try adding asm(“nop”) in the empty if() branch. If this changes the behavior, it is a side effect of the way gcc emits symbols for empty branches.
Hi,
If you are new to VisualGDB, please do allocate some time to go through the documentation and tutorials (e.g. unit testing tutorial). They do show the location of all the relevant settings (e.g. see the “Recovering from assertion failures” section) and will save you considerable time if you are planning a non-trivial setup.
