Open TD-er opened 2 years ago
I see a performance decrease when i often do (OTA) upgrades. But for me this was not related how the where flashed. The issues always disappeared after a full flash erase and flashing again. Thats a miracle for me and i have no idea whats the reason is and how it can be solved. A wild guess, maybe the wifi calibration is "damaged" somehow over the time when doing updates. Flashing without a full erase uses old wifi calibration so this is always a good idea for new devices. Tasmota has a command to erase this section in flash to retrigger this process. Mandantory, after this a power off is needed.
Is it related to ESP32 only? What's the difference between OTA and Web flasher please? I supposed the upgrade firmware from the ESP web GUI in fact means OTA upgrade (and this is how I am always upgrading the firmware after one-time flash .exe tool used on new / empty ESP devices). So now I am confused with another flashing method (Web flasher?).
A wild guess, maybe the wifi calibration is "damaged" somehow over the time when doing updates. Flashing without a full erase uses old wifi calibration so this is always a good idea for new devices.
Well my test node did not get a full erase of the flash and it worked fine after flashing it via the esptool.py flash tool. Even with a major SDK jump in code.
What's the difference between OTA and Web flasher please?
Ah, I get the confusion :)
Is it related to ESP32 only?
Not sure, however I was not able to flash the specific ESP8266 on my desk with the web flash tool. Might be related to the specific USB to serial chip on that one, as that specific board can also not be flashed using the ESPEasyFlasher (the one with the blue color and the "special font" (let's say I'm not a fan of that font choice...)
I had this with esp8266 in the past too. I do nearly nothing with a esp8266 since a year. All time spent to get the new espressif mcu well implemented in Tasmota. This opened a big new rabbit hole. Since support in Platformio was lacking completly and jumping in there opened new ones...
Is it related to ESP32 only?
Not sure, however I was not able to flash the specific ESP8266 on my desk with the web flash tool. Might be related to the specific USB to serial chip on that one, as that specific board can also not be flashed using the ESPEasyFlasher (the one with the blue color and the "special font" (let's say I'm not a fan of that font choice...)
Have you tried the new webflasher version? Talking about rabbit holes i refactored the webserial code to support the S3, now it should recognize more USB serial adapters too. You can easily try the latest version with https://tasmota.github.io/install/
Is EspEasyFlasher still using the old Esptool.exe? Since that time there have been many fixes and enhancements done. For flashing "on the desk" esptool.py v3.3 should be used. There are compiled binaries available too.
I updated to the latest 8.0.1 version of the web flasher, which is -as far as I know- the latest.
And the ESPEasy Flasher tool does look into the Windows registry to find the COM ports. Apparently there are some USB to serial chips out there that trigger some driver to get installed which does not register itself in the registry like any other serial driver does. So it is perfectly possible that the Chrome implementation to interact with the serial port suffers from the same issue.
Edit: Hmm strange, your tasmota link does seem to get further than the one I installed. I get an error stating the port is not ready and your flasher page looks to get one step further.
Thank you both for comments / explanation. For the first time flashing I am still using a couple years old FlashESP8266.exe which always worked fine for me with 2 different USB serial adapters.
@TD-er yep using 8.0.1 Probably it fails at the same point, just looking different
For a long time, users have reported WiFi issues, where others experienced none. Both running the same build.
When testing the web upload tool myself, I noticed some ESP32 unit I used for development was acting extremely slow.
I tried flashing to an ESP32 with 4MB flash. (e.g. ESP_Easy_mega_20220428_test_A_ESP32_4M316k ) The 20220427 build does not yet use the new board definitions introduced with the IDF-4.4 pull request. So the flash may be running at 80 MHz on those builds, unless patched by the flash tool. N.B. The web flash tool does not patch files.
I also performed an OTA flash to run a linux made build, just to make sure it isn't related to the build platform. This OTA flash does result in a very responsive system, at least when starting from a responsive system to be begin with.
So I'm wondering what has to be changed to make every node work well on every build, regardless the flashing tool.
@Jason2866 Do you have any idea?