search

letscontrolit / ESPEasy

Easy MultiSensor device based on ESP8266/ESP32
http://www.espeasy.com
Other
3.28k stars 2.22k forks source link

ESP32&mega-20220809 AdaGFX helper issue #4194

Closed sobolkz closed 2 years ago

sobolkz commented 2 years ago

Hi all! Just checked latest mega-20220809 with Wemos D32 mini pro - it's look like an error in AdaGFX helper was expected. Mega-20220809 was uploaded to clean Wemos D32 mini pro, it can work without issues due ILI9341 plugin was enabled. After it board stopping to boot at ADAGFX helper initialization step:

INIT : Booting version: mega-20220809_57b0c0c (ESP32 SDK v4.4.3)
48 : Info   : INIT : Free RAM:267076
50 : Info   : INIT : Cold Boot - Restart Reason: CPU0: RTC Watch dog reset digital core and rtc module CPU1: for APP CPU, reseted by PRO CPU
51 : Info   : FS   : Mounting...
92 : Info   : FS   : Mount successful, used 151552 bytes of 8318976
175 : Info   : CRC  : SecuritySettings CRC   ...OK
198 : Info   : INIT : I2C
201 : Info   : INIT : SPI Init (without CS)
203 : Info   : ExtRTC: Read external time source: [1660235047](tel:1660235047)
204 : Info   : Time set to [1660235047](tel:1660235047).000
206 : Info   : Current Time Zone: STD time start: 2022-10-30 03:00:00 offset: 360 min
207 : Info   : Local time: 2022-08-11 22:24:07
209 : Info   : WiFi : Start network scan all channels
311 : Info   : WiFi : STA Started
6927 : Info   : WiFi : Scan finished, found: 10
6931 : Info   : WiFi : Best AP candidate: XXXXXXXXXXXXXXXXXXXX Ch:9 (-58dBm) WPA2/PSK
6933 : Info   : WIFI : Connecting XXXXXXXXXXXXXXXXXXXXX Ch:9 (-58dBm) WPA2/PSK attempt #0
6943 : Info   : WIFI : Arduino wifi status: WL_DISCONNECTED 6 ESPeasy internal wifi status: DISCONNECTED
6967 : Info   : INIT : Free RAM:219656
7014 : Info   : ILI9341: Init start.
7015 : Info   : ILI9341: Init done, address: 0x3ffd3abc valid, commands: tft/tftcmd
7016 : Info   : AdaGFX_helper:

Web server wasn't yet enabled, therefore only full reset can help to boot board again (with disabled ILI9341). I'll try to check latest build with @tonhuisman commit #3903

Jason2866 commented 2 years ago

Tasmota USB serial code changes starting here

TD-er commented 2 years ago

Thanks, will look into these links.

Jason2866 commented 2 years ago

Yes, sure. Download tool v. 3.9.2. As all before. Also, 16m1m was successfully flashed after it.

@TD-er Since how the bootloader are built for core 2.0.4 idk if using old tools is still working. There are NO defaults anymore in magic bytes firmware header.

TD-er commented 2 years ago

Oh and just curious, why don't you have the option to not append the SHA digest when generating the factory bin?

Jason2866 commented 2 years ago

esptool v4.1 does not patch the header if there is the SHA diggest. So the need to be stripped before to make it possible to do the needed header patching. In IDF this is not needed since the bootloaders are built together with the firmware with the settings made for size, speed and mode. This remove of the diggest is only possible in elf2image command. The command is in the changed platformio espressif framework

TD-er commented 2 years ago

Yep, I know why it is needed when patching the speed/mode flags. But if it isn't possible to do so on "factory" images, then flashing using flash tools which may patch these on the fly will cause bootloops, right?

Jason2866 commented 2 years ago

See annswer above. The firmware.img does not have anymore the diggest. So the needed header patching is now possible with esptool v4.1 too. The check for diggest and not to do patching (not to brake SHA) is introduced with esptool v4.x. Esptool v3.x patches always header. NO check! So this problem only arrives when using Esptool v4.

sobolkz commented 2 years ago

What state has the checkbox to change the bin? (not sure about the exact text) Does it allow to change the bin during flash or not? What does the flash tool show about the detected module? (flash frequency, flash mode, etc.)

As I use natuve Win tool Esspessif Download tool and remember option like "Do mot change the bin" always checked. Also it doesn't matter which type of flashing mode was used - it always use propriate type DIO or QIO. Also, as I wrote before @tonhuisman's old test release 16M8M can be successfully used with same tool and same flashing options.

Jason2866 commented 2 years ago

Exactly old test release, stuff changed. Old may not working anymore!

Jason2866 commented 2 years ago

Even Platformio guys seems sometimes a bit confused about. Did a PR https://github.com/platformio/platform-espressif32/pull/880

sobolkz commented 2 years ago

I'm testing now with only old one, because it's look like board HW independent issue. So, latest results - you build 3227 seems to work with 4M316k and 16M1M versions - I can upload this versions and use with backup. Version 16M8M LittleFS still can't be used - I can't restore backup. Board going to cyclic reboot after restoring, hardware power disconnection doesn't help. Also board going to reboot after PMS7003 was added at HWSerial1 or HWSerial2. I'll upload 16M1M version and will test it more detail.

2 days of testing- no issues. PMS7003 was changed to PMS5003ST, additional parameters was added for new events from this device - all looks good, some board stats:

1 2

Jason2866 commented 2 years ago

So issues are introduced somewhere since that. Since we encounter no issues in Tasmota it has to do something related to Espeasy or the tools around used to build or flash. @sobolkz Please try with flash mode qio. This is the main change in core 2.0.4(.1) The way the bootloaders are builded has changed. I recommend to set all boards to mode qio since it makes no difference. ONLY the second stage bootloader enables the flash mode which is used finally! In my experience strange errors that may occur does disappear by doing this. Maybe we are not hit by this since we use dout as standard flash mode for Tasmota. It could be that the problem in this mode do not happen?!

tonhuisman commented 2 years ago

ESPEasy uses flash-mode dout by default, currently. We made a test build 2 days ago with qio, but that wasn't an improvement

sobolkz commented 2 years ago

So issues are introduced somewhere since that. Since we encounter no issues in Tasmota it has to do something related to Espeasy or the tools around used to build or flash. @sobolkz Please try with flash mode qio. This is the main change in core 2.0.4(.1) The way the bootloaders are builded has changed. I recommend to set all boards to mode qio since it makes no difference. ONLY the second stage bootloader enables the flash mode which is used finally! In my experience strange errors that may occur does disappear by doing this. Maybe we are not hit by this since we use dout as standard flash mode for Tasmota. It could be that the problem in this mode do not happen?!

@Jason2866 , is it important, which tool should be used? As discussed with @TD-er some time ago - it can be sensitive for esptool. But as I use for las time only native Espressif win tool flash mode - it sholud like this one: image I'll test it again for you, but as I remember - it was already tested yesterday, it's look like this option doesn't affected while ESPEasy .factory.bin used. Independent that I choose upload procedure was going without errors and final mode is DOUT or QIO is provided inside of FW file.

TD-er commented 2 years ago

The DoNotChgBin option is checked in your screenshot. This means (or at least should mean) that no matter what you set in your SPI config there, or what is detected on the ESP unit, the flashed data should be exactly what was compiled.

However with that checkbox unchecked, or using other tools like esptool.py, the flash settings may be changed while flashing.

So this leaves us with several possible causes when flashing results in a boot loop (or other unexpected behavior) :

Even with all the SPI flash settings set correct, I am still a bit worried to why exactly your build did behave like it did. In other words, I am not 100% convinced that even though Ton's builds seem to work now, all new builds will too. The reason I'm still not convinced is simply because I am not sure about whether our explanation can explain all we're seeing.

TD-er commented 2 years ago

Just read through the comments a bit more. The 4M build and 16M1M build both use SPIFFS. The 16M8M uses LittleFS. Maybe LittleFS is a bit more timing sensitive? Or maybe it uses a bit more low level function calls, making assumptions it shouldn't?

Jason2866 commented 2 years ago

For Tasmota we only use LittleFS and it is in every Esp32x build. If there would be a general problem users would have opened issues in github

Jason2866 commented 2 years ago

Mhh,. do you use ESPAsyncWebServer? There was a problem in the past. Needs newest version to work together.

TD-er commented 2 years ago

Nope, we don't use that one.

Jason2866 commented 2 years ago

One point. I have no idea why the second stage bootloader does not switch in mode qio. I did not managed. But this is not new, previous version did behave identically

Jason2866 commented 2 years ago

Later this week I have some more time to do investigations around the qio miracle Will start with IDF examples. If qio mode is activated I will try this generated bootloader to use with Tasmota.

sobolkz commented 2 years ago

Closing issue due to solved by theme.