Debugger only works for some programs

panometric · September 17, 2019, 8:07am

Hi, a newbie to PIO and ESP32 here. I have a custom WRover board, and a new FT232H, and am having difficulty debugging some programs. For example, espidf-blink will debug, but espidf-aws-iot , or similar programs with IoT and Wifi, time out on the same hardware. .

Environment: Win10, VSCode, PlatformIO, version 4.1.0b1

I followed the instructions in Medium article, The debugger appears to be attached correctly, since it finds the 2 cores, but then times out. The JTAG pins are all dedicated. Not sure where to look next. Ideas:?
1 My module has 16MB of flash, does that matter?
2.Does the debugger need a reset line?
???

Thanks.

Debugger Log:

PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = ftdi
PlatformIO: Initializing remote target...
Open On-Chip Debugger  v0.10.0-esp32-20190708 (2019-07-08-11:04)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
none separate
ftdi samples TDO on falling edge of TCK
adapter speed: 20000 kHz
Info : Configured 2 cores
esp32 interrupt mask on
Info : tcl server disabled
Info : telnet server disabled
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description '*', serial '*' at bus location '*'
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 (pwrstat=0x5F, after clear 0x0F).
Info : esp32: Core 0 was reset (pwrstat=0x5F, after clear 0x0F).
Info : esp32: Debug controller 0 was reset (pwrstat=0x5F, after clear 0x0F).
Info : esp32: Core 0 was reset (pwrstat=0x5F, after clear 0x0F).
Info : accepting 'gdb' connection from pipe
Error: No symbols for FreeRTOS
Info : Target halted. PRO_CPU: PC=0x40007BA1 (active)    APP_CPU: PC=0x00000000
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Error: timed out while waiting for target halted / 4 - 2
Info : Target halted. PRO_CPU: PC=0x40090069 (active)    APP_CPU: PC=0x00000000
Error: xtensa_wait_algorithm: not halted 0, pc 0x40090069, ps 0x60025
Error: Failed to wait algorithm (-302)!
Error: Algorithm run failed (-302)!
Error: Failed to run flasher stub (-302)!
Warn : Failed to get flash mappings (-302)!
Error: Target is already running an algorithm
Error: Failed to start algorithm (-4)!
Error: Algorithm run failed (-4)!
Error: Failed to run flasher stub (-4)!
Error: Target is already running an algorithm
Error: Failed to start algorithm (-4)!
Error: Algorithm run failed (-4)!
Error: Failed to run flasher stub (-4)!
Error: Failed to probe flash, size 0 KB
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected
Error: error during select: Unknown error
Warn : Flash driver of esp32.flash does not support free_driver_priv()
Warn : Flash driver of irom does not support free_driver_priv()
Warn : Flash driver of drom does not support free_driver_priv()
.pioinit:11: Error in sourced command file:
Remote communication error.  Target disconnected.: No error.

manuelbl · September 17, 2019, 8:38am

Can you provide more information about a project that fails to debug, i.e. a link to a git repository, contents of platformio.ini and any other information for reproducing it. In case it’s an AWS IoT project, specify how you provide the certificates.

The debugger usually works without the reset line. So this shouldn’t be the problem.

pfeerick · September 17, 2019, 9:38am

espidf-aws-iot → platform-espressif32/examples/espidf-aws-iot at develop · platformio/platform-espressif32 · GitHub

Example seems to come with it’s own certificates.

panometric · September 17, 2019, 4:49pm

As @pfeerick said, the repo has certs included. The only thing I have changed is in platformio.ini:

upload_speed = 460800
build_flags =
  -DCOMPONENT_EMBED_TXTFILES=src/private.pem.key:src/certificate.pem.crt:src/aws-root-ca.pem
  -DCONFIG_WIFI_SSID=\"MYSSID\"
  -DCONFIG_WIFI_PASSWORD=\"MYPASSWD\"

The upload speed has to be added, or it will try to switch to 921600 and fail. That could be because of my serial circuit, I’m using a different FTDI cable (not the debugger), and my board has an RS-232 converter. The debugger fails, with or without it connected.

This is the terminal output:

Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (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:0x3fff0018,len:4
load:0x3fff001c,len:6120
load:0x40078000,len:8816
ho 0 tail 12 room 4
load:0x40080400,len:6412
entry 0x40080748
␛[0;32mI (31) boot: ESP-IDF 3.30202.190627 2nd stage bootloader␛[0m
␛[0;32mI (31) boot: compile time 09:25:33␛[0m
␛[0;32mI (60) boot: Enabling RNG early entropy source...␛[0m
␛[0;32mI (61) boot: SPI Speed      : 40MHz␛[0m
␛[0;32mI (61) boot: SPI Mode       : DIO␛[0m
␛[0;32mI (63) boot: SPI Flash Size : 16MB␛[0m
␛[0;32mI (67) boot: Partition Table:␛[0m
␛[0;32mI (70) boot: ## Label            Usage          Type ST Offset   Length␛[0m
␛[0;32mI (78) boot:  0 nvs              WiFi data        01 02 00009000 00006000␛[0m
␛[0;32mI (85) boot:  1 phy_init         RF data          01 01 0000f000 00001000␛[0m
␛[0;32mI (93) boot:  2 factory          factory app      00 00 00010000 00100000␛[0m
␛[0;32mI (100) boot: End of partition table␛[0m
␛[0;32mI (104) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x17a9c ( 96924) map␛[0m
␛[0;32mI (147) esp_image: segment 1: paddr=0x00027ac4 vaddr=0x3ffbdb60 size=0x03150 ( 12624) load␛[0m
␛[0;32mI (152) esp_image: segment 2: paddr=0x0002ac1c vaddr=0x40080000 size=0x00400 (  1024) load␛[0m
␛[0;32mI (154) esp_image: segment 3: paddr=0x0002b024 vaddr=0x40080400 size=0x04fec ( 20460) load␛[0m
␛[0;32mI (171) esp_image: segment 4: paddr=0x00030018 vaddr=0x400d0018 size=0x786b8 (493240) map␛[0m
␛[0;32mI (343) esp_image: segment 5: paddr=0x000a86d8 vaddr=0x400853ec size=0x0b0f4 ( 45300) load␛[0m
␛[0;32mI (370) boot: Loaded app from partition at offset 0x10000␛[0m
␛[0;32mI (370) boot: Disabling RNG early entropy source...␛[0m
␛[0;32mI (371) cpu_start: Pro cpu up.␛[0m
␛[0;32mI (374) cpu_start: Starting app cpu, entry point is 0x40081fc0␛[0m
␛[0;32mI (0) cpu_start: App cpu up.␛[0m
␛[0;32mI (385) heap_init: Initializing. RAM available for dynamic allocation:␛[0m
␛[0;32mI (392) heap_init: At 3FFAE6E0 len 0000F480 (61 KiB): DRAM␛[0m
␛[0;32mI (398) heap_init: At 3FFC6DC0 len 00019240 (100 KiB): DRAM␛[0m
␛[0;32mI (404) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM␛[0m
␛[0;32mI (410) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM␛[0m
␛[0;32mI (417) heap_init: At 400904E0 len 0000FB20 (62 KiB): IRAM␛[0m
␛[0;32mI (423) cpu_start: Pro cpu start user code␛[0m
␛[0;32mI (106) cpu_start: Starting scheduler on PRO CPU.␛[0m
␛[0;32mI (0) cpu_start: Starting scheduler on APP CPU.␛[0m
I (176) wifi: wifi driver task: 3ffb7be4, prio:23, stack:3584, core=0
I (186) wifi: wifi firmware version: 693c7b6
I (186) wifi: config NVS flash: enabled
I (186) wifi: config nano formating: disabled
␛[0;32mI (186) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE␛[0m
␛[0;32mI (196) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE␛[0m
I (256) wifi: Init dynamic tx buffer num: 32
I (256) wifi: Init data frame dynamic rx buffer num: 32
I (256) wifi: Init management frame dynamic rx buffer num: 32
I (266) wifi: Init management short buffer num: 32
I (266) wifi: Init static rx buffer size: 1600
I (266) wifi: Init static rx buffer num: 10
I (276) wifi: Init dynamic rx buffer num: 32
␛[0;32mI (276) subpub: Setting WiFi configuration SSID OMSI...␛[0m
␛[0;33mW (286) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration␛[0m

B�YY�Y,]K␗�W�.H]�Z�V��␖VH�H�

manuelbl · September 17, 2019, 8:17pm

I’ve tried to reproduce your problem. But I was successful debugging and failed at reproducing with all projects I tried. So try the following things:

1. Check and recheck the wiring

It’s essential that TDI, TDO, TCK, TMS and GND are connected to the right pins and have a reliable connection. Furthermore, shorter cables are better (no more than 30cm).

2. Use the FT232H/ESP-Prog for upload

In platformio.ini, add:

upload_protocol = esp-prog

This will quickly show if the JTAG connection works before the complex debug session starts. Furthermore, you can leave the serial monitor connected at all times as it is not needed for upload.

3. Lower the adapter speed

Try to lower the adapter speed by editing the file /Users/xxx/.platformio/packages/tool-openocd-esp32/share/openocd/scripts/board/esp-wroom-32.cfg and changing the value for adapter_khz. The default value is 20000 (20MHz). Try 10000 or 5000.

4. Use a matching board description

For your firmware, it’s important that you have 16MB of flash. For the debugger I’m not sure. I don’t know where it gets the memory layout information from. But try to use a matching board description anyway.

There are a few board descriptions in /Users/xxx/.platformio/platforms/espressif32/boards for boards/modules with 16MB. If none fits, copy one of the .json files to /Users/xxx/.platformio/boards and adapt it to your needs.

5. Connect the serial monitor before you start debugging

When you connect the serial monitor to the device, it will first reset it. That’s a problem during a debugging session. So connect it early.

I don’t know what serial monitor you are using. I find it convenient to use a program separate from Visual Studio Code.

6. Stop in app_main

Instead of the line shown in the Medium article, use:

debug_init_break = tbreak app_main

This tells the debugger to initially stop in the app_main function. That’s the better choice for ESP-IDF but will probably not be the cause of the problem. (The article uses setup instead which is preferred for use with the Arduino framework.)

Further observation

Many system cannot make reliable serial connections at 921,600 bps. Unfortunately, it’s the default for all ESP32 boards. I have to lower it to 460,800 as well.

panometric · September 18, 2019, 4:08pm

Thanks for your detailed reply. Those are good hints.

In my case, I read elsewhere that failure at the phy_init stage indicates a power droop, and sure enough, I was getting one, despite what looked like a suitable design.