[support]

Hi,

This may happen if your distro installs Qt5 in a location that VisualGDB cannot locate. Could you please try running “which qtchooser” from the command line and check if it is located properly?

[support]

Hi,

You might be using assembly files that are intended for a different compiler (e.g. Keil or IAR). Unfortunately unlike C/C++, the syntax of the assembly files is totally different for the different compilers (mainly when it comes to special directives, declaring symbols, etc) and they are not compatible with each other. Please double-check that your codebase contains a version of the assembly files that is compatible with GCC.

[support]

Hi,

This is expected if you are debugging optimized code (the mapping between source lines and the actual instructions is very inaccurate then).

If you can reproduce this in the unoptimized code, please provide us more details so that we could look into this:

1. A snippet from your source file with the line numbers
2. A snippet from the gdb log (or the ‘all gdb interaction’ mode of the GDB Session window) showing the commands and gdb responses that are executed in response to using the “Set next statement” command. This should explain what is going on.

[support]

Hi,

Please try enabling verbose mode for the linker via VS Project Properties -> Linker -> Advanced. This should produce a massive debug output showing ALL the libraries checked by the linker. If librtc.a is on the list, but the problem still occurs, please try running the <target>-nm tool on the library to get a list of all symbols in it and double-check that this version of the library actually contains that symbol.

[support]

Normally this should not be related. Let us know if the problem persists after fixing the sysroot synchronization.

[support]

Hi,

Normally tar should skip the inaccessible files and handle the rest, so the rest of the files should be synchronized properly (unless you see clues to the opposite, e.g. if the sync stops before the progress bar reaches the end).

[support]

Hi,

If you don’t want to add the linker script to Solution Explorer, you don’t need to modify template.xml at all. Just add the file in the archive and VisualGDB will extract it when it creates the project.

Regarding the warnings, we might be able to help if you could send us screenshots of your Solution Explorer, your VisualGDB Project Properties specifying the linker script and the warning. If you don’t want to upload them to an image hosting, you can simply send them to us via our support interface.

[support]

Hi,

VisualGDB supports both STM32CubeMX and mbed. Please refer to the following tutorials

• https://visualgdb.com/tutorials/arm/stm32/cube/
• http://visualgdb.com/w/tutorials/tag/mbed/

[support]

Hi,

We do have a tutorial on that already: https://visualgdb.com/tutorials/arm/stm32/cube/

[support]

Hi,

Looks like your cross-toolchain might be corrupt. Please try reinstalling it.

[support]

Hi,

Please select the View->Output command in Visual Studio just as the error suggests and you should be able to see more details about the error. Most likely you have 2 instances of the system file, so removing the reference to one of them via VisualGDB Project Properties -> Embedded Frameworks should resolve the problem.

[support]

Hi,

This is actually very straight-forward. A VisualGDB project template is just a ZIP file containing template.xml with various project information and other files that will be simply copied to the project folder. So you can simply change the template file extension to .zip and add any extra contents there using 7-Zip or any other tool.

The behavior you described with the warnings looks like a bug, so if you find it annoying, feel free to provide more steps and we will fix it.

[support]

Hi,

Based on our experience, most likely this won’t work. As we don’t have any insight in the closed-source parts of the ESP8266 libraries, unfortunately we cannot offer much help here. Please consider asking on the Espressif forums.

[support]

Hi,

Thanks for the suggestions. We have considered making per-use trial, but that would mean that VisualGDB would have to re-activate on each start and that would make it much more inconvenient. If you did not have enough time to try out VisualGDB, you can always contact our support, explain your situation and we will give you a trial extension.

Regarding the academic pricing, most of the VisualGDB price comes from the support we provide with the product. For a complex IDE plugin like VisualGDB there are much more things that can go wrong compared to a JTAG debugger, so we need to reflect this in the license price and terms in order to be able to provide support. We could offer an academic license with no technical support, however that would unfortunately upset the academic users, as they would still sometimes need help resolving occasional issues just like regular users.

Hence the only advice we can give if you find VisualGDB too expensive is to try free tools like Eclipse. Our toolchains will still work with them, although the integration won’t be seamless and you would not be covered by our technical support, but you will still get the basic debug functionality that may be sufficient if you don’t use them regularly.

[support]

Hi,

Thanks for the video. This is totally expected. In order to do reliable stepping, gdb needs 2 mechanisms:

1. To be able to step one instruction at a time
2. Once it steps into a function, it needs to set a breakpoint on either the first code line of that function (for stepping into) or on the first line after the calling line (for stepping over).

On ESP8266 both mechanisms don’t work reliably:

1. Stepping instruction-by-instruction often triggers interrupts and gdb does not know how to step out of them
2. ESP8266 supports only 1 hardware breakpoint at a time, so if you already have one breakpoint in your code, gdb cannot set the temporary breakpoint as described above.

Additionally to that, gdb does not know how to reliably unwind the call stack on ESP8266, so if the target starts running some pre-built library code from Espressif, you see the ‘frame not in module’ message and don’t get a meaningful call stack.

These issues don’t happen with ARM devices because the ARM platform is very old and these problems were solved long ago. So for ARM devices, VisualGDB relies on the free tools like gdb to provide basic functionality (like stepping) and builds advanced features (like real-time watch) on top of them. For ESP8266/ESP32 there are no reliable low-level debugging tools and making them on our side would drive the VisualGDB price sky high (you would probably not want to pay $5K to debug a $2 chip), so unfortunately VisualGDB has to depend on the unreliable open-source tools that may be eventually fixed by the chip vendor. Hence <3$ for an IoT device is indeed compelling, however unfortunately you end up paying with spending several times more time to accomplish the same basic results.

We may eventually consider creating a list of the low-level tool issues and launching a crowdfunding campaign to fix them in the free tools, but it is hard to say how successful this would turn out.

We hope this explains it and sorry for the inconvenience caused by this.

[Author]

Posts