Something broke with the installation…

[eyalasko]

Hi,

 

I’ve recently started developing for the ESP32 and found VisualGDB very convenient.

Unfortunately, not sure what exactly happened, the tool ceased working as expected.

 

I’ve tried to repair, uninstall-reinstall visualgdb (5.5.2.3410) and also the latest toolchain (8.2.0-r2), but I just can’t get it to work again 🙁

To start with – the build log show the following and I don’t figure why:

CMake Warning at C:/sysgcc/esp32/esp-idf/v4.0/tools/cmake/idf.cmake:14 (message):
   IDF_PATH environment variable is different from inferred IDF_PATH.

       Check if your project's top-level CMakeLists.txt includes the right
       CMake files. Environment IDF_PATH will be used for the build.
Call Stack (most recent call first):
   C:/sysgcc/esp32/esp-idf/v4.0/tools/cmake/project.cmake:7 (include)
   CMakeLists.txt:5 (include)

Secondly, when hitting ‘start’ (in the toolbar) the environment seems to be flashing and even halts at app_main() but when run it keep sending:

"Debug controller 0 was reset

Core 0 was reset

Debug controller 1 was reset

Core 1 was reset

..."

Thirdly, any attempt to breakpoint or step-through halts the debugger.

And lastly, I couldn’t find any IDF_PATH environment variable defined (doesn’t the toolchain installation take care of this)?

 

I’m in despair so any help is highly appreciated

Thanks for  any assistance

[support]

Hi,

Unfortunately, the ESP32 tools are considerably more fragile than ARM-based tools, hence it is possible to break them by installing incompatible versions of different components or by accidentally patching some open-source components.

Our best advice to resolve it would be:

1. Delete the ESP32 toolchain and the ESP32 OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.
2. Try creating a new ‘ledblink’ project from scratch. Make sure you use the ESP-IDF version that is shipped with the toolchain.
3. Ensure the ledblink project works and can be debugged.
4. Once you get the ledblink project to work, try opening the previously broken project and check if it behaves differently. If it still doesn’t work, please try comparing the configuration files for the 2 projects (or simply move the code from the broken project to the working ledblink project).

[eyalasko]

Hi,

 

I’ve followed your guidelines – deleted the packages and recreated ‘led blink’ project.

As expected, the ESP32 toolchain (8.2.0/8.1.0/r2) was reinstalled and so was the ESP32 debug (20191024)

The project was built and programmed to the DevKit (WRover kit)

However, I still can’t debug… after hitting a breakpoint I can’t single step and get GDB timeout message “-stack-list-frames –thread 1” …

 

Not sure if it’s relevant, but when the build process starts, I still get the following warning (screen cap attached):

Removing C:\Users\eyala\source\repos\ESP32\Blinky/VisualGDB/Debug...
Reconfiguring project due to missing Makefile...
Running CMake: C:\Users\eyala\AppData\Local\VisualGDB\CMake\bin\cmake.exe ../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_COLOR_MAKEFILE=OFF -DCMAKE_MAKE_PROGRAM="C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe"
CMake Warning at C:/sysgcc/esp32/esp-idf/v4.0/tools/cmake/idf.cmake:14 (message):
   IDF_PATH environment variable is different from inferred IDF_PATH.

               Check if your project's top-level CMakeLists.txt includes the right
               CMake files. Environment IDF_PATH will be used for the build.
Call Stack (most recent call first):
   C:/sysgcc/esp32/esp-idf/v4.0/tools/cmake/project.cmake:7 (include)
   CMakeLists.txt:5 (include)

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The -stack-list-frames –thread 1 error sometimes happens when the ESP32 gdb port tries to interpret the stack of the old program (that is still programmed in the board) using the symbols from the new program (that was just built). This happens relatively rarely, and appears to be a bug in the ESP32 tools.

If this happens, please try programming the FLASH memory over the serial port (right-click on the project in Solution Explorer and select ‘Program FLASH Memory’). This should overwrite the old program in the ESP32 FLASH memory and will make sure you can debug the new one.

[eyalasko]

Hi,

 

Can’t get it to program over serial, Keep getting “esptool.py failed”.

However it seem that JTAG loading works OK, its just the debugging that get stuck…

 

Any thoughts?

 

 

 

[support]

Sorry, if the esptool.py doesn’t work, the device or board might be malfunctioning. Please consider posting more details on the Espressif forums and asking whether there is a workaround.

If you could get the underlying tools to work with the device, VisualGDB should be able to work with it as well.

[Author]

Posts