TTGO T-Beam debugging with ESP-Prog

Advanced Solutions Debugging
1

I have some TTGO T-Beam boards that I’m using for a project. The docs suggest the ESP-Prog board for debugging and the docs page of the ESP-Board list the T-Beam as one of the compatible boards. However, upon closer inspection, it seems that the pin MTDI / GPIO12 that is needed for the debugging board to work is used by the GPS and is not exposed (or so I think, because I don’t really understand the schematics).
A similar question was asked but the answer is that you can’t use the pin for both things at the same time, which I don’t have a problem with (as I’m not planning to use the GPS), I just need to debug the code with the board.

The question is, is the T-Beam really compatible with any JTAG debugger? Is some soldering needed to get it to work? In this case, do you have any suggestion on where’s the best place to solder?

Thanks

2

Here 's a link to the schematics. The IO12 pin is mostly seen in page 4

3

The linked topic is correct – if the GPIO pins

GPIO12 — TDI
GPIO15 — TDO
GPIO13 — TCK
GPIO14 — TMS

Are not exposed and unconflicted with something else, debugging is impossible.

The schematics show where IO12 geos

grafik

grafik

grafik
grafik704×621 41.8 KB

The IO12 is also not available anywhere else on a pin header on a board.

The only way to make it debugabble is to desolder R58, to break the connection between IO12 and the GPS module, and then connect IO12 to the esp-prog.

Judging from this image and comparing it against the schematic, it should be this resistor

grafik

But it doesn’t seem to be practible to desolder that tiny component… If you can you can maybe get a normal dev board with all pins exposed and debug the sketch there. If you need some of the modules (like the GPS), there are also breakout boards for that so you can then attach them to other pins that don’t interfere with JTAG.

Another thought would be to not debug via JTAG but via a software GDB server (gdbstub) running on the ESP32 over UART. ESP-IDF has code that for that (esp-idf/components/esp_gdbstub at master · espressif/esp-idf · GitHub) but it’s only activated on a crash and not in general… Some code modifications would surely have to be done.

4

Thanks for your thorough reply.

I didn’t understand the same but it makes sense. I guess I hoped the necessary pins were exposed somehow on the board.

The image you have is an older model compared to the one I have. Fortunately with some patience and a multimeter I found R58 and IO12, as you can see in this image.

T-Beam T22_V1.1 20191212 IO12
T-Beam T22_V1.1 20191212 IO121600×1200 224 KB

Note that the version of this board is T22_V1.1 20191212.

I don’t know much about electronics (and maybe neither do you) but do you think I could damage the GPS by using the line as TDI for the debugging process? I think I will be able to solder a wire there for the debugging board.

Even though this seems like the proper way, I don’t think I have the resources or the knowledge to do it, but I appreciate the comment :slight_smile:

5

If R58 is removed and IO12 is directly connected to the debugger it leaves the GPS module completely alone, it just never receives any UART data then for control. If it’s still connected to the module and the module is being debugged the GPS module will see weird high-speed data that it will try to interprete, but fail – but it should not break the module. The UART RX is an input anyways, so it should be be externally drivable.

6

Perfect, I’ll update the post with the results.

However, I think the docs page should be updated. Listing the debug boards without a You’ll have do do sketchy things notice is quite misleading. Maybe it’s better to wait and see if I’m successful to update it properly

7

In this case yes, remember the docs are auto-generated based purely on the fact that it’s an ESP32 board for which we have all these debugging tools available – they don’t look per board if the hardware was screwed up in such a way that you don’t have the debugging pins available (without mods). I can open an issue for that. Edit: Open per Add notes to boards which need hardware modifications to be debuggable · Issue #523 · platformio/platform-espressif32 · GitHub.

8

Well, I ended up soldering a cable in IO12 as shown in the picture without removing R58 and it seems that there are no shorts. However, I’m having some issues when I try to debug a simple “Hello World” script.

Processing ttgo-t-beam (platform: espressif32; board: ttgo-t-beam; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/ttgo-t-beam.html
PLATFORM: Espressif 32 (3.1.1) > TTGO T-Beam
HARDWARE: ESP32 240MHz, 1.25MB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
 - framework-arduinoespressif32 3.10005.210308 (1.0.5)
 - tool-esptoolpy 1.30000.201119 (3.0.0)
 - tool-openocd-esp32 2.1000.20201202 (10.0)
 - toolchain-xtensa32 2.50200.97 (5.2.0)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 28 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Compiling .pio/build/ttgo-t-beam/src/main.cpp.o
Generating partitions .pio/build/ttgo-t-beam/partitions.bin
Archiving .pio/build/ttgo-t-beam/libFrameworkArduinoVariant.a
Indexing .pio/build/ttgo-t-beam/libFrameworkArduinoVariant.a
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/Esp.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/FunctionalInterrupt.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/HardwareSerial.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/IPAddress.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/IPv6Address.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/MD5Builder.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/Print.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/Stream.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/StreamString.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/WMath.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/WString.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/base64.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/cbuf.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-adc.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-bt.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-cpu.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-dac.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-gpio.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-i2c.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-ledc.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-log.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-matrix.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-misc.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-psram.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-rmt.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-sigmadelta.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-spi.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-time.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-timer.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-touch.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/esp32-hal-uart.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/libb64/cdecode.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/libb64/cencode.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/main.cpp.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/stdlib_noniso.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/wiring_pulse.c.o
Compiling .pio/build/ttgo-t-beam/FrameworkArduino/wiring_shift.c.o
Archiving .pio/build/ttgo-t-beam/libFrameworkArduino.a
Indexing .pio/build/ttgo-t-beam/libFrameworkArduino.a
Linking .pio/build/ttgo-t-beam/firmware.elf
Retrieving maximum program size .pio/build/ttgo-t-beam/firmware.elf
Checking size .pio/build/ttgo-t-beam/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   1.0% (used 13684 bytes from 1310720 bytes)
Flash: [==        ]  20.8% (used 272802 bytes from 1310720 bytes)
Building .pio/build/ttgo-t-beam/firmware.bin
esptool.py v3.0
========================= [SUCCESS] Took 13.80 seconds =========================
Reading symbols from /home/USER/Documents/PlatformIO/Projects/Simple/.pio/build/ttgo-t-beam/firmware.elf...
done.
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = esp-prog
PlatformIO: Initializing remote target...
Open On-Chip Debugger  v0.10.0-esp32-20201202 (2020-12-02-17:38)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 20000 kHz

WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
Info : FreeRTOS creation
Info : FreeRTOS creation
adapter speed: 5000 kHz

Info : tcl server disabled
Info : telnet server disabled
Error: libusb_claim_interface() failed with LIBUSB_ERROR_BUSY
Error: unable to open ftdi device with vid 0403, pid 6010, description '*', serial '*' at bus location '*'
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6014, description '*', serial '*' at bus location '*'

openocd: ../src/jtag/core.c:343: jtag_checks: Assertion `jtag_trst == 0' failed.
Aborted (core dumped)
.pioinit:11: Error in sourced command file:
Remote communication error.  Target disconnected.: Connection reset by peer.

I tried to look on the internet for the last lines, but libusb_claim_interface() failed with LIBUSB_ERROR_BUSY doesn’t mean anything to me and I can’t think of a reason why it should be busy. I’ve tried to restart VSCode but nothing changes.

In addition, here’s the relevant output for lsusb

USER@HOST:~$ lsusb | grep UART
Bus 001 Device 023: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 001 Device 026: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC

Which makes the error unable to open ftdi device with vid 0403, pid 6014... make sense but not for the 6010. (Note that I downloaded and applied the udev rules some hours ago)

As for Assertion 'jtag_trst == 0' failed. I’ve found this SE post that mentions that I need to use the TRST pin if it exists, but I haven’t been able to fin it in the schematic. While at the same time the question mentions that this pin is optional.

I’m a little bit at loss and I’m not sure what’s actually wrong or what else should I check

9

I’ve seen this error too when I hand-wired my ESP32 to my FT232H board – in that case I had a long wire connected to the reset pin (but not connected to anything else on the other line). It seems that the OpenOCD code still tries to check the voltage on the TRST line although it is mentioned in

that it is not used (reset_config none).

This also says the same.

A general countermeasure is also to lower the JTAG speed by writing e.g.

debug_speed = 500

in the platformio.ini.

10

Well, seems that I found the solution. The pads weren’t properly soldered and they weren’t making contact to the board, thus the errors. I realized this when I found another ESP32 board and tested de debugger and everything worked and the red light of the ESP-Prog lightened up without being connected to the computer, something that it didn’t do when I was using the T-Beam. In addition I also found a GND pad that is not connected to ground and I was using that one as well.

I’ll do a more detailed guide in the next days and mark that as the solution in case someone has the same problems or the docs want to be updated.

Thanks a lot, @maxgerhardt :tada:

1 Like
11

TL;DR: Some soldering is needed, use another board if you have the chance.

Remember to install all the necessary tools needed for debugging as if it was any other board. Those steps are not covered here.

As mentioned in the discussion the pin 12 needed for the JTAG debugger is not exposed but it’s possible to solder a wire or use one of these tools to properly expose the pin in order to use the debugger.

When doing the soldering, the best position to solder a wire is in the green rectangle, as seen in the image below. Note that this specific layout is only present on some versions. Mine is a T22_V1.1 20191212.

T-Beam IO12
T-Beam IO121600×1200 286 KB

However, as other comments mentioned in this thread, different boards have different layouts and from experience, the resistor nearest to the LoRa Module is R58, the one you are looking for. However, some boards don’t have that extra space next to the resistor as seen in the image and you’ll have to do the soldering on the same pad as the resistor, which is not ideal

Troubleshooting

I had some issues with the connectivity of the wires. Make sure all the cables are properly connected or soldered and have contact with the pads.

Even though it’s difficult to believe, unplugging both boards and plugging them again solves some issues that I believe have to do by the computer thinking the board is the debugger and vice-versa, so try that