Update: Crash fixed by out of tree ESP32 branch: https://github.com/samguyer/FastLED original message:

Update: Crash fixed by out of tree ESP32 branch:

original message:
Is fastLED supposed to be stable on ESP32?

pragma message “FastLED version 3.001.008”

After a certain number of fastled.show() commands, ESP32 crashes (while ESP8266 and teensy3.1 continue working with the same code):

Guru Meditation Error: Core 1 panic’ed (Interrupt wdt timeout on CPU1)
Core 1 register dump:
PC : 0x400d13ce PS : 0x00060534 A0 : 0x800d14eb A1 : 0x3ffca630
A2 : 0x3ffca664 A3 : 0x140b351f A4 : 0x00000008 A5 : 0xffffffff
A6 : 0x0000003b A7 : 0x000000d1 A8 : 0xff000000 A9 : 0x3ffc2491
A10 : 0x3ff44004 A11 : 0x00000039 A12 : 0x00000020 A13 : 0x00000020
A14 : 0x3ff44004 A15 : 0x0000012b SAR : 0x0000001f EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xffffffff

Backtrace: 0x400d13ce:0x3ffca630 0x400d14e8:0x3ffca660 0x400d1639:0x3ffca6a0 0x400d1f89:0x3ffca6e0 0x400d0a41:0x3ffca720 0x400d0b5c:0x3ffca740 0x400d1697:0x3ffca760 0x400e659d:0x3ffca790
0x400d12f7: ClocklessController5, 60, 150, 90, (EOrder)66, 0, false, 5>::showRGBInternal(PixelController(EOrder)66, 1, 4294967295u>) at /home/merlin/Arduino/libraries/FastLED/platforms/esp/32/clockless_esp32.h line 13
0x400d146c: ClocklessController5, 60, 150, 90, (EOrder)66, 0, false, 5>::showPixels(PixelController(EOrder)66, 1, 4294967295u>&) at /home/merlin/Arduino/libraries/FastLED/platforms/esp/32/clockless_esp32.h line 42
0x400d15bd: CPixelLEDController(EOrder)66, 1, 4294967295u>::show(CRGB const*, int, CRGB) at /home/merlin/Arduino/libraries/FastLED/controller.h line 397
0x400d1f0d: CFastLED::show(unsigned char) at /home/merlin/Arduino/libraries/FastLED/controller.h line 90
0x400d0a35: FastLED_NeoMatrix::show() at /home/merlin/Arduino/libraries/FastLED/FastLED.h line 488
0x400d0f02: display_scrollText() at /home/merlin/Arduino/libraries/FastLED_NeoMatrix/examples/MatrixGFXDemo/MatrixGFXDemo.ino line 533
0x400d172b: loop() at /home/merlin/Arduino/libraries/FastLED_NeoMatrix/examples/MatrixGFXDemo/MatrixGFXDemo.ino line 710
0x400e6521: loopTask(void*) at /home/merlin/Arduino/hardware/espressif/esp32/cores/esp32/main.cpp line 18

Core 0 register dump:
PC : 0x400d5f5e PS : 0x00060534 A0 : 0x8008593d A1 : 0x3ffc70c0
A2 : 0x00000008 A3 : 0x00000000 A4 : 0x00000001 A5 : 0x3ffc7704
A6 : 0x00000000 A7 : 0x00000001 A8 : 0x3ffc2c6c A9 : 0x3ffc2c50
A10 : 0x00000000 A11 : 0x00000001 A12 : 0x00000000 A13 : 0x00000001
A14 : 0x00000000 A15 : 0x3ffc6d80 SAR : 0x00000000 EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000

Backtrace: 0x400d5f5e:0x3ffc70c0 0x4008593a:0x3ffc70e0
0x400d5ee2: esp_vApplicationIdleHook at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./freertos_hooks.c line 62
0x4008593a: prvIdleTask at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/./tasks.c line 3409

Esp32 work is being done in a separate repository for now - https://github.com/samguyer/FastLED?files=1

Watch dog timer timeout errors are often caused by delay statements…

@Jeremy_Spencer err? delay is supposed to call yield(), and the wdt you’re likely thinking about is on esp8266, not on ESP32 which has 2 cores, one to run arduino and one to run background tasks.
Or am I confused?
@Daniel_Garcia thanks for the pointer, I’ll try that other branch.

I know it’s not supposed to be a problem, but I’m sure it’s hapenned to me with the ESP32…

Which type of LEDs are you using? I’ve had fewer problems with SPI LEDs, but have got both working well now (on an ESP32)

@Jeremy_Spencer ok, then please be more specific so that I can try to avoid your problems :slight_smile: / The whole idea is that if you do a tight loop, you don’t allow background processes to run. If you run delay(), it exactly allows them to run. So, are you sure delay is a problem?

@Jeremy_Spencer I’m using neopixel LED matrices, clockless, the cheap stuff (well, it’s still $150-ish for 32x32 pixels).
@Daniel_Garcia thanks, I can confirm the other lib does not crash anymore.
@Sam_Guyer thanks for your ESP32 fork. I can confirm it does not crash for me anymore, however it also fails to display anything when I send it fast updates (i.e. too many calls to show() which I guess don’t have time to settle in the background).
If you don’t mind, can you clone https://github.com/marcmerlin/FastLED_NeoMatrix and run https://github.com/marcmerlin/FastLED_NeoMatrix/blob/master/examples/MatrixGFXDemo/MatrixGFXDemo.ino ?
It’s meant by default for a 16x16 neopixel matrix, but you can adjust the size, and if you’d like run it on a strip instead.
Watch on serial console for “pan/bounce 24 bitmap” “pan/bounce 8 bitmap” and “Count pixels”. With your code, nothing gets displayed for those demos because apparently I update the matrix quicker than the backend is able to push updates.

@Sam_Guyer if you get the chance to look at the code, also look at FastLED.delay. It’s not working for me on ESP32, see:

Your diff never calls matrix->show()

Oh - nevermind, I see where you define delay as FastLED.delay (it’s generally a bad idea to do defines like that - better to mark them as all caps, makes it clearer that it’s a define - especially for things that are system functions : )

@Daniel_Garcia ah yes, I messed up my debugging attempt (adding a delay(1)), but I’ve just re-added show() and it still does not work on ESP32 https://github.com/marcmerlin/FastLED_NeoMatrix/commit/4c865441f13b4c56b82771246a80a2b125bef075

@Daniel_Garcia yeah, good point. I’ll probably convert it all to DELAY, this code was written before FastLED, so I have to convert it over what FastLED can do.

@Marc_MERLIN , I seem to remember that the delay issues were with a very early version of the ESP32 Arduino core…

@Jeremy_Spencer @Marc_MERLIN Hey guys regarding the watchdog firing, i saw this ages ago in both the esp8266 and esp32 (not in fastled just generally). Basically it fires if something in your code is in a very tight loop and not giving the other core enough time to run anything. All you need to do is place a yield() into anything that does this

And the reasons why a yield in the middle of ws2812 bitbang’d output is a bad idea are legion :slight_smile:

So, just to try I put a yield just before my led.show() and that made no difference, however increasing the wait between 2 retries if a line gets interrupted, that worked. No more glitches and interrupts are still on (see https://plus.google.com/+MarcMERLIN/posts/4xtLu55Aon1 )

The wait time value is actually how long an interrupt is allowed to take before we reset the frame and retry.