ESP32&mega-20220809 AdaGFX helper issue #4194
Comments
TD-er
added
Type: Bug
|
There is no watchdog reset? |
|
Just looking through your logs and I wonder what the Is this some browser extention trying to create clickable links for phone nrs? |
Due to testing any watchdogs wasn't configured. Internal also wasn't affected - ": Info : AdaGFX_helper:" was last message in log for a long time until board was reloaded.
As I understand it's RTC module native work. I can try to unplug it. Also - this log was copied from serial console, not wrom web log. Which extension can make it inside of serial connection? |
|
The logs should only show something like this: Not the brackets and (tel:....) part. Given the fact it wasn't rebooting, that means it is stuck somewhere where it is still calling something which resets the watchdog timer. |
Yep, it's look like waiting or block code. But there is no such reactions inside of ILI9341 plugin, because there is no buttons on it's board. Touch plugin is different part of this boards, it can be used separately and it's disabled now. |
|
If you have log level Debug enabled, then you might see a bit more, depending on where it halts. |
|
I think it may be halted here: That's the first line where there's actual interaction with the display. Do you have the backlight pin set? I will also check on my board to see if analog write is still working as it should, as there have been quite a few issues lately with changed implementation of low-level GPIO code in the most recent SDK. |
|
Looked a bit more into the code of It seems there is already some code in there wrapped in // Probably ESP8266 or ESP32. USE_FAST_PINIO is not available here (yet)
// but don't worry about it too much...the digitalWrite() implementation
// on these platforms is reasonably efficient and already RAM-resident,
// only gotcha then is no parallel connection support for now.
typedef uint32_t ADAGFX_PORT_t; ///< PORT values are 32-bit |
Nope, Backlight control isn't used by plugin (therefore PIN not configured in plugin). It's used through rules, without PWM, only On\Off functionality after booting and before sleeping. |
|
You could set GPIO-2 to be as backlight pin, as that one is often connected to a LED. This may help to see what's wrong? |
As I wrote before (at the forum) - it's Wemos TFT 2.4 shield. It's backlight control was linked to TFT connector at GPIO32 for Wemos D32 Pro and through pin header. Therefore I'm using rules like
and
GPIO2 also used in my project, but for power control of environment through MOSFET. This GPIO controlled by Hardware at boot and by rules at sleep. |
|
It was merely meant as a suggestion for diagnostic reasons as we now have no clue where it halts. |
I'll check situation with increased logging level as you proposed. |
|
Which pins do you use? Do you have any pins set on the Hardware tab to anything other than "default" (e.g. pull-up resistors enabled) |
Hmmm it's very long story. because almost all free PINs was used. There is 2 HW Serials (one for PMSx003, another one for Senseair S8), 2 active I2C - one is BME280, another one is RTC module. There is third one I2C module planned- SCD41 (instead of S8) but it isn't used now due to P135 wasn't released yet. SPI for TFT screen and GPIO2 for power latching.
There is part of display initialization:
As you can see - there is no any additional information while Debug dev was activated. |
Can you also provide this info? Edit: Bonus question: How long are the wires to the display, and are they all of the same length (less than 2 cm. diff)? |
|
I've been testing this for a while (though I haven't got a display connected to this device, tried that and works just as fine with a 4MB ESP32), I got this log (at INFO level): Edit: And the same result with P095 Splash turned off. |
|
Ok, there is information for @tonhuisman release (as fully working one): |
It's native Wemos TFT cable used. It's working with you release but isn't working with newest builds. |
|
Bingo!
Board was going to cycle reboot with same serial messages for some time and then going back with disabled PMS7003 plugin:
After this additional step board isn't going back as previously, it's stucking in this state |
|
P.S. also - WiFi isn't connected to AP, there is no such device in WiFi client's list at the router. |
|
Thinking about this for a while, but I'm inclined to think that this is related to recent IDF changes, regarding pin mode settings etc. |
|
I don't have the exact same display here (or at least I can't find it...)
Also looked at the signals using the Logic Analyzer, but there doesn't seem to be any strange jitter in the timings |
|
OK, I'll try to check situation with new same board. It isn't soldered, therefore it can't take HW affect, only SW. |
|
So, same bootloop with new board, wasn't previously used yet. Was flashed with mega-20220809 and minimally configured - same Advanced settings, same Hardware and VSPI. GPIO2&32 was manually changed to 1 by "Commands" through web server. After Display was added it send Core panic, rebooted and stucked at AdaGFX helper step:
Test scheme is: |
|
By the way - if it can help - I can't use @tonhuisman 's May's config from test release at new build (by save&load), look's like a difference in filesystem and new build can't successfully load it - board going to cyclic bootloop after loading old config. |
That 26 MHz is what I've seen in these display-related sources ever since I started working with them, so most likely that hasn't changed. |
I dont think it will solve your issues. The SDK (Arduino) is the same. Changed is only that esptool v4.1 and the USB reset command can be used. |
|
OK, will try. Do you have any idea whether issues like these are really related to the slower speed of LittleFS on larger file systems? |
|
Dont think LittleFS issues are speed related, we use heavily for Tasmota and our standard flash mode is |
|
Added https://github.com/arendst/Tasmota/blob/development/pio-tools/post_esp32.py#L134-L142 in factory firmware build script since you can not flash bootloaders in flash mode |
|
Tasmota USB serial code changes starting here |
|
Thanks, will look into these links. |
@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. |
|
Oh and just curious, why don't you have the option to not append the SHA digest when generating the factory bin? |
|
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. |
|
Yep, I know why it is needed when patching the speed/mode flags. |
|
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. |
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. |
|
Exactly old test release, stuff changed. Old may not working anymore! |
|
Even Platformio guys seems sometimes a bit confused about. Did a PR platformio/platform-espressif32#880 |
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:
|
|
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. |
|
ESPEasy uses flash-mode |
@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: |
|
The 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. |
|
Just read through the comments a bit more. |
|
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 |
|
Mhh,. do you use |
|
Nope, we don't use that one. |
|
One point. I have no idea why the second stage bootloader does not switch in mode |
|
Later this week I have some more time to do investigations around the qio miracle |
|
Closing issue due to solved by theme. |
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:
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
The text was updated successfully, but these errors were encountered: