Hi FastLED community! I’ve just gotten into this whole shebang, and as usual am trying to do too many things at once. But this is how we learn. I’ve banged my head against an issue for awhile now, so I’m hoping it’s something simple I’m just not experienced enough to get.
I had a sketch loaded onto an ESP32. FastLED runs well on it. However, I’m trying to relay instructions over through a bluetooth serial connection. I understand there’s some interrupt issues because I’m using WS2812B strips, but hear me out, because I still have the issues when I comment out FastLED.show(), and replace FastLED.delay() with delay() in my loop.
I can send data (SerialBT.read()) without issue until the first pixel assignment. However, after I assign a batch pixel colors, I get a “Guru Meditation Error: Core 1 panic’ed (InstrFetchProhibited). Exception was unhandled.” error the next time I try to do a SerialBT.read(); I’ve tried leds.CRGB(r,g,b), leds.r = r, leds.red = r, etc.
Is there something about accessing members of CRGB that can cause an interrupt error or anything like that?
@John_Rhoades can you publish your code on gist please.
If you want to put all the leds to the same color you need to do fill_solid(leds,CRBG(r,g,b),Num_leds)
@Yves_BAZIN Let me clarify. My problem isn’t assigning colors to specific LEDs or any specific use of the library. My problem is how it’s interacting with the Arduino-ESP library. I’ll try to get a “down to bare minimum” version up to look at. Unfortunately, that might take awhile, since stripping it down to what I thought was the issues has resulted in no issue, so now I need to add parts until it breaks.
Well, I “solved” the issue. Like so many issues I’ve had with this project, my solution makes no real sense. In the BluetoothSerial library, the method SerialBT.read() first calls SerialBT.available() to check that something’s there to read. By common practice, in my main code, all "SerialBT.read()"s are wrapped in a “while (SerialBT.available)” loop, making the double check redundant. Removing the redundancy in the library fixes the crashing issue. No idea why, as it shouldn’t interfere.
The core issue is still related to interaction with the FastLED library somehow, but I can’t see it.
My guess is that the while loop causes timers or interrupts to be ignored for too long. Also: check out the backtrace decoder for ESP32 – it is super helpful in figuring out where the failure happens.