Crash Neopixel with ESP_Easy_mega_20221105_neopixel_ESP32_4M316k.bin

[fly74]

The new build ESP_Easy_mega_20221105_neopixel_ESP32_4M316k.bin don't work with neopixel:

21267 : Info : WIFI : Disconnected! Reason: '(8) Assoc leave' Connected for 21 s 21268 : Info : WIFI : Arduino wifi status: WL_DISCONNECTED 6 ESPeasy internal wifi status: DISCONNECTED 21369 : Info : WIFI : Disconnected! Reason: '(8) Assoc leave' Connected for 21 s 21371 : Info : WIFI : Set WiFi to OFF 21488 : Info : INIT : Free RAM:242052 21501 : Info : neomatrix: INIT, matrixType: 0b101 21521 : Info : NEOMATRIX: Init start. 21522 : Info : NEOMATRIX: Init done, address: 0x3ffd0b90 valid, commands: neomatrix/neomatrixcmd, size: w:16, abort() was called at PC 0x400867a7 on core 1

Backtrace: 0x40084095:0x3ffb2210 0x4008f0c5:0x3ffb2230 0x40094351:0x3ffb2250 0x400867a7:0x3ffb22d0 0x400868a9:0x3ffb2300 0x401661d7:0x3ffb2320 0x400d4707:0x3ffb2350 0x400d45d9:0x3ffb23a0 0x4014a093:0x3ffb23c0 0x400f5979:0x3ffb2430 0x4011b7de:0x3ffb2620 0x4011c1a2:0x3ffb2670 0x4012356a:0x3ffb2760 0x4011a282:0x3ffb27a0 0x400e4687:0x3ffb2800 0x40162e52:0x3ffb2820

ELF file SHA256: 0000000000000000

Rebooting... ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DOUT, clock div:2 load:0x3fff0030,len:184 load:0x40078000,len:12616 load:0x40080400,len:2916 entry 0x400805c4

[TD-er]

Does this board have PSRAM ?

[fly74]

I don't know. I'm trying to flash back to the build before.

[TD-er]

Is the shape more rectangular like the left one or more square like the right one?

[fly74]

ESP Chip ID: | 13375324 (0xCC175C) -- | -- ESP Chip Frequency: | 240 MHz ESP Crystal Frequency: | 40 MHz ESP APB Frequency: | 80 MHz ESP Chip Model: | ESP32-D0WDQ6 ESP Chip Revision: | 1 ESP Chip Cores: | 2 ESP Board Name: | Espressif Generic ESP32 4M Flash ESPEasy 1810k Code/OTA 316k FS Storage Flash Chip ID: | Vendor: 0x5E Device: 0x4016 Flash Chip Real Size: | 4096 kB Flash IDE Size: | 4096 kB Flash Chip Speed: | 80 MHz Flash IDE Speed: | 40 MHz Flash IDE Mode: | DIO Flash Writes: | 0 daily / 0 boot Sketch Size: | 1451 kB (1856 kB free) Max. OTA Sketch Size: | 1856 kB (1900544 bytes) SPIFFS Size: | 283 kB (121 kB free) Page size: | 256 Block size: | 8192 Number of blocks: | 35

The action build ESP_Easy_mega_20221018_neopixel_ESP32_4M316k.bin works again.

[TD-er]

On builds which don't even 'know' about PSRAM, ESPEasy will not show anything. So you need to look at the ESP32 module to see if its shape matches one on the picture.

[fly74]

It's a ESP32 problem, the new build with 8266 works with neopixel. I look at the module.

[fly74]

[TD-er]

Ton had similar crash issues with his 16M board, which does have PSRAM. That's why we added those new 16M8M PSRAM builds. On 4M boards the PSRAM build flag was already present in the board definition.

If the ESP may check for PSRAM support, GPIO 16 and GPIO 17 may be polled. Not sure if you're using those?

[fly74]

No, it's a very simple neopixel with 4x (8x8) neopixel.

like the wire in the picture :)

[TD-er]

Hmm strange. Maybe I can make a build for you in Windows? Just to see if that makes a difference

[fly74]

I'm not sure if @tonhuisman changes from the action build ESP_Easy_mega_20221018_neopixel_ESP32_4M316k.bin are in the new build?

But as I said the 8266 new build works with the plugin. Must be something between these 2 builds regarding ESP32.

[TD-er]

Must be something between these 2 builds regarding ESP32.

Yep very likely

[TD-er]

Just made a build on Windows ESP_Easy_mega_20221105_neopixel_ESP32_4M316k.factory.zip

Could you try it?

[fly74]

Same crash.

[TD-er]

OK, that makes it still terrible to have crashes reported before the build on my own PC was even done, after 2 months of development and testing. But on the bright side, we can rule out "Linux" vs. "Windows" builds.

I will look into it.

[tonhuisman]

I did a test of the NeoPixel builds, and it crashes, independent of PSRAM option enabled or not. Reverting the Espressif32 library from 2.0.5.2 to 2.0.4.1 resolves the crash, seems that in the 2.0.5 version something broke regarding to RMT, as that's what's being used by this plugin. @Jason2866 Do you have suggestions on how to fix this?

This is a working build: ESP_Easy_mega_20221105_neopixel_ESP32_4M316k.zip

[Jason2866]

@tonhuisman idk, what is causing the issue. I see no obvious changes in rmt part since 2.0.4.1

[tonhuisman]

We'll revert to using 2.0.4.1 for now as that's working quite stable. We'll keep an eye on any framework updates, and test this explicit scenario. @Jason2866 Thanks for your reply.

[fly74]

This is a working build: ESP_Easy_mega_20221105_neopixel_ESP32_4M316k.zip

@tonhuisman confirmed worked for me.

[fly74]

It looks like as has also an effect to the 7-segment plugin. Some segments don't light up or all light up. Couldn't describe it more precisely.

[tonhuisman]

It looks like as has also an effect to the 7-segment plugin. Some segments don't light up or all light up. Couldn't describe it more precisely.

I've just tested using the build I uploaded, above, and 7-segment plugin & hardware is working as intended here, running on ESP32. Can your issue be related to connection issues?, as the hardware seems quite sensitive to that.

[fly74]

Not really. I flashed back to action build ESP_Easy_mega_20221018_normal_ESP32_4M316k.bin and all ist fine.

[TD-er]

Which pins are used? Suspect pins are GPIO 16 and 17 as they are also used for PSRAM and this seems to be checked more even though it is not present.

[fly74]

16 and 17 are used.

[tonhuisman]

That would imply the other displays, starting at 7SEG3, work as intended, correct?

[Jason2866]

Using GPIO 16/17 needs reinit before the can be used. Reason, PSRAM is by default enabled in Tasmota framework. Core does search for PSRAM and enables when found. If not it bails out. BUT bailing out leaves GPIO 16/17 in not useable state. So (re)init is needed. This behaviour did NOT change since core 2.0.4.1 to latest. In general when other GPIOs are free it is good idea to use first.

[Jason2866]

That would imply the other displays, starting at 7SEG3, work as intended, correct?

I am not sure if a issue with GPIO 16/17 does not make a collateral damage.

[tonhuisman]

@fly74 Can you set both GPIO-16 and GPIO-17 to Output High on the Hardware page, to see if that fixes it late enough in the boot process to temporarily resolve the issue with your 7-segment displays?

[fly74]

I don't need really a temporary workaround after the flash back to the actionbuild ESP_Easy_mega_20221018_normal_ESP32_4M316k.bin.

[TD-er]

I don't need really a temporary workaround after the flash back to the actionbuild ESP_Easy_mega_20221018_normal_ESP32_4M316k.bin.

Ton probably intended it as a diagnostics request...

[fly74]

I don't need really a temporary workaround after the flash back to the actionbuild ESP_Easy_mega_20221018_normal_ESP32_4M316k.bin.

Ton probably intended it as a diagnostics request...

Ok, I'll give it a try tomorrow.

[TD-er]

Just re-opened as I would like to know any findings by @fly74 Please close when considered finished.

[TD-er]

Using GPIO 16/17 needs reinit before the can be used. Reason, PSRAM is by default enabled in Tasmota framework. Core does search for PSRAM and enables when found. If not it bails out. BUT bailing out leaves GPIO 16/17 in not useable state. So (re)init is needed. This behaviour did NOT change since core 2.0.4.1 to latest. In general when other GPIOs are free it is good idea to use first.

@Jason2866 I do remember I read some discussion about this somewhere but cannot find it. Do you happen to have some of these bookmarked somewhere?

Edit: I am using the "Tasmota" code for this, as you told me to a while ago: https://github.com/letscontrolit/ESPEasy/blob/2731bd15ddd151bbf2bf8c02fe1cf565bd39ea91/src/src/ESPEasyCore/ESPEasy_setup.cpp#L120-L131 Is it possible the 2.0.5.2 SDK is no longer defining CONFIG_IDF_TARGET_ESP32 ?

[fly74]

Now ESP_Easy_mega_20221105_normal_ESP32_4M316k actual in testing with

Pin mode GPIO-16: Output High Pin mode GPIO-17: Output High

Results later today.

[Jason2866]

@TD-er Seems the same https://github.com/arendst/Tasmota/pull/13345 There is no general issue with neopixel. We have no issues for Tasmota after the core change.

Is it possible the 2.0.5.2 SDK is no longer defining CONFIG_IDF_TARGET_ESP32 ?

It is there, but Platformio LDF is... I spent many hours to get a really stable and predictable result from. Finally we use now

lib_ldf_mode = chain
lib_compat_mode = strict

[TD-er]

It is there, but Platformio LDF is... I spent many hours to get a really stable and predictable result from. Finally we use now

lib_ldf_mode = chain
lib_compat_mode = strict

Many thanks. Will perform a number of tests with these. I always got the feeling something is messing up the builds as some builds do seem to perform "different" even when only a single flash string was changed (thus not related to any code, or at least should be).

Maybe I will also move all used libraries into the project tree as you seem to do with Tasmota. It for sure may speed up project build initialization time as that's taking up quite a lot of time these days.

[TD-er]

With these lib flags, I am no longer able to build ESPEasy. For example PubSubClient and LiquidCrystal_I2C cannot be found, but they are present in the lib folder.

Also added lib_dir = lib to platformio.ini in the [platformio] section. and:

[common]
lib_archive               = false
lib_ldf_mode              = chain
lib_compat_mode           = strict
shared_libdeps_dir        = lib

These libraries are also added to the lib_deps entry.

I did look at the Tasmota PIO ini files and it looks like you're not setting the lib_deps but only the lib_ignore. Is it a correct assumption that when lib_deps is not set, it will only look in the lib folders?

[Jason2866]

tbh, i dont remember.

[TD-er]

OK, then I will try to move all libs into our repository libs folder.

[TD-er]

Just a short update... Finally found out why the libs were ignored in the strict mode by making a verbose build:

LDF Modes: Finder ~ chain, Compatibility ~ strict
Ignored library C:\GitHub\TD-er\ESPEasy\lib\ESP32_ping
Ignored library C:\GitHub\TD-er\ESPEasy\lib\ESPEasy_ESP8266Ping
Platform incompatible library C:\GitHub\TD-er\ESPEasy\lib\HLW8012_1.1.1
Platform incompatible library C:\GitHub\TD-er\ESPEasy\lib\HT16K33
Platform incompatible library C:\GitHub\TD-er\ESPEasy\lib\HeatpumpIR
Platform incompatible library C:\GitHub\TD-er\ESPEasy\lib\LiquidCrystal_I2C
Platform incompatible library C:\GitHub\TD-er\ESPEasy\lib\MechInputs
Platform incompatible library C:\GitHub\TD-er\ESPEasy\lib\SerialDevices
Platform incompatible library C:\GitHub\TD-er\ESPEasy\lib\pubsubclient
Ignored library C:\GitHub\TD-er\ESPEasy\lib\raburton_esp8266_mutex

The platforms didn't mention the platforms.

[fly74]

Now ESP_Easy_mega_20221105_normal_ESP32_4M316k actual in testing with

Pin mode GPIO-16: Output High Pin mode GPIO-17: Output High

Results later today.

No problems until now.

[Jason2866]

yup, in mode strict it is mandantory that a library.properties or library.json with correct entrys is there

[tonhuisman]

@fly74 I have a test-build for you, that has today's work by TD-er, with all libraries in the repository, that greatly stabilizes the build, but I have also used framework version 2.0.5.2, that yesterday was able to crash consistently when starting a NeoPixel-related plugin, but today, in my local tests, is running smoothly.

Also, this build does have PSRAM support, but still allows the use of GPIO-16 and GPIO-17 when PSRAM isn't actually installed (that was also fixed by TD-er), so your 7-segment displays should also work from these pins as intended, without having to initialize these pins to Output, High on the Hardware page.

To sweeten the package, I've built it from the [P038] NeoPixel branch that has support for Initial and Max brightness settings, as you requested 😃

Can you please test this build with your setup, and report your findings here? ESP_Easy_mega_20221107_neopixel_ESP32_4M316k.zip

TIA

[fly74]

@tonhuisman looks good for Bus(FX). To test the 7 segment I need a ESP32 normal 4M1 binary and for the brightness an ESP8266 normal 4M1.

[tonhuisman]

Sure, no problem: ESP_Easy_mega_20221107_normal_ESP32_4M316k.zip ESP_Easy_mega_20221107_normal_ESP8266_4M1M.zip

[fly74]

Both of them booting and looking fine. Final result from me tomorrow.

@Jason2866 @tonhuisman @TD-er Great work in analysis and fixing in short time!

[Jason2866]

Great to know, there is no issue introduced for neopixel in core 2.0.5.2 It seems the core is not bad ;-) Until now we have no issues in Tasmota with. Always good to have a second project which is using. ESPEasy is a great test software ;-)

[TD-er]

ESPEasy is a great test software ;-)

And Tasmota is a great partner project :) (You know Theo and I only live 20km apart?)

[Jason2866]

Really? Funny! Have you ever met each other in real?

[TD-er]

Really? Funny! Have you ever met each other in real?

Yep, on this picture, we're sitting next to each other :) Me with blue shirt and glasses, Theo wine-red shirt short sleeves. Also been at his house for coffee once.