[support]

Hi,

Just to double-check, are you using the latest esp32-gcc5.2.0.exe toolchain? A recent update to the ESP-IDF was interfering with the FLASH programming and it was only fixed in the 5.2.0 toolchain.

[support]

Hi,

The _estack message can be safely ignored. It refers to a mechanism that automatically checks for incorrect end-of-stack setting on ARM devices, however it does not work on ESP8266/ESP32 due to a different linker script layout.

[support]

Hi,

No problem, let us know if you run into any further issues with “program without debugging”.

With the popularity, yes, AVaRICE is much less popular than tools like OpenOCD. Arduino is indeed very popular, but it does not support low-level debugging and based on the feedback we got, most Arduino users expect the development tools to be free and there would not be much interest for a professional-grade tool like VisualGDB.

[support]

Hi,

This could happen if the .vgdbsettings file got corrupt or the NMake project settings were modified so that the .vgdbsettings file is no longer specified as the project output.

When you hold Shift, does the VisualGDB Project Properties window show the correct settings? Does opening View->Other Windows->VisualGDB Diagnostics Console and right-clicking on the project again show any error messages?

[support]

Hi,

The VisualGDB embedded frameworks are actually based on the mbed features and libraries reported by the mbed build system, so it could be a bit confusing in case of Ethernet libraries.

Please try referencing the “LWIP Support” framework instead of “Ethernet support” to get the mbed v5 sources (you can search for file names in the BSP.XML file to get the framework names required to include certain sources).

Regarding the new release, we usually update the popular BSPs quarterly. Hence the next mbed update will be released around the end of Summer.

[support]

Hi,

The main reason for worse AVR support is actually the underlying tools. VisualGDB relies on existing tools like OpenOCD or Segger J-Link software to handle the low-level communications and brings a usability level on top of it. The AVR devices use a completely different stack of tools that are much less popular and hence much less reliable, so VisualGDB inherits many of their limitations.

BTW, you can work around the ‘program without debugging’ error message by editing the <SysGCC>\avr\avr-bsp\debuggers\avarice\edp.xml file as follows:

  <SupportedDebugMethods>
    <DebugMethod>
      <DetachCommand></DetachCommand>

VisualGDB will then skip the ‘mon detach’ command when programming the FLASH without debugging.

[support]

Hi,

The “JTAG scan chain interrogation failed: all ones” error usually indicates a wiring issue (some of the JTAG pins are not connected properly). We would recommend starting with the ESP32 board from Sparkfun that we officially support and once you get it to work reliably, moving on to a different one.

[support]

Hi,

It is not directly supported yet. The mechanism used by our BSP generator does not report it as a separate framework, so VisualGDB does not show it in the list. We may fix this in the next release, although currently the easiest way to get it to work is simply add the sources to the project manually.

[support]

Hi,

According to the log, it looks like a hardware wiring problem. Please double-check all your wiring and use a logic analyzer to see if the JTAG signals are going through.

Another advice would be to get a board directly tested by us (e.g. Sparkfun ESP32-Thing ), get the debugging to work with it first and then switch over to ESP32-WROVER.

[support]

Hi,

GCC should actually support #pragma once when compiling .c files as well, so normally you won’t need this.

[support]

Hi,

Not sure what you mean by the “standard template”. Could you please provide an example?

[support]

Hi,

Our AVR support is not as good as ARM as AVR devices are generally less popular and the underlying tools VisualGDB uses to do the low-level communication are somewhat more buggy. Can you confirm that programming FLASH on the same device while debugging works, but the program without debugging doesn’t? Or are both options broken?

[support]

Hi,

Looks like there might be a slight confusion. The Live Variables window allows tracking how the value of a single variable changes over time and saving this history (you need to enable plotting for the variables you want to save as otherwise VisualGDB won’t record any history).

If you want to plot a value of a large array at a single point in time, please use the Visual Watch instead of Live Variables.

Another option would be to use the advanced memory window. It can highlight variable boundaries and save selected ranges to binary files.

If this does not help, please let us know what are exactly you trying to accomplish and we will suggest the best way to do it.

[support]

Hi,

The easiest way would be to add another .cpp file and rename it to .c.

[support]

Hi,

Please try right-clicking in the “registers” window to enable the non-default register groups like “FP registers”.

[Author]

Posts