Unable to debug using gdbgui (IDFGH-4098)

[vignesh93k]

Environment

• Development Kit: ESP32-Wrover-Kit
• Kit version (for WroverKit): v4.1
• Module or chip used: ESP32-WROVER-B
• IDF version: v4.2-beta1-86-gdddcc2ede
• Build System: idf.py
• Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2020r2) 8.2.0
• Operating System: Windows
• (Windows only) environment type: ESP Command Prompt
• Using an IDE?: No
• Power Supply: USB

Problem Description

When I start openocd and try to debug blink example project using gdbgui, a browser window is opened with the url http://127.0.0.1:5000/ and an error occurs in the page saying Unable to connect. Hence, I am unable to debug using gdbgui.

Expected Behavior

A gdbgui debug session should be started in browser

Actual Behavior

Gdbgui debug session is not started in browser and an error Unable to connect is shown as below

Steps to reproduce

1. Configure the board for debugging by following the steps mentioned in this documentation
2. Compile and flash the blink example by following the steps mentioned in the Getting started section of esp-idf documentation.
3. Start openocd in ESP command prompt with the command
   openocd -f board/esp32-wrover-kit-3.3v.cfg
4. Start another ESP command prompt and change the current directory to blink example project path
5. Enter the command idf.py gdbgui monitor
6. A browser window is automatically opened with the url http://127.0.0.1:5000/

Picture of setup

Debug Logs

openocd command log

D:\Vignesh\ESP32_IDE_Setup\esp\esp-idf>openocd -f board/esp32-wrover-kit-3.3v.cfg
Open On-Chip Debugger  v0.10.0-esp32-20200420 (2020-04-20-16:15)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Configured 2 cores
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32: Debug controller 0 was reset.
Info : esp32: Core 0 was reset.
Info : esp32: Debug controller 1 was reset.
Info : esp32: Core 1 was reset.
Info : Listening on port 3333 for gdb connections

gdbgui command log

D:\Vignesh\ESP32_IDE_Setup\esp\blink>idf.py gdbgui monitor
Executing action: gdbgui
gdbgui started as a background task 6940
Executing action: monitor
Choosing default port b'COM8' (use '-p PORT' option to set a specific serial port)
Running idf_monitor in directory d:\vignesh\esp32_ide_setup\esp\blink
Executing "C:\Users\ELCOT\.espressif\python_env\idf4.2_py3.7_env\Scripts\python.exe D:\Vignesh\ESP32_IDE_Setup\esp\esp-idf\tools/idf_monitor.py -p COM8 -b 115200 --toolchain-prefix xtensa-esp32-elf- d:\vignesh\esp32_ide_setup\esp\blink\build\blink.elf -m 'C:\Users\ELCOT\.espressif\python_env\idf4.2_py3.7_env\Scripts\python.exe' 'D:\Vignesh\ESP32_IDE_Setup\esp\esp-idf\tools\idf.py'"...
←[0;33m--- WARNING: GDB cannot open serial ports accessed as COMx←[0m
←[0;33m--- Using \\.\COM8 instead...←[0m
--- idf_monitor on \\.\COM8 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x1e (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:4
load:0x3fff0034,len:7200
ho 0 tail 12 room 4
load:0x40078000,len:13704
ho 0 tail 12 room 4
load:0x40080400,len:4000
0x40080400: _init at ??:?

entry 0x40080688
I (33) boot: ESP-IDF v4.2-beta1-86-gdddcc2ede 2nd stage bootloader
I (33) boot: compile time 00:11:32
I (33) boot: chip revision: 1
I (37) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (44) boot.esp32: SPI Speed      : 40MHz
I (49) boot.esp32: SPI Mode       : DIO
I (53) boot.esp32: SPI Flash Size : 2MB
I (58) boot: Enabling RNG early entropy source...
I (63) boot: Partition Table:
I (67) boot: ## Label            Usage          Type ST Offset   Length
I (74) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (82) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (89) boot:  2 factory          factory app      00 00 00010000 00100000
I (97) boot: End of partition table
I (101) boot_comm: chip revision: 1, min. application chip revision: 0
I (108) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05c60 ( 23648) map
I (126) esp_image: segment 1: paddr=0x00015c88 vaddr=0x3ffb0000 size=0x021f8 (  8696) load
I (130) esp_image: segment 2: paddr=0x00017e88 vaddr=0x40080000 size=0x00404 (  1028) load
0x40080000: _WindowOverflow4 at D:/Vignesh/ESP32_IDE_Setup/esp/esp-idf/components/freertos/xtensa/xtensa_vectors.S:1730

I (135) esp_image: segment 3: paddr=0x00018294 vaddr=0x40080404 size=0x07d84 ( 32132) load
I (158) esp_image: segment 4: paddr=0x00020020 vaddr=0x400d0020 size=0x12dc0 ( 77248) map
0x400d0020: _stext at ??:?

I (187) esp_image: segment 5: paddr=0x00032de8 vaddr=0x40088188 size=0x01d20 (  7456) load
0x40088188: rtc_clk_cpu_freq_to_xtal at D:/Vignesh/ESP32_IDE_Setup/esp/esp-idf/components/soc/src/esp32/rtc_clk.c:421

I (196) boot: Loaded app from partition at offset 0x10000
I (196) boot: Disabling RNG early entropy source...
I (199) cpu_start: Pro cpu up.
I (203) cpu_start: Application information:
I (207) cpu_start: Project name:     blink
I (212) cpu_start: App version:      1
I (217) cpu_start: Compile time:     Oct 13 2020 00:10:36
I (223) cpu_start: ELF file SHA256:  d792055b2ebcf403...
I (229) cpu_start: ESP-IDF:          v4.2-beta1-86-gdddcc2ede
I (235) cpu_start: Starting app cpu, entry point is 0x400815c0
0x400815c0: call_start_cpu1 at D:/Vignesh/ESP32_IDE_Setup/esp/esp-idf/components/esp32/cpu_start.c:282

I (0) cpu_start: App cpu up.
I (246) heap_init: Initializing. RAM available for dynamic allocation:
I (252) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (258) heap_init: At 3FFB2A28 len 0002D5D8 (181 KiB): DRAM
I (265) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (271) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (277) heap_init: At 40089EA8 len 00016158 (88 KiB): IRAM
I (284) cpu_start: Pro cpu start user code
I (302) spi_flash: detected chip: generic
I (303) spi_flash: flash io: dio
W (303) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (313) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Turning off the LED
Turning on the LED
Turning off the LED
Turning on the LED
Turning off the LED
Turning on the LED
Turning off the LED
Turning on the LED
Turning off the LED
Turning on the LED
Turning off the LED
Turning on the LED
Turning off the LED

Other items

• sdkconfig file ( sdkconfig.txt )

[Alvin1Zhang]

Thanks for reporting and letting us know, we will look into.

[dobairoland]

Hi @vignesh93k. Thank you also for the especially good description of the issue.

It works for me on Linux following your steps and using your IDF commit.

Does anything else shows up in the openocd output after you started idf.py gdbgui monitor?

What is the output of idf.py gdbgui when you start it without monitor?

[vignesh93k]

Hi @dobairoland. Thank you for your response.

Please find the output of openocd before starting idf.py commands as below:

D:\Vignesh\ESP32_IDE_Setup\esp\esp-idf>openocd -f board/esp32-wrover-kit-3.3v.cfg
Open On-Chip Debugger  v0.10.0-esp32-20200420 (2020-04-20-16:15)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Configured 2 cores
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : Listening on port 3333 for gdb connections

1. Please find the output of openocd after starting idf.py gdbgui monitor as given below

Info : esp32: Debug controller 0 was reset.
Info : esp32: Core 0 was reset.
Info : esp32: Debug controller 1 was reset.
Info : esp32: Core 1 was reset.
Info : esp32: Debug controller 0 was reset.
Info : esp32: Core 0 was reset.
Info : esp32: Debug controller 0 was reset.
Info : esp32: Core 0 was reset.
Info : esp32: Debug controller 1 was reset.
Info : esp32: Core 1 was reset.

2. Please find the output of idf.py gdbgui when I start it without monitor , as given below

Executing action: gdbgui
gdbgui started as a background task 5532
Executing action: post_debug
"gdbgui" exited with 3221225477

After starting idf.py gdbgui without monitor also, the actual behavior as mentioned above is observed.

[david-cermak]

@vignesh93k
Thanks for posting the results of these targets executed separately. They look correct to me. Just seems that the browser cannot access the hosted endpoint for some reason (windows firewall?, port occupied?)

Could you please check with another port, starting from idf.py:

idf.py gdbgui  --gdbgui-port 8080

Also could you try to run the gdbgui itself from the command line:

> gdbgui -p 8080
Opening gdbgui with default browser at http://127.0.0.1:8080
exit gdbgui by pressing CTRL+C
Opening in existing browser session.

and connecting to the http://127.0.0.1:8080 from another browser (after closing the default one)

[david-cermak]

@vignesh93k Any update on this issue? Did the gdbui work on a different port?

[rjsargeant]

Hi,

I am experiencing exactly the same problem with the same symptoms using the Wrover-Kit board. I have replicated the problem on two different machines and a clean installation of Windows 10 Pro. Any help would be appreciated.

[david-cermak]

Hi @rjsargeant

What happens if you start the gdbui itself from the command line?

$ gdbgui -p 8080

Would it print something out?
Could you try to open a browser and copy the printed link to it? (e.g. http://127.0.0.1:8080)? What happens? (Any message from windows firewall? unable to connect page? anything else?)
Thanks!

[rjsargeant]

Hi @rjsargeant

What happens if you start the gdbui itself from the command line?

$ gdbgui -p 8080

Would it print something out?
Could you try to open a browser and copy the printed link to it? (e.g. http://127.0.0.1:8080)? What happens? (Any message from windows firewall? unable to connect page? anything else?)
Thanks!

Exactly the same as when port 5000 is used. Unable to connect page.

Thanks

[Trickfilm400]

un ubuntu "gdbgui -p 8080" works, but not with kalilinux
interesting, in kalilinux in the console is an error with "failed ith typeerror"

[dachalco]

After some issues I was able to get it working on Mac with Firefox. There's open known issues with some python deps, so it's very important to have the right version set for things to work. Fixed by upgrading my local version of gdbgui to 1.8.0. Also got it work with gdbgui 0.13

[DavidAntliff]

I have this same error - by downgrading greenlet from 1.0.0 to 0.4.16 I was able to get a HTTP connection, although gdbgui seems to be unable to connect to the gdb server or load the binary (in fact very little seems actually functional):

python3 -m pip install greenlet==0.4.16

With greenlet-1.0.0 I get a segmentation fault when I try to run gdbgui manually, or via idf.py gdbgui.

[dobairoland]

@DavidAntliff Have you tried the latest master branch? It was just updated 12 hours ago. There was a necessary workaround applied for greenlet. Please note that not only the requirements.txt file was updated. And it was tested in several independent environments. The fix will be backported to v4.3 and v4.2 soon.

[DavidAntliff]

@dobairoland I just gave master branch a try and it works well - thank you for the hint. I look forward to the backport to v4.x.