ESP32dev - PIO Unified Debugger - setup problem

Dear All,
I have some problems with the configuration of the project. I have an esp32dev board and a FT2232H mini Module. I’ve linked them following the wiring connections at this link: _http://docs.platformio.org/en/latest/plus/debugging.html_

My platformio.ini is the following:

[env:esp32dev]
board_build.partitions = partitions_t.csv
platform = espressif32
board = esp32dev
lib_ldf_mode = chain
framework = espidf
upload_port = COM3
monitor_port = COM3
monitor_speed = 115200
debug_tool = minimodule

I have the driver for the FT2232H installed correctly on windows 10. When I try to execute the debug, I receive the following error:

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: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description ‘Dual RS232-HS’, serial ‘’ at bus location '
.pioinit:10: Error in sourced command file:
Remote communication error. Target disconnected.: No error.

I can’t understand why it couldn’t find the FTDI device. Any advice please? :thinking:
Thank you so much.

What is your OS? Do you see Mini Module as USB device in a system?

My os is windows 10. I think I’ve found some problems with FTDI drivers: the FT2232H mini module generates 4 USB-Serial converter instead of two. All of them have “usb migration problem”.
I’ve tried to reinstall the drivers with the latest one from FTDI website, but it doesn’t work. I am stuck because it does the same on other computers.
I’ve try to ask to FTDI support: lets see if they reply.

EDIT: I’ve found that you have to connect also V3V3 to VIO in the FT2232H Mini Module:
CN2, pins 1, 3 & 5 ----> CN2 pins 11 & 21 and CN3, pins 12 & 22
This solve the problem of the USB driver malfunction.

Anyway the debugger session doesn’t start: same messages as above: unable to open ftdi device… :disappointed_relieved:

@botofancalin do you have any ideas?

Are you sure that’s a FT2232 minimodule? Maybe you have FT4232 minimodule.
Please read what’s written on the module chip.
They look very similar.

FT2232 minimodule:
2232

FT4232 minimodule:
4232

The FT2232 is detected as 2 USB2Serial converter and FT4232 is detected as 4 USB2Serial converter
They also have different VID/PID.
FT2232: VID_0403&PID_6010
FT4232: VID_0403&PID_6011 (as i remember…)
Those values can be changed using FtProg but i think is easier to adapt the openocd settings to work with FT4232.

To edit the settings, go to
c:\Users[Your User].platformio\packages\tool-openocd-esp32\share\openocd\scripts\interface\ftdi\esp32_devkitj_v1.cfg
and change the PID to the one detected on windows device manager (ex. 6011)

Please check the last post from this thread: ESP32 & PIO Unified Debugger - #19 by ivankravets

I posted there the detailed instructions for FTDI2232 minimodule setup on windows 10.

Please post the results.

1 Like

Thankyou for your advice. I have an FT2232. I’ve followed your guide and I’ve used zadig’s software.
Anyway this is the output:


As you can see, the debugger tell’s you exactly what’s the problem:
It can’t find a device with VID0403&PID6010 named “Dual RS232-HS”
That’s because your device is detected as “FT2232H-MiniModule” on device manager and may have a different VID&PID

Do you use the drivers from FTDI website?
Please post the VID/PID of the FT2232H-MiniModule from your device manager.
To find the VID/PID, go to device manager, right click on the device and select Properties->Details->Hardware Ids

Capture1

Please post a picture here with the VID and PID

1 Like

I’m seeing the same problem here. My PID is coming up as 6011 instead of 6010
FTDIBUS\COMPORT&VID_0403&PID_6011

So… you have an FT4232 after all…

The board says FT2232 on it so it doesn’t tie up with what the device is actually reporting. Surely debugging should be able to work with both devices. The only difference between them seems to be 2 or 4 channels?

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’…