Erase_flash fails on RPI in strange way

[zliudr]

I've been able to flash and erase flash with the esptool.py I copied from IDF V4.3 beta-1 on RPI just fine until now. I was able to erase flash and program but now I can't do either. With the same programmer and same device board, I could program and erase on my pc running windows and a linux laptop.

I chased the issue down to my latest firmware. This firmware has turned off all debug prints so only first stage bootloader has a few lines of print. This it spawns a console to accept commands. I wonder if it is because RPI 4B is too slow and not printing debug info makes esp32 boot too fast and esptool.py runs too slowly and misses the window of opportunity to talk to the bootloader (first or second stage?) so this doesn't work. If I erase the device on a pc, then I can successfully erase it over and over on RPI and flash program to it. But once I flash my program, rpi can't flash or erase anymore. I have to use my PCs.

Any idea if this is a timing issue of RPI4B running too slow?

[zliudr]

I checked the timing of asserting DTR (L) and de-asserting RTS (H) right before the bootloader kicks in. For my win10 computer the timing is 0.13ms. For my slow RPIOS laptop it was 0.23ms but for my RPI4B it was 0.43ms. This part may be crucial because we're enabling ESP32 and pulling GPIO0 to low "at the same time". If first stage bootloader reads GPIO0 before it is set to low, then it boots the rest and no DOWNLOAD_BOOT. This timing may only be important when you disable console logs everywhere and the timing of boot is slightly faster I guess.

So is there any mode of esptool.py that will directly take say DTR connected to GPIO0 and RTS connected to EN so it would be able to more directly manipulate the lines?
I imagine the timing was done with some hi-res timer in python but the non-working RPI4B has 3.7.3 and working RPIOS laptop has 3.5.3 so I thought higher version should have less issues.

[ESP_Sprite]

The timing is actually dependent on hardware, drivers etc, not so much on the python program. As a workaround, you could try connecting an 1uF capacitor between the EN and GND pins of the ESP32.

[zliudr]

ESP_Sprite,

Thanks. I agree with you, the timing depends on the host computer and driver because Python is too high-level to do anything about it. With python, running this will be the fastest you can do with toggling both pins in sequence:
port.dtr=True;port.rts=True

I ran this in a loop and used my USB protocol analyzer to probe 3 separate systems, my main computer with win 10 and fast processor (supposed to be bettern chipset) averages 0.13ms, my slow speed celeron dual core laptop running RPI OS averages 0.23ms, and RPI4B averages 0.43ms, the slowest. I guess not every driver/hardware is made the same. My RPI OS laptop and RPI4B should have the same source code of FTDI drivers but could have compiled very differently on different architectures. Anyway, I guess there's no way to have esptool.py directly manipulate DTR to GPIO0 and RTS to EN instead of via the transistors?

[ESP_Sprite]

It's been a while, but I think you actually can, and esptool will try some ways to get the device into download mode. The issue with connecting everything directly is in 'other' terminal programs that don't always have a standard way of setting DTR/DSR: you may run into some that e.g. will lower them, causing the ESP32 to be locked up in reset.

[zliudr]

Thanks. I've made my own programming jigs to mass flash and provision devices for production. I'm not dealing with development boards etc and my device has no npn transistors. They are on the programmers or jigs. If I make my jigs to contain no transistor and properly run esptool.py to directly drive DTR and RTS lines for GPIO0 and EN, then I'll be fine. I can still use normal development board way of esptool.py when I use programmers that do contain npn transistors.

But I see no such option to alter the behaviors of DTR and RTS. There are options of before and after but I don't now if those are the options. Not sure about soft vs hard reset either. Could you provide a pointer where I should be looking?

I tested on my PC that when Python opens port, it asserts both DTR and RTS. So the board is in RESET state and all esptool.py has to do is to de-assert RTS to enter programming mode, right? Is that the --before no_reset? no_reset_no_sync?

[ESP_Angus]

If I make my jigs to contain no transistor and properly run esptool.py to directly drive DTR and RTS lines for GPIO0 and EN, then I'll be fine. I can still use normal development board way of esptool.py when I use programmers that do contain npn transistors.

But I see no such option to alter the behaviors of DTR and RTS. There are options of before and after but I don't now if those are the options. Not sure about soft vs hard reset either. Could you provide a pointer where I should be looking?

I tested on my PC that when Python opens port, it asserts both DTR and RTS. So the board is in RESET state and all esptool.py has to do is to de-assert RTS to enter programming mode, right? Is that the --before no_reset? no_reset_no_sync?

You should be able to wire RTS and DTR directly to EN and GPIO0 and both esptool.py and ESP-IDF monitor tool will work with no other changes (and other serial programs will work if you configure them to de-assert DTR & RTS).

Some hook functions were recently added to esptool.py to allow overriding the reset behaviour in the code more easily. But in this case, if I understand correctly, then you shouldn't need to change anything.

There's a bit more about this topic written here:
https://github.com/espressif/esptool/wi ... -Selection