ESP32dev - PIO Unified Debugger - setup problem

Used this in my platformio.ini and I seem to have bypassed this issue.
Just need to rewire it all again and test

[env:myenv]
debug_tool = custom
debug_init_break=
debug_server =
 $PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/bin/openocd
 -s
 $PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/share/openocd/scripts/
 -f
 $PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/share/openocd/scripts/interface/ftdi/digilent_jtag_smt2.cfg
 -f
 $PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/share/openocd/scripts/board/esp-wroom-32.cfg
 -c 'ftdi_vid_pid 0x0403 0x6011'
debug_load_cmd=preload

Yes. FT4232 have 4 channels and different product ID (PID)
But will work just fine as debugger.

I think you can remove this line

$PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/share/openocd/scripts/interface/ftdi/digilent_jtag_smt2.cfg

and will work just fine.

Thanks. It’s slightly closer. I can now use minimodule by modifying mbftdi.cfg in .platformio\packages\tool-openocd-esp32\share\openocd\scripts\interface\ftdi as follows…

interface ftdi
#ftdi_device_desc “Dual RS232-HS”
ftdi_device_desc “Quad RS232-HS”
#ftdi_vid_pid 0x0403 0x6010
ftdi_vid_pid 0x0403 0x6011

ftdi_layout_init 0x0008 0x000b

This gets me this far…
Checking size .pioenvsesp32devirmware.elf
Memory Usage → Redirecting...
DATA: [ ] 4.1% (used 13404 bytes from 327680 bytes)
PROGRAM: [= ] 13.5% (used 177060 bytes from 1310720 bytes)
Configuring upload protocol…
AVAILABLE: esp-prog, esptool, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny
CURRENT: upload_protocol = esptool
Looking for upload port…
Auto-detected: COM13
Uploading .pioenvsesp32devirmware.bin
Serial port COM13
Connecting……_____
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
*** [upload] Error 2
[ERROR] Took 39.19 seconds
I’ve managed to upload the firmware to the esp32 board ok by setting upload_port to point to the usb serial port for the ESP32 board instead of the minimodule, but the debugger then stalls still. I think I need to go back and check the wiring, but atleast I can now get past the PID issue without resorting to the custom command

It means that esptool via Serial Port is used (not debug tool). You can change upload protocol via Redirecting...

See available protocols above.

For example, if your debug tool is minimodule and you would like to flash board via JTAG/minimodule, need to use the next configuration:

[env:yourenv]
upload_protocol = minimodule
debug_tool = minimodule

Thanks - think it’s closer but I get this error with either protocol and port…

PlatformIO Unified Debugger > Redirecting...
PlatformIO: Initializing remote target…
Open On-Chip Debugger 0.10.0-dev (2018-06-04-09:51)
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
adapter speed: 20000 kHz
esp32 interrupt mask on
force hard breakpoints
Info : tcl server disabled
Info : telnet server disabled
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : ftdi: if you experience problems at higher adapter clocks, try the command “ftdi_tdo_sample_edge falling”
Info : clock speed 20000 kHz

it look’s OK for now…

Make sure you perform the step 7 from my instructions: ESP32 & PIO Unified Debugger - #20 by botofancalin on the ftdi channel that you use as Jtag
Add this line to openocd cfg file that you use:

ftdi_channel 0

and try again.

You can also try to replace “ftdi_layout_init 0x0008 0x000b” with this setting:

ftdi_layout_init 0x0000 0x001b

Please post the results.

Ok, so the error is gone and it looks like it’s better, but I don’t anything happening further than this.
I’ve set some break points in the GUI. They don’t seem to be getting hit.
Tried changing the layout parameter and no difference.
Would I see errors if the wiring wasn’t correct? Is there a command I can put into the terminal or debug switch I can use to get more info on what’s happening?
Thanks for your help so far,
Andy.

Writing at 0x0000e000… (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 9362.3 kbit/s)…
Hash of data verified.
Compressed 177216 bytes to 88964…
Writing at 0x00010000… (16 %)
Writing at 0x00014000… (33 %)
Writing at 0x00018000… (50 %)
Writing at 0x0001c000… (66 %)
Writing at 0x00020000… (83 %)
Writing at 0x00024000… (100 %)
Wrote 177216 bytes (88964 compressed) at 0x00010000 in 1.8 seconds (effective 768.4 kbit/s)…
Hash of data verified.
Leaving…
Hard resetting via RTS pin…
[SUCCESS] Took 8.02 seconds
Reading symbols from c:/Users/Andy.ASUS/Documents/PlatformIO/Projects/DebugTest2/.pioenvs/esp32dev/firmware.elf…
done.
PlatformIO Unified Debugger > Redirecting...
PlatformIO: Initializing remote target…
Open On-Chip Debugger 0.10.0-dev (2018-06-04-09:51)
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
adapter speed: 20000 kHz
esp32 interrupt mask on
force hard breakpoints
Info : tcl server disabled
Info : telnet server disabled
Info : ftdi: if you experience problems at higher adapter clocks, try the command “ftdi_tdo_sample_edge falling”
Info : clock speed 20000 kHz

Make sure the debug lines (TDI,TDO,TMS,TCK,TRST, GND) are connected correctly.
You can try the console command"pio debug --interface gdb -x .pioinit" to start gdb and connect to target.

I don’t seem to be able to make any further progress. I’m using an ESP32 dev board based on the WROOM32 package. I’ve double checked the wiring and it seems to be correct. I’ve tried all 4 ports as listed in device manager and get the same results for each. Tried the layout value you have suggested. Only other thing I can think is to run up the logic analyser tomorrow and take a look at the signals to see what is happening.

Andy.

Managed to set up debug

With the following in platformio,ini:

debug_tool = custom
#debug_init_break=
debug_server =
$PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/bin/openocd
-d
3
-s
$PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/share/openocd/scripts/
-f
$PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/share/openocd/scripts/interface/ftdi/esp32_devkitj_v1.cfg
-f
$PLATFORMIO_HOME_DIR/packages/tool-openocd-esp32/share/openocd/scripts/board/esp-wroom-32.cfg
-c ‘ftdi_vid_pid 0x0403 0x6011’

Here is the tail of the debug messages

Debug: 121 26018 tcl.c:573 jim_newtap_cmd(): Processing option: -expected-id
Debug: 122 26018 core.c:1304 jtag_tap_init(): Created Tap: esp32.cpu0 @ abs position 0, irlen 5, capture: 0x1 mask: 0x3
Debug: 123 26019 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_target create esp32 esp32 -endian little -chain-position esp32.cpu0 -rtos FreeRTOS
Debug: 124 26020 command.c:143 script_debug(): command - ocd_target ocd_target create esp32 esp32 -endian little -chain-position esp32.cpu0 -rtos FreeRTOS
Debug: 125 26020 target.c:1973 target_free_all_working_areas_restore(): freeing all working areas
Debug: 126 26021 target.c:1973 target_free_all_working_areas_restore(): freeing all working areas
Debug: 127 27020 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 128 27021 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 129 27021 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 130 27022 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 131 27022 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 132 27022 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 133 28022 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 134 28023 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 135 28023 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 136 28023 command.c:364 register_command_handler(): registering ‘ocd_set_permissive’…
Debug: 137 29025 core.c:1304 jtag_tap_init(): Created Tap: esp32.cpu1 @ abs position 1, irlen 5, capture: 0x1 mask: 0x3
Debug: 138 29026 command.c:399 register_command(): command ‘esp32’ is already registered in ‘’ context
Debug: 139 29026 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 140 29027 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 141 30027 command.c:364 register_command_handler(): registering ‘ocd_esp32’…
Debug: 142 30027 command.c:364 register_command_handler(): registering ‘ocd_esp32’…

Yep.
That’s it :slight_smile:
I think will be much easier to edit the “ftdi_vid_pid 0x0403 0x6010” line on esp32_devkitj_v1.cfg
Then you won’t need fancy options on platformio.ini

I can debug esp32 project with ftdi based jtag using just this options on platformio.ini:

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino

I meant debug on openocd itself. I still don’t seem to have it working as it just seems to stall at that point and never halts the program at any breakpoint I’ve added and doesn’t display anu of the debug info. I’ve ordered a different interface in case this one is a problem

I think I have a driver issue.

I’m getting the following message in the event log.

!Device USB\VID_0403&PID_6011&MI_00\7&296dc3c5&0&0000 was not migrated due to partial or ambiguous match."

Ok, I finally have it working. I missed one set of power loop connections on the miniboard that are more clearly documented here:

Missing these connections has the bizarre result that the FT2232H miniboard is detected as an FT4232H miniboard! So, it really leads you up the garden path. Now I have these loop cables in place, the driver correctly identifes the 2 ports and my config is now very simple. Thanks for your help, I’ve learnt a lot more about how this stuff all hooks together :slight_smile:

1 Like

The 3.3v VIO should be router on the minimodule board… At least they are routed on the ft4232 minimodule that i got my hands on…

Anyway. good that you finally got it working.
Can you please check if the VID/PID was changed too ?

It’s back to what it should be - 6010, so it would have worked right away had I not missed those wires.

This is awesome, by the way. I’m used to debugging with nothing more than the serial port…

I was also mistakenly wiring the FT2232H minimodule.
As wired as documented, the driver correctly recognized FT2232H(vid 0403,pid6010).
I replaced the driver with zadig, but an same error occurred.

Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description ‘Dual RS232-HS’, serial ‘’ at bus location '’

However, the error was solved by the following procedure.

・confirm driver name when using zadig

・Replace the “Dual RS232-HS” in the following directory with the driver name displayed by zadig(“FT2232H MiniModule”) with grep.(recommend back up directory)

%HOMEPATH%/.platformio/packages/tool-openocd-esp32/share/openocd/scripts/interface

・then press F5!!

With the latest FTDI driver, vid and pid of FT2232H do not change, but I think that it is a error caused by different display names of drivers.

2 Likes

This is a bug in platformio.py, see my Pull Request

Thanks! Should be fixed in the latest ESP32 dev/platform.

1 Like

Maybe one of you here can help me out since it seems that this thread already has the attention of some FT2232H users… :slight_smile:
I asked this earlier: Debugging non-funct [OSX | VSC | ESP32 | Minimodule/FT2232H]

tl;dr:
Could any of you share a working demo project with the ESP32 and FT2232H debugging?
I am especially interested in the platformio.ini and any other edited presets (openOCD should have some too?) and the factory/working EEP/config for the FT2232H since I bought another board, not the original minimodule.
Perfect case: a dump of a working FT_prog.exe .xml config file.