Hi guys! When using wifi stack code fastled hangs in a minute. If you do not use wifi - everything is fine. I tried to disable interrupts, but it had no effect.
Thanks for help!
Board: MH-ET Live esp32 DevKit.
FastLED 3.2.1
@X-WL1 if you don’t get an exception on ESP32, you need to go the printf debugging route to see if it hangs somewhere that’s always the same, and maybe inspect that code for bugs.
Sadly Sam or I won’t really be able to help you debug this in details. That’s the downside of microcontrollers, it can be a pain when you hit issues like this 
You can also try running your code on a different microcontroller without wifi to see if it hangs too, which would then show that it is a bug in your code unrelated wifi.
That said, are you really sure your serial port is working? I can’t remember if I ever got an ESP32 to hang without printing an exception. There is a watchdog on the chip that does detect hangs and prints an exception there too.
@Marc_MERLIN if i don’t do
WiFi.begin (ssid, password);
then everything will work fine. As far as I know, I was not the only one who encountered this. There is a bug report in the FastLED branch, according to @Sam_Guyer should work in the latest version of the code, but this is not the case (
You mean @Sam_Guyer . Maybe he can comment further, I can’t. If you’re very stuck, you can try Yves’ driver instead, see http://marc.merlins.org/perso/arduino/post_2018-07-30_Building-a-64x64-Neopixel-Neomatrix-4096-pixels-running-NeoMatrix-FastLED-IR.html#esp32driver
@Marc_MERLIN The Yves driver works without errors, but flickering appears on my installation, look here: https://plus.google.com/u/0/107582712342018613958/posts/Qvv5MAkFRqm
@X-WL1 ah, to confirm
- Yves’ driver flickers, even after you added level shifters
- and yet your power injection is good because it stops flickering with Sam’s driver, so that proves your power is good.
If so, honestly I don’t know what to tell you.
For printf debugging, correct, you sprinkle Serial.printf in the code using divide and conquer until you find the area that hangs, usually down to a single instruction.
That said, with dual core and semaphores on ESP32, it can get complicated and I’m not that knowledgeable on how to debug them.
@Marc_MERLIN @Sam_Guyer
I found this!
There is a problem in line 423 of the clockless_esp32.h file
As I think, ClocklessController is not created on time.
If you use println, then “Guru Meditation Error: Core 0 panic’ed (Interrupt wdt timeout on CPU0)” occurs
Decoding:
Core 0:
PC: 0x4008ed72: vListInsert at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/list.c line 188
EXCVADDR: 0x00000000
Decoding stack results
0x4008ed72: vListInsert at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/list.c line 188
0x4008dc8b: vTaskPlaceOnEventList at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 2958
0x4008c733: xQueueGenericReceive at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/queue.c line 1589
0x400d6e35: uartWriteBuf at /Users/xwl/Documents/Arduino/hardware/espressif/esp32/cores/esp32/esp32-hal-uart.c line 319
0x400d63d9: HardwareSerial :: write (unsigned char const *, unsigned int) at /Users/xwl/Documents/Arduino/hardware/espressif/esp32/cores/esp32/HardwareSerial.cpp line 122
0x400d656a: Print :: write (char const *) at /Users/xwl/Documents/Arduino/hardware/espressif/esp32/cores/esp32/Print.h line 66
0x400d657d: Print :: print (char const *) at /Users/xwl/Documents/Arduino/hardware/espressif/esp32/cores/esp32/Print.cpp line 84
0x400d5324: ClocklessController23, 77, 77, 154, (EOrder) 66, 0, false, 5> :: startNext (int) at /Users/xwl/Documents/Arduino/libraries/FastLED/platforms/esp/32/clockless_esp32.h line 424
0x400d549e: ClocklessController23, 77, 77, 154, (EOrder) 66, 0, false, 5> :: interruptHandler (void *) at / Users / xwl / Documents / Arduino / libraries / FastLED / platforms / esp / 32 / clockless_esp32. h line 504
Core 1:
PC: 0x4008bedd: vPortCPUAcquireMutex at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/portmux_impl.inc.h line 88
EXCVADDR: 0x00000000
Decoding stack results
0x4008bedd: vPortCPUAcquireMutex at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/portmux_impl.inc.h line 88
0x4008cd1a: vTaskSwitchContext at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 2839
Very interesting that you don’t get a traceback (which I thought you’d get every time) until after you add a printf.
At least now you were able to get a better hint on where the error is.
Note that from my experience Sam is not always on G+. I think once, he got back to me after a month because he wasn’t getting/seeing the notifications (also to be fair, like most folks, myself included, when not hacking on microcontrollers, I’m sure he has other things that take his time and attention).
My understanding of the main FastLED branch is that it’s also maintained, but only lightly. I’m not sure if @Mark_Kriegsman and/or @Daniel_Garcia know the ESP32 code and/or maintain it, or if it was only @Sam_Guyer 's work (although from a recent test I did, FastLED git crashed on ESP32 with SmartMatrix while Sam’s branch didn’t, so clearly they are not quite doing the same thing).
My recommendations
- do your best to find the bug yourself and send a patch (the “scratch your own itch” approach).
- if ESP32 multicore code is a bit too opaque for you (don’t feel bad, you wouldn’t be the first), reproduce the bug with both Sam’s branch https://github.com/samguyer/FastLED ) (and the master FastLED branch, and file an issue in github in both with the appropriate traceback.
- If ESP8266 is good enough to do the job for you, you may also work around the problem by using that driver instead, which is of course entirely different while still offering wifi (although wifi might interfere with fastled timing on single core). That one only supports 4 way parallel output though.
Best of luck.
I’ll pass this along to Sam; thanks for the help isolating this problem.
Mmmh, now I see that Sam’s branch says “This branch is 39 commits ahead, 19 commits behind FastLED:master.” so it’s actually a different driver than FastLED driver. I didn’t check when his code was last pulled into FastLED master, but clearly master is not up to date with his branch yet and his branch is behind on other stuff (although probably unrelated code)
@X-WL1 but definitely file github issues in both github trees if both fail for you. No github issue == no bug 
@Marc_MERLIN I tried the latest version of the Sam code and it did not solve the problem (
Core 0 panic’ed occurs only if you do print in the startNext function, otherwise the ESP continues to work further, after stop FastLED. and if, for example, to raise the web server - it will continue to respond.
3) esp8266 is not suitable due to the large load due to scene rendering or ArtNet processing.
I also tried to connect ETH lan8720, but there were difficulties with the launch.
The stack trace you’re looking at is something different - that’s an interrupt watchdog timeout that is firing because the interrupt handler is taking too long to return - which is happening because you’re doing a serial write inside the interrupt handler. So the specific trackback that you are getting may be different then what is happening normally.