Unable to flash ESP32-WROOM

[motojake]

First off, apologies if this is in the wrong forum. I'm new here and to direct embedded programming (meaning without a devkit or arduino)

Secondly, my hardware and software:

Hardware: ESP-32 WROOM
Debugger: Segger J-Link
Operating System: Windows 10
Programming software: Visual Studio 2017 w/ VisualGDB

Connections:
J-LINK -- ESP32-WROOM
1(VTref) -- 3.3V rail
3(nTRST) -- EN
4(GND) -- GND
5(TDI) -- IO12
7(TMS) -- IO14
9(TCK) -- IO13
11(RTCK) -- GND
13(TDO) -- IO15

Nothing else is connected to the ESP32-WROOM module.

3.3V and GND are powered by a breadboard power supply adapter and 12V 750mA supply so I don't think there are any current issues.

When attempting to program it, I receive the following message from VisualGDB: "Custom FLASH programming step failed"

The ESP32 seems to be detected, based on the logs. I get the same message whether or not IO0 is held low on boot.

Attached are my openocd logs:

Open On-Chip Debugger 0.9.0 (2017-05-09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag".
To override use 'transport select <transport>'.
adapter speed: 3000 kHz
Info : No device selected, using first device.
Info : J-Link V9 compiled Apr 22 2016 11:47:06
Info : Hardware version: 9.30
Info : VTarget = 3.217 V
Info : clock speed 3000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0
x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0
x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32.cpu0: Debug controller was reset (pwrstat=0x5F, aft
er clear 0x0F).
Info : esp32.cpu0: Core was reset (pwrstat=0x5F, after clear 0x0
F).
Info : accepting 'gdb' connection on tcp/3333
Interrupt suppression during single-stepping is now enabled
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0
x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0
x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32.cpu0: Core was reset (pwrstat=0x1F, after clear 0x0
F).
Info : esp32.cpu0: Target halted, pc=0x40000400
Warn : esp32.cpu1: target not halted
in procedure 'reset'
in procedure 'ocd_bouncer'
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:
startup.tcl", line 248
in procedure 'esp32.cpu0' called at file "embedded:startup.tcl",
line 349
in procedure 'ocd_bouncer'

esp32.cpu0: target state: halted
Target did not halt within 5000 msec

Info : esp32.cpu0: Target halted, pc=0x40090DF8
esp32.cpu0: target state: halted
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0
x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0
x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32.cpu0: Core was reset (pwrstat=0x1F, after clear 0x0
F).
Info : esp32.cpu0: Target halted, pc=0x40000400
Warn : esp32.cpu1: target not halted
in procedure 'reset'
in procedure 'ocd_bouncer'
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:
startup.tcl", line 248
in procedure 'esp32.cpu0' called at file "embedded:startup.tcl",
line 349
in procedure 'ocd_bouncer'

esp32.cpu0: target state: halted
Target did not halt within 5000 msec

Info : esp32.cpu0: Target halted, pc=0x40090DF8
esp32.cpu0: target state: halted
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0
x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0
x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32.cpu0: Core was reset (pwrstat=0x1F, after clear 0x0
F).
Info : esp32.cpu0: Target halted, pc=0x40000400
Warn : esp32.cpu1: target not halted
in procedure 'reset'
in procedure 'ocd_bouncer'
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:
startup.tcl", line 248
in procedure 'esp32.cpu0' called at file "embedded:startup.tcl",
line 349
in procedure 'ocd_bouncer'

esp32.cpu0: target state: halted

If it's worth adding, I have been able to program the DevkitC using this programmer in the past, however I have not attempted to with another ESP32-WROOM module yet.

[ESP_igrr]

There are two implementations of flashing over JTAG now, one provided by VisualGDB and one provided in openocd-esp32 by Espressif. In this case you may get more relevant replies from the VisualGDB forum.

One thing that does look wrong is the connection between TRST of the JTAG adapter and EN of the ESP32. On ESP32, EN pin acts as a system reset, not JTAG reset, so if OpenOCD is configured to actually use that pin, it may be doing undesired system resets.

[motojake]

There are two implementations of flashing over JTAG now, one provided by VisualGDB and one provided in openocd-esp32 by Espressif. In this case you may get more relevant replies from the VisualGDB forum.

One thing that does look wrong is the connection between TRST of the JTAG adapter and EN of the ESP32. On ESP32, EN pin acts as a system reset, not JTAG reset, so if OpenOCD is configured to actually use that pin, it may be doing undesired system resets.

@ESP_igrr Thanks for the advice, I'll give an ask over there.

Interesting about the EN pin, though. I've been curious about that one since I thought the purpose of the reset was to put it in bootloader mode without having to pull IO0 low on boot.

[ESP_igrr]

When flashing over JTAG, bootloader mode is not required/used. Host software uploads a small bit of code (stub) into target's RAM and runs it. Then the stub communicates with host over JTAG, receives firmware image, and writes it to flash.
The target does need to be reset prior to flashing though. I don't know which method VisualGDB uses, maybe it does involve pulling EN low.

[motojake]

ESP_igrr Thanks for the info! As I said earlier I'm still learning about this stuff so it's great to hear more.

For anyone that may come across this later via google or otherwise: It all works (mostly) correctly after using the new preview build of VisualGDB (VisualGDB 5.3 Preview 8).

Here is the associated thread on the visualgdb forum: https://sysprogs.com/w/forums/topic/una ... p32-wroom/

It continues to flash just fine with or without EN connected to the Segger J-link. I'm not sure if the EN may be required for any other functions, but anyway I can flash just fine with or without it.