VSCODE: purchased Wrover-kit, serial flashing does not work and JTAG flash/debug does not work

[espdorian]

After many attempts to get JTAG debugging working with a Lyra-T board, I bought a Wrover-kit, which has on board JTAG. This to rule out any hardware issues which might exist in my Lyra-T setup. Unfortunately again issues. When attempting to flash the 'blink' application serially from VSCODE:

$ H:\.espressif\python_env\idf4.2_py3.9_env\Scripts\python.exe
esptool.py v3.0
Serial port COM22
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: a8:03:2a:ec:00:30
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Compressed 3072 bytes to 103...

A fatal error occurred: Timed out waiting for packet content
The terminal process terminated with exit code: 2.

When attempting to flash using JTAG (lastest OpenOcd)
"Failed to flash the device (JTag), please try again [got response: 'invalid command name "program_esp_bins"', expecting: '0']

After deleting my 'blink' project from disk and doing a new "create project from blink example" I was able to serially flash it.
Then pressed F5 it started the debugger, stopped at a breakpoint and I could single step.

I was, hoever not able to stop the debugger and needed to exit VScode. Tried again.. behaviour seems inconsistent, sometimes I ams able to start debugging, sometimes I am able to flash. And often I see the serial flash error as listen above.
It seems to recover from that state is to power off the board and exit VScode.

Unable to et JTAG flashing working and today it happened again. Updated my settings.json for a new openOCD version and 15 minutes later it as changed back again. Is the IDF extension doing this ?

I really do appreciate the efffort the Espressif guys put into it, but sometimes I really wonder of anything has been tested
on a 'clean' Windows system.

[ESP_bignacio]

Hey @espdorian What is the value of idf.openOcdConfigs also called List of configuration files inside OpenOCD Scripts directory in Preferences: Open Settings (UI) ?

[ESP_Roland]

The communication with esptool seems to be normal (chip detection, stub upload) up until flash detection. "(FlashID=0xffffff, SizeID=0xff" usually indicates some kind of hardware issue with the connected flash. Have you connected anything to your wrover kit?

You may try to run "esptool.py flash_id" with the latest esptool from https://github.com/espressif/esptool to see if you get the same result. I think you will.

[ESP_Roland]

One more thing. TDI is GPIO12 which is also a strapping ping which selects between 1.8 or 3.3V flash voltage. It may cause flash failure.

Please try to disconnect the JTAG pins before running esptool. Of course, flashing should work even when they are connected. Please check the connections (at least jumper setup) based on the documentation of the board.

[espdorian]

@ESP_roland and @ESP_bignacio

First thank you for yor replies. I will try to answer most of the questions from both here.

What is the value of idf.openOcdConfigs also called List of configuration files inside OpenOCD Scripts directory in Preferences: Open Settings (UI) ?

There is no: idf.openOcdConfigs, only the following idf related entries:
"idf.telemetry", "idf.espIdfPathWin", "idf.customExtraPaths", "idf.customExtraVars", "idf.pythonBinPathWin"

Have you connected anything to your wrover kit?

Board is new from the package. Nothing connected except single USB cable. The only jumpers which are fitted are:
- Power from USB, not from ext
- JP2 RXD/TXD
- JP2 TMS, TDO, TDI, TCK

You may try to run "esptool.py flash_id" with the latest esptool from https://github.com/espressif/esptool to see if you get the same result. I think you will.

First result (left out some none relevant parts):

Code: Select all

esptool.py v3.1-dev
Serial port COM22
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
Uploading stub...
Running stub...
Stub running...
Manufacturer: ff
Device: ffff
Detected flash size: Unknown
Hard resetting via RTS pin...

Then removed the JTAG jumpers and tried again:

Code: Select all

...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

Strange, because I was able to perform serial flashing from Eclipse, so I re-installed the JTAG jumpers.
Then tried several times, it didn't fail. After that could flash from VScode without any problem.

In that case it must have something to do with JTAG in combination with OpenOCD/VScode, because the only thing done
with removing and re-installing the JTAG jumpers was, power disconnect (without using VScode)

Then tried to reproduce it with VScode:

- Power up board -> flash detected
- Start Openocd server -> flash not detected
- Stop Openocd server -> flash not detected
The only way to recover from this situation is power down the board.

Measured the JTAG signals with scope 'before starting' and 'after stopping' Openocd (nothing in between only start/stop)

Code: Select all

Signal          Before          After
TMS             3V3               0V  
TDO             3V3               3V3 
TDI             1V0               3V3 
TCK             3V3               0V 

TDI is GPIO12 which is also a strapping ping which selects between 1.8 or 3.3V flash voltage.

If Openocd does not reset the state of TDI and performs a device reset, the flash voltage might be incorrect ?

So the issue why flashing is not working is getting more clear. Next is to find out why JTAG debugging (and flashing, can be related to TDI state after reset ?).

[ESP_Roland]

I'm happy that you are getting closer to solve this. Please also check this: https://docs.espressif.com/projects/esp ... figuration. It might help you.

[ESP_bignacio]

If idf.openOcdConfigs is missing, it might be the issue.
As shown in Configuration settings Board Specific settings idf.openOcdConfigs specifies the configuration files used by openOCD to communicate with your board.

In Visual Studio Code extension, when you use Select OpenOCD Board Configuration command or Set Espressif device target command this configuration setting is set to a value like:

idf.openOcdConfigs: ["interface/ftdi/esp32_devkitj_v1.cfg", "board/esp32-wrover.cfg"]

for ESP32 for example.

[espdorian]

When trying to find out the correct flash voltage for the board, I looked into several datasheets and forum posts. It is seems not specified within the electrical specifications but somewhere 'hidden' within the text.

I found the WROVER (without extension) requires 1.8V and the WROVER-B, WROVER-E, WROVER-IE requires 3.3V
Is this correct, or are there exceptions/other versions ?

This brings me to another issue. In one of my earlier posts in this thread, I mentioned a scope showed approx. 1V for the TDI pin after boot. (strap for flash voltage). Since this a a rather strange level, I investigated this.

Measured it again using a multimeter, which shows 0.88V (TDI jumper mounted) For the WROVER-E with 3.3V flash it should be low level after/during reset. The ESP32 has an internal weak pull down, it seems however the FTDI232H has an internal pull up on its ADBUS pins (which are bi-directional and input after reset) . I could not find this in the FTDI232H datasheet, but after removing the TDI jumper the voltage dropped to 0, so the FTDI232H clearly has a weak pull-up causing the 0.88V.

VILmax and VIHmin for the ESP32 are 0.25*Vdd and 0.75*Vdd, which is 0.825V and 2.48V respectively based on 3.3V

From this we can conclude that a WROVER kit, with the TDI jumper mounted (and JTAG not used yet) has an undetermined level at its MTDI strapping pin, which might result in unpredictable behaviour.

Note: If this pull-up in the FT232H is also not taken into account with the Espressif JTAG interface and other development boards, then this might cause unpredictable behaviour as well (I need to check my setup with the Lyra-T for this) .

Adding a 22k resistor between TDI and ground brings down the level to 0.4V , which is within the limits for the ESP32.

With a little bit of creativity A 0603 SMD resistor can be soldered diagonally between R50(GND) and R54(TDI) on the WROVER kit.

Besides this, imho it is still incorrect that openOCD does not return the pin state to the initial condition upon shutdown.
Don't know yet if this is openOCD related, or related to the Espressif openOCD port.

I still need to check if another board config, solves the TDI pin state after openOCD disable.
To be continued.....

[espdorian]

The story continues,

Added pulldown resistor to TDI and added:

Code: Select all

"idf.openOcdConfigs" : ["board/esp32-wrover-kit-3.3v.cfg"] 

to settings.JSON as ESP_bignacio pointed out.

This clearly improved consistency: flashing now always works. However debugging is still a bit weird, I noticed the following bahaviour:

- After VScode is started I press F5 (debug) Note: the board is already flashed with the corrrect binary.
- It just starts to run the application, shows the debug toolbar, but it does not stop on any breakpoint.
- I first have to flash it using serial (it starts executing) and if I then press F5, it stops on a breakpoint and single stepping is possible.

When stopping debugging (Red/orange square in the toolbar) and pressing F5 again, it starts executing (but does not stop on any breakpoint). Basically it seems to be running without the debugger. Then flash (flame button at the bottom) folllowed by F5 results in a working debug session.

Sometimes it ends up in a situation where it is not possible to terminate the debug session (only quitting VScode and disconnecting the board helps). I do not know yet how to reproduce.

So there is still something not completely correct here.

[ESP_bignacio]

In your project's/.vscode/launch.json set logLevel:5 to increase output logs in debug console as shown in debugging.md.

Any error on your project's debug.log or in the debug console or in openOCD ?