Flashing runs ok, ends without any errors. So I removed gnd from IO0, restarted module and… nothing. Esphomeflasher shows as log output something strange, like module is still waiting for flashing or so.
What is wrong here? Seems, flashing is ok, but why this load can’t work? Any additional pin should be pulled up or down? I though about EN, but it looks, they are pulled up internally (there is 3,2V on both).
And one thing more, maybe it matters: according to my experience with ESP12, it shouldn’t be possible to flash module without grounding GPIO0. Here should be the same, isn’t it? I’m asking because as I discovered, my flasher (ESPHomeFlasher) is able to flash module with grounded IO0 or without, when this pin has a high state (verified by multimeter). It looks like my module is in permanent flashing mode…
Interesting, why? I just connected it, flashed and started to experience this problem.
Is any way to exit from this mode? I doc I found description of pin “cfg” - pulling down this pin during startup should restore factory settings - what do you think?
But how? It is ETH module, “over air” is impossible. Over ethernet - don’t see any DHCP activity here.
I had this issue when only powering from the flashing dongle.
I connected a 5V supply to the 5V on the board and an ethernet cable and it was discovered right away in HA ( obviously adding api:)
Do you need to add the logger: ?
I added manual IP too
I did need to connect IO0 to flash
It does look like GPIO0 is still low.
IO0 only has to be low at power-up to go into the flash mode. It does not have to remain low during the flashing.
Remove the ground from IO0 and reset/restart the board. Don’t count on the UART to do this for you.
It can be a clue, my first run was also with power from uart converter. But next few tries I made with external PSU. IO0: I operated it manually and tried both options, with removing GND short after power up and with left GND here - no differences. Tomorrow I’ll try this reset to factory and try to repeat whole operation.
Yet, I tried still today. And unfortunately, still the same results. Tried “CFG” pin (according to datasheet I started module with CFG pulled down and waited a minute - no visible effects on console, the same behavior of module after).
Regarding IO0 - yes, it looks like this pin would be still low. But it isn’t, after flashing I ever tried to restart module with this pin pulled up by resistor, also I checked by multimeter this port direct on ESP32 - it is up. I have no more ideas. Only use big hammer and then buy new module
Is it possible you’re trying to assign GPIO pins that are reserved by that microprocessor model for other purposes? This is often the cause of power-up reset loops. https://files.seeedstudio.com/products/102991455/WT32-ETH01_datasheet_V1.1-%20en.pdf Check pages 8 and 9 of the PDF.
And in saying “OTA” mode, I erred. I should have said ‘recovery’ mode instead. When the code fails to boot successfully several times, it boots a minimal recovery config that allows flashing from the Ethernet port, whether it’s wireless or wired.
But I haven’t any other connections, only power, Rx, Tx and IO0. And GND for uart and for power of course.
Regarding such recovery mode - yesterday I tried to google for such mode, but found nothing. Do you know any details, how it works and how to exit?
It looks that the only possible communication here is still via rx/tx pins, ethernet is not working, even with fixed IP.
Yesterday I wrote about hammer as a last solution, but I have other idea: replace ESP32 module. I have few wroom modules, maybe it will work?
