Instable work with Olimex-ARM-USB-OCD-H JTAG

[bobik78]

Hi,
I have connected OLIMEX ARM-USB-OCD-H to ESP32_Cover_board_V2 dev.kit.
But when I run openocd it keeps getting endless resets.
Before it I programmed the board with default https://github.com/espressif/esp-idf-template.git application. Looks like some watchdog reset issue. Any solutions?

Openocd printout enclosed:

./src/openocd -s ./tcl -f ./esp32_olimex_arm_usb_ocd_h.cfg
Open On-Chip Debugger 0.10.0-dev-g90071eb-dirty (2017-03-08-15:11)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 2000 kHz
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 1000
force hard breakpoints
Info : clock speed 2000 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.cpu1: Debug controller was reset (pwrstat=0x40, after clear 0x00).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0xE5, after clear 0x0F).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0x40, after clear 0x0F).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0x40, after clear 0x00).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0x72, after clear 0x00).
Info : esp32.cpu1: Core was reset (pwrstat=0x72, after clear 0x00).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0x40, after clear 0x0F).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0xF9, after clear 0x00).
Info : esp32.cpu1: Core was reset (pwrstat=0xF9, after clear 0x00).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0x40, after clear 0x0F).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0x40, after clear 0x0F).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0x40, after clear 0x00).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0xE5, after clear 0x0F).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0x40, after clear 0x00).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0xF9, after clear 0x00).
Info : esp32.cpu1: Core was reset (pwrstat=0xF9, after clear 0x00).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0xF9, after clear 0x00).
Info : esp32.cpu1: Core was reset (pwrstat=0xF9, after clear 0x00).
Info : esp32.cpu0: Debug controller was reset (pwrstat=0xE5, after clear 0x0F).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0x40, after clear 0x00).
Info : esp32.cpu1: Debug controller was reset (pwrstat=0x72, after clear 0x00).
Info : esp32.cpu1: Core was reset (pwrstat=0x72, after clear 0x00).

Thanks,

[projectgus]

Do you have any sample serial console output we can look at?

If you reset the board from inside openocd does it stabilise? (The reason I'm asking this is that by default the ESP32 reads the MTDI pin on reset to determine the flash voltage. If the pin is pulled high, for example by the JTAG adapter, then the flash will initialise at 1.8V, which will brown out the flash on a Core board and cause a reset. You can work around this by resetting from inside openocd (which has hooks to drive the pin low on reset), or you can permanently fix it by running "espefuse.py" (in the components/esptool/esptool-py directory) as espefuse.py set_flash_voltage 3.3V, in which case MTDI will be ignored on reset.

[bobik78]

Hello projectgus,
Thanks for helping me with this issue!

1. Yes, I have a sample serial console, but I don't think this will help:
   I (768) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
   I (768) heap_alloc_caps: At 3FFB6CA0 len 00029360 (164 KiB): DRAM
   I (778) heap_alloc_caps: At 3FFE8000 len 00018000 (96 KiB): D/IRAM
   I (799) heap_alloc_caps: At 40099F04 len 000060FC (24 KiB): IRAM
   I (820) cpu_start: Pro cpu up.
   I (831) cpu_start: Single core mode
   I (844) cpu_start: Pro cpu start user code
   I (904) cpu_start: Starting scheduler on PRO CPU.
   I (1012) wifi: wifi firmware version: 90b1b8b
   I (1012) wifi: config NVS flash: enabled
   I (1012) wifi: config nano formating: disabled
   I (1017) wifi: Init dynamic tx buffer num: 32
   I (1017) wifi: wifi driver task: 3ffbce80, prio:23, stack:3584
   I (1023) wifi: Init static rx buffer num: 10
   I (1026) wifi: Init dynamic rx buffer num: 0
   I (1031) wifi: Init rx ampdu len mblock:7
   I (1034) wifi: Init lldesc rx ampdu entry mblock:4
   I (1039) wifi: wifi power manager task: 0x3ffc2238 prio: 21 stack: 2560
   I (1046) wifi: wifi timer task: 3ffc32c8, prio:22, stack:3584
   I (1084) phy: phy_version: 329, Feb 22 2017, 15:58:07, 0, 0
   I (1085) wifi: Init ampdu: 1
   I (1085) wifi: mode : sta (24:0a:c4:05:e2:e4)

2. Resetting from inside the openocd/gdb didn't solve the issue.

3. Running espefuse.py generated the following error:
   espefuse.py --port /dev/ttyUSB1 set_flash_voltage 3.3V
   usage: espefuse [-h] [--port PORT] [--before {default_reset,no_reset,esp32r1}]
   [--do-not-confirm]
   {dump,summary,burn_efuse,read_protect_efuse,write_protect_efuse,burn_key}
   ...
   espefuse: error: argument operation: invalid choice: 'set_flash_voltage' (choose from 'dump', 'summary', 'burn_efuse', 'read_protect_efuse', 'write_protect_efuse', 'burn_key')

• Do you suggest burning relevant efuses manually?*

Thanks,
Bobik78

[projectgus]

3. Running espefuse.py generated the following error:

Looks like you have an older version of this IDF, this convenience function for flash voltage was only added recently.

I no longer think this is the problem though, if the serial console log you posted is happening at the same time as the resets. I would have expected a constant reset loop, but this just looks like normal boot functionality.

[bobik78]

I have refreshed the IDF version and burned the efuses with the recommended setting of flash voltage.
But this didn't solve the problem.
I also want to mention that the printout on serial console is printed only after power resetting (pressing the reset button the board). Running openocd had no impact on serial print itself. So, it looks like JTAG is completely fail to boot the cpu cores.
What JTAG do you use?

[projectgus]

We have some of these TIAO adapters, which are an FT2232H breakout. Also the ESP-WROVER-KIT board has an FT2232H onboard.

I think I may have also used my Olimex ARM-USB-TINY-H at one point, which is another FT2232H based adapter. Although I'm not 100% certain on that (I don't have access to that adpater right now). I'm also not sure how different that is to the Olimex adapter model you have.

[gojimmypi]

@bobik78 I noticed the adapter speed: 2000 kHz have you tried lowering it?

I have a blog about using the and ESP32 here that might help.

Note that I tie my RTCK to GND, set ESP config to set ESP32_RTOS none, fwiw I also do not srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst or adapter_nsrst_delay: 1000

Here's my Olimex startup that basically works, except for a few oddities in VSCode see: esp-idf/issues/645 and vscode-cpptools/issues/763

Open On-Chip Debugger 0.10.0-dev-g372bb59 (2017-05-19-10:35)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
jtag
force hard breakpoints
Info : clock speed 1000 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.cpu0: Target halted, pc=0x40080E10
Info : accepting 'gdb' connection on tcp/3333

@projectgus from the latest esp-idf esp.cfg file - there's a line for esp108 flashbootstrap 1.8 but from your comment, above - it looks like this should perhaps be: esp108 flashbootstrap 3.3 ?

part of the default file in my /./home/gojimmypi/esp/esp-idf/docs/api-guides/esp32.cfg:

# The TDI pin of ESP32 is also a bootstrap pin that selects the voltage the SPI flash
# chip runs at. When a hard reset happens (e.g. because someone switches the board off
# and on) the ESP32 will use the current TDI value as the bootstrap value because the
# JTAG adapter overrides the pull-up or pull-down resistor that is supposed to do the
# bootstrapping. These lines basically set the idle value of the TDO line to a
# specified value, therefore reducing the chance of a bad bootup due to a bad flash
# voltage greatly.

# Enable this for 1.8V SPI flash
esp108 flashbootstrap 1.8
# Enable this for 3.3V SPI flash
#esp108 flashbootstrap 3.3

[igrr]

there's a line for esp108 flashbootstrap 1.8 but from your comment, above - it looks like this should perhaps be: esp108 flashbootstrap 3.3

That depends on the module which is used on the dev board. Most WROOM modules use 3.3V flash, while WROVER modules use 1.8V flash.

[krzychb]

That depends on the module which is used on the dev board. Most WROOM modules use 3.3V flash, while WROVER modules use 1.8V flash.

What would be the convenient way to check the flash voltage, if we are not sure what particular flash is installed and do not want to desolder module's shield can to check the flash model?

There is a discussion on reading the flash chip model id but not sure if this ended up in providing an API inside ESP-IDF.

[igrr]

Even if we knew flash chip model ID we would still need to find its operating voltage. The only comprehensive database of flash chips i know of is in flashrom, and even it doesn't list the operating voltage.
We could try some auto-probing, but i don't know how reliable it would be.

By the way, we have a cleaner way of overriding flash voltage (in software, via RTC registers) than forcing TDI to a specific state and hoping that the chip will not be reset in the middle of JTAG transaction. But that doesn't help much as we still don't know what the flash voltage should be for the given flash chip.

[gojimmypi]

@igrr I noticed the esp32 config file set this to 3.3V in your WIP .. that change (the setting in the other config was 1.8V), and the recent OpenOCD changes in that branch resulted in a significantly better initial debug excperience in VSCode! (more testing needed). I'm using the Adafruit ESP32_Core_Board_V2.

For more info on my initial experience with the feature/esp32_dualcore branch :

https://gojimmypi.blogspot.com/2017/06/vscode-jtag-debugging-of-esp32-part-3.html

[krzychb]

@bobik78, using recent commit a859564 (of Jul 24, 2017 ) I have checked Olimex ARM-USB-OCD-H together with ESP32_Core_board_V2 and it works without any issues. JTAG wiring is documented in https://esp32.com/viewtopic.php?f=13&t=2525#p12056
Documentation matching above commit is under http://esp-idf.readthedocs.io/en/latest/api-guides/jtag-debugging/index.html
Please check it out with latest s/w and post here, if you still see issues.

[FayeY]

Closing due to lack of response, please feel free to reopen if this is still an issue.