Can only flash with manual reset

Panometric
Posts: 14
Joined: Sat Sep 07, 2019 8:09 am

Can only flash with manual reset

Postby Panometric » Sat Sep 07, 2019 8:55 am

My WROVER custom board has an RS-232 serial port rather than USB. I implemented the automatic programming circuit as in https://dl.espressif.com/dl/schematics/ ... _SCH-2.pdf with 2 NPNs, a 12K pullup on EN over 2nF, and a 5 K pullup on GPIO0 over 1nF. In my case GPIO2 is open

What's odd is that the circuit works fine to get the board into flash mode. And you can ID the board and get the MAC. But then the flash id phase fails, and so does the flash write. Those pins are not used in that phase at all.

Log:

Code: Select all

esptool.py v2.6
Serial port com21
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: cc:50:e3:ab:7b:cc
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0x0, SizeID=0x0), defaulting to 4MB
Flash params set to 0x0220
Compressed 28544 bytes to 16277...
Wrote 28544 bytes (16277 compressed) at 0x00001000 in 1.4 seconds (effective 158.6 kbit/s)...

A fatal error occurred: Timed out waiting for packet header

I've debugged into esptool.py, stepped through, and both IOs seem to be doing exactly what they should. And by stepping through, I've slowed it down so the cap values and delays in the code should not be relevant.

I realize now that V2 may not have been the best model, since these circuits have changed. But I can't see why what I'm measuring does not work.

There is apparently some black magic with this pins. Why isn't what's depicted here working?

Is it just not reliable like: https://esp32.com/viewtopic.php?f=12&t=12154

Thanks!
Wrover Flash failure from esptool.png
Wrover Flash failure from esptool.png (49.32 KiB) Viewed 3060 times

Panometric
Posts: 14
Joined: Sat Sep 07, 2019 8:09 am

Re: Can only flash with manual reset

Postby Panometric » Mon Sep 09, 2019 5:25 pm

FWIW, I found the issue. RTS and DTR should have been inverted. Using FT_Prog on an FTDI adapter, you can just program the part to invert those outputs to active when low. The difficulty was is in diagnosing when those 2 inputs trip each other through the NPN pair.

Here's what a correct sequence looks like for anyone who might be having the same problem.
Attachments
Wrover Flash Success with RTS and DTR inverted.png
Wrover Flash Success with RTS and DTR inverted.png (42.42 KiB) Viewed 3039 times

Who is online

Users browsing this forum: No registered users and 92 guests