Raspberry Pi JTAG

[bbx10node]

I used this https://github.com/espressif/esp-idf/bl ... penocd.rst to setup openocd on a Raspberry Pi 2. I do not have a JTAG dongle so I am trying the RasPi bit bang method.

The RasPi connected to an Arduino Due via JTAG works fine. I used JTAG on a Due before so I used the Due to make sure the RasPi side works. I followed the two guides below.

https://github.com/synthetos/PiOCD/wiki ... TAG-Dongle
https://learn.adafruit.com/programming- ... pberry-pi/

Next I connected up the ESP32 dev board. The ESP32 shows a lot of errors but it is tantalizingly close. If I can get this to work, I
will post my notes.

Does the app have to enable/map JTAG pins? The app in the ESP32 is the 01_hello_world app. I suspect this is true because if the ESP32 runs the app, JTAG does not work at all. openocd reports all ones for the device ID. But if the ESP32 is in bootload mode, openocd shows the trace below.

I am using the following pins for JTAG. Are the signals mapped elsewhere when FreeRTOS boots up?

Code: Select all

ESP32   ESP32
Pin     Name
13      MTCK 
14      MTMS 
15      MTDO 
12      MTDI 

I tried 100K pull ups to 3V3 on MTCK, MTMS, and MTDI because the Due schematic has them. But this does not make any difference.

I am trying to borrow a J-Link but it might be a week or more, if I get it at all. Perhaps the ESP does not like bit bang JTAG signals.

Thanks!

Code: Select all

$ sudo ./src/openocd -s ./tcl -f ./esp32.cfg
Open On-Chip Debugger 0.10.0-dev-g7790403-dirty (2016-10-01-14:12)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
BCM2835 GPIO nums: swclk = 25, swdio = 24
BCM2835 GPIO config: srst = 18
srst_only separate srst_gates_jtag srst_push_pull connect_deassert_srst
adapter speed: 200 kHz
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG and SWD modes enabled
Info : clock speed 200 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)
Error: esp32.cpu0: IR capture error; saw 0x10 not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : esp32.cpu1: Debug controller was reset (pwrstat=0xFF, after clear 0x40).
Info : esp32.cpu1: Core was reset (pwrstat=0xFF, after clear 0x40).
Error: esp32.cpu1: esp108_fetch_all_regs (line 649): DSR (FFFF7FFD) indicates target still busy!
Error: esp32.cpu1: esp108_fetch_all_regs (line 649): DSR (FFFF7FFD) indicates DIR instruction generated an overrun!
Error: Exception reading fsr!

Info : esp32.cpu1: Target halted, pc=0x00000000
esp32.cpu1: target state: halted
Info : esp32.cpu0: Debug controller was reset (pwrstat=0x4A, after clear 0xFE).
Error: Exception reading ps!

Info : esp32.cpu0: Target halted, pc=0x00000000
esp32.cpu0: target state: halted
Info : esp32.cpu0: Debug controller was reset (pwrstat=0xF0, after clear 0x0E).
Info : esp32.cpu0: Core was reset (pwrstat=0xF0, after clear 0x0E).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0x4E, after clear 0x83).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0xFD, after clear 0x54).
Info : esp32.cpu0: Core was reset (pwrstat=0xFD, after clear 0x54).
Error: esp32.cpu1: esp108_fetch_all_regs (line 673): DSR (FFFF7EFF) indicates target still busy!
Error: esp32.cpu1: esp108_fetch_all_regs (line 673): DSR (FFFF7EFF) indicates DIR instruction generated an exception!
Error: esp32.cpu1: esp108_fetch_all_regs (line 673): DSR (FFFF7EFF) indicates DIR instruction generated an overrun!
Error: Exception reading pc!

Info : esp32.cpu1: Target halted, pc=0x00000000
esp32.cpu1: target state: halted

[ESP_Sprite]

The app does not have to enable JTAG, but it can disable it by configuring the GPIOs the JTAG port uses as something else. You indeed seem to be pretty close... but it looks like there's too much capacitance or something in your cables. Can you run JTAG slower? Normally, I think OpenOCD does that with adapter_khz. Fyi, 200 works fine for me there, but I think I had 1000 working as well. You may try to lower it to eg 10 to make absolutely sure your cabling doesn't interfere. (And as I said, I'm not sure the bitbang driver supports it at all.)

[bbx10node]

Thanks, I tried 100 and 50 kHz and removed the 100K pull ups. But spontaneous core and debug controller resets still occur. I made two changes so openocd can now get device IDs reliably.

1. On the RasPi2, I switched from USB WiFi to Ethernet. Having two WiFi radios a few inches apart seems like a bad idea.

2. A friend pointed out boards connected with more than one path to mains power is very bad. I had the ESP32 dev board connected via USB to a desktop computer and connected via JTAG to the RasPi which has it own AC adapter. I am not entirely sure what ground loops are but I have been warned they cause havoc on hardware. The ESP32 is now powered via a RasPi USB port so the desktop is no longer connected. I am not planning on compiling on the RasPi (too slow) so I will find a better solution. But openocd can now reliably get the device IDs when running an app.

Code: Select all

> reset halt
JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
esp32.cpu0: Core was reset (pwrstat=0x1F, after clear 0x0F).
esp32.cpu0: Target halted, pc=0x40000400
esp32.cpu0: target state: halted
esp32.cpu1: Core was reset (pwrstat=0x1F, after clear 0x0F).
esp32.cpu1: Target halted, pc=0x40000400
esp32.cpu1: target state: halted

[bbx10node]

Summary: I was never able to completely solve the random resets using the Raspberry Pi 2.

I purchased an FT2232 JTAG board (TIAO) which works fine.

[ESP_Sprite]

Thanks for updating. And weird; afaik there's nothing that should make debugging using the Pi impossible. We have at least building a toolchain for the Pi on our list of things to do: I'll also see if I can investigate what went wrong with your setup and perhaps create a known-to-work setup recipe.