After flashing cannot enter to programming even Repl does not answer

[Erkman84]

Hi there,

This issue is as I wrote in the wrong queue: espressif/esptool#785

I am not new to micropython (esp boards, I've flashed, and get to work 2-3 types of esp boards and they work like a charm).

But I've tried new boards, e.x. Wemos D1 mini light (the causal old basic version works also without any issues, and this is true also for D1 mini pro). I use raspberry and it's OS for flashing/programming, with a high quality usb cable, other boards works fine so this is not a question here.
After flashing (after > 20 tries with combining baud rates, -fm dout, dio, 0x0, and so on) and used also -- verify says, that flashing is okay on all boards, ends like it used to... hard resetting via rts PIN
and
try to enter (via USB on the same way like flashing) the Micropython repl but I have no input method (=no reaction of any button, i cannot import any module, because when I hit the keyboard nothing happens). I use picocom for this purpose (and works for other esp boards well), but it seems it is gone freez or something. Reseting replug de device does not help.
Okay, mayb repl does not answer, what happens when I upload boot.py or main.py with ampy (like I did a lot of times on other boards): nothing, I have to interrupt it after waiting a while. I get an err msg like: no answer from device or something else.

Okay, maybe there must be a hack: pull GPIO 0 to GND (low), GPIO 2 to high (3,3V) found this: https://www.instructables.com/ESP8266-Using-GPIO0-GPIO2-as-inputs/

And tried the old way via USB TTL also, there is no answer. And an earlier version of micropython 1.10, 1.16 and 1.18 (this is one I played a lot recently).
On the 1.19 it does not work either.

So it seems after flashing mode, I don't get into boot or programming mode, and I do not know why.

Nothing helps.
My new ESP C3 board, Wemos D1 mini light (or V2), Lillygo T-Call 1,4 and 1,5 (not the 1,3V this works like a charm) have the same issue.
I played with the wemos d1 mini because this is the simplest one, so if I cannot solve this at this, I won't solve on the others.

[robert-hh]

The Wemos D1 mini lite has only 1MB of flash. So you have to use the 1MB versions of the firmware.

[Erkman84]

Okay, maybe Im not very clear: it is not a wemos d1 mini lite, it is a wemos d1 mini V2 or V3 with 4MB. Please just forget the wemos d1 mini lite...

So what is your idea in this case?
And I wrote: also a ESP32-C3 board is affected, and a ESP 32 T-call 1.4 and 1.5 (the 1.3 older version works as it should be after flashing).

[Erkman84]

So it seems newer boards fails after flashing. But this is not what I've expected... what is the trick?

[scruss]

Okay, maybe Im not very clear: it is not a wemos d1 mini lite, it is a wemos d1 mini V2 or V3 with 4MB. Please just forget the wemos d1 mini lite...

Please tell us exactly the command lines you are using with esptool.py. You didn't include it in the esptool report, and the maintainers have closed your issue because it was incomplete. ESP32s use a different command line and MicroPython image from ESP8266, and ESP32-C3 use a different command line from ESP32.

For a D1 Mini v4 bought from the official LOLIN store, this is what I would do, based on Getting started with MicroPython on the ESP8266. Note that on my Linux machine the board is on serial port /dev/ttyUSB2, and yours probably won't be:

Erase flash

esptool.py --port /dev/ttyUSB2 erase_flash
esptool.py v4.1
Serial port /dev/ttyUSB2
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: c4:5b:be:df:67:62
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 0.1s
Hard resetting via RTS pin...

Upload image

This is from the ESP8266 with 2MiB+ flash download page, and I'm using the latest stable release, esp8266-20220618-v1.19.1.bin

esptool.py --port /dev/ttyUSB2 --baud 460800 write_flash --flash_size=detect 0 esp8266-20220618-v1.19.1.bin
esptool.py v4.1
Serial port /dev/ttyUSB2
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: c4:5b:be:df:67:62
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00000000 to 0x0009afff...
Flash params set to 0x0040
Compressed 634844 bytes to 419808...
Wrote 634844 bytes (419808 compressed) at 0x00000000 in 37.4 seconds (effective 136.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Run check

In a serial terminal window (I used screen /dev/ttyUSB2 115200) or in Thonny, hitting return in the shell window gives me the

>>> 

MicroPython prompt. If I hit Ctrl + D to soft-boot the board at this prompt, I see:

MPY: soft reboot
MicroPython v1.19.1 on 2022-06-18; ESP module with ESP8266
Type "help()" for more information.
>>> 

For your ESP32 boards, the various esp32 download pages have installation instructions specific to each processor type.

[Erkman84]

Hi, sorry, for the late update, so there are good news: if I have and esp device wich CH.... USB controller, then I have this errors. This has nothing to do with the flashing. I've bougth another versions (the same D1 minis) with other usb chip controller, ex FP 232 (or something else), and BAAANG: the Repl is working as it should.

So how everything with a CH... driver is very complex in using, repl works only in Arduiono IDLE with catride return and new line mode.
For upload scripts there is a special program made by somebody, there you can upload devices.
For testing these kind of boards with this drivers arent good, but I won't recycle them, the mentioned workaround works, but I have no time now.

So CH340, or CH9XX end everything which have CH drivers are for micropython 'unuseable'. That's all.

Next time when I buy something from Ali then I look at the chipset driver and check it, before buying it. (the normal chipset drivers are a little more expensive, but it is worth)

[scruss]

Glad you've worked the issue out, but your experience with CH341 chips does not mirror mine. If you're using Windows or Mac OS (especially on Apple Silicon) you will probably need the proper driver for these.

With the global chip shortage, serial driver chips have suddenly become a free-for-all. I have no idea what's going to show up on new boards, even from reputable vendors. Silicon Labs serial chips have become unobtainable, so WCH have stepped in with their CH9102 pin-compatible chip