[support]

Hi,

The unknown code address could be an interrupt handler from the prebuilt esp8266 libraries. Generally, it is possible to do the proper stepping given one hardware breakpoint, however the corresponding part of the the xtensa gdb is very buggy and often gets confused. The reason why this functionality works out-of-the-box for ARM devices is that ARM has been around for decades, so the underlying tools have matured to handle common scenarios flawlessly. ESP8266 is based on a much less popular CPU architecture, the corresponding low-level tools are less developed and behave more sporadically.

Our primary goal with ESP8266/ESP32 is to keep VisualGDB affordable to the hobbyist community, that are the primary users of those devices, so we don’t go very deep in fixing the toolchain issues, instead providing a user-friendly layer on top of the tools. The unfortunate disadvantage of this is that VisualGDB inherits many of the ESP8266 gdb bugs until Espressif fixes the underlying tools.

We are also considering a crowdfinding campaign to fix the most annoying issues in the low-level open-source tools (keeping the fixes open-source of course), but currently it is hard to provide any specific timeframe estimates on that.

[support]

Hi,

If your code explicitly manipulates CPU sleep states and power-related registers, you may need the “connect under reset” option as described in the tutorial. If you are not sure, we would suggest editing the OpenOCD scripts as described in the tutorial and checking if it solves the problem.

[support]

Hi,

Please try using the “Export to CSV” button in the Live Variables tool window.

[support]

Hi,

We actually have a detailed tutorial showing how to configure an equivalent of “Connect under reset” with VisualGDB: https://visualgdb.com/tutorials/stm32/sleep/

Let us know if it does not help.

[support]

Hi,

Normally VisualGDB shows the license information only in About window and in the GDB Session window, but not in a separate popup.

If your license shows the name of your company’s purchasing person instead of the actual user, simply contact our support and we will update this.

[support]

Hi,

This looks like a bug in the STM32 device table on their site (http://www.st.com/en/microcontrollers/stm32l4-series.html?querycriteria=productId=SS1580). Once they fix it, our next BSP will use the updated data.

The wrong value should only affect the device selector, but not the actual linker scripts, so you can simply ignore it.

[support]

Hi,

The problem is that ReSharper uses its own IntelliSense engine that does not handle the GCC language extensions. So our best advice would be to use our Clang-based IntelliSense engine that is fully aware of those extensions and also offers advanced refactoring functionality.

[support]

Hi,

You can download the previous versions of the BSPs here:  http://visualgdb.com/hwsupport/

Then simply install them via “Install a package from file”

[support]

Hi,

CC3220S is a different chip from CC3200 and is not supported by us directly (it looks to be much less popular than CC3200, so we currently don’t have plans for supporting it directly).

Please follow our legacy device tutorial to setup a project manually.

[support]

Hi,

The Edison toolchain might require an explicit “–sysroot” argument. Please try specifying it via additional command line flags for both compiler and linker (see the toolchain documentation or included examples for the correct sysroot value).

[support]

Hi,

Thanks, according to the stack trace, VisualGDB was stuck waiting for a response from the Linux machine while trying to close an SSH connection. If you run into this problem again, please try updating your SSH server or try a different network connection (e.g. this could be caused by packet loss).

[support]

Hi,

Unfortunately, VS registry can get corrupt in many different ways, so one specific instance won’t be of much help. You could try getting a diff of the .reg files from the old and the new key and quickly check if there is anything obviously wrong there (or send the diff to us if the amount of changes is relatively small), but unless it gets obvious from the first glance, investigating it further won’t be worth the time.

[support]

Hi,

Please double-check that the .S file is actually compiled with the -ggdb switch (so that gdb can get debugging information for it). If it does not help, please try repairing breakpoints via VisualGDB breakpoint repair button in the GDB Session window.

[support]

Hi,

Please try referencing the “config” variable from your code so that the linker does not discard it as unused. Alternatively you can try using the KEEP() statement in the linker script file and attribute__((used)) in your code.

If it does not help, try enabling the map file generation via Linker Settings and check the map file to see where exactly the linker placed your variable.

[support]

Hi,

The behavior you are describing would make 100% sense if the sleep loop was infinite (the optimizer would eliminate the rest of the code), but if it’s limited to 100 iterations, it should not happen.

Please try pressing the ‘diagnose breakpoint problems’ button in the GDB Session window to automatically diagnose path mapping issues.

[Author]

Posts