ESP32 Forum

I've built my own led controller with a ESP32 D1 Mini / D1 Mini ESP32 from AZ-Delivery.
It has done it's job exclusively well until i tried building my own classes in the Arduino.
Mainly these handle what colours the lights have and do not influence any hardware directly.

I have checked all the wiring because i could not imagine this could be a software issue ever.
Nothing helped.
I replaced the "Adafruit ws2801" library with the "Fastled" library, did not change anything either.
But if i roll back a few versions (of my project), the problems disappear.

What i changed was only that i started using heap memory explicitly to be able to create my handlers dynamically and maintain buffers (with lighting colours, brightness and so on) after loop() returns.

The SPI output is somehow unstable. I see this because from time to time there is a color mismatch in the leds and sometimes even the whole strip flashes in a greenish color. This is only for a few milliseconds but it's visible.
Since the problem disappears when i roll back my arduino project to an older version i know it's not a hardware issue.
And there are no crashed when it happens. The overall program just continues to run and the light patterns are consistent.

My question is now: What am i looking at? How do i debug this? Has anyone seen something like this before?

Since you mentioned that the issue appeared after introducing dynamic memory allocation, review the specific changes you made in your code.

Reviewing is not the problem. The code is functional but somehow the SPI-output gets corrupted after it is sent to the SPI but only sometimes. The data is correct when i create it in my classes. I do not know where to set my hooks if the data is not corrupted within my own class. Or which hook to set to catch this bug. Have you got anything helpful to say how i could debug this? What tool to use, what library?

Post the code where you are generating the corrupt data.
I would say the most likely cause of this symptom would be not zeroing out an array after your malloc, and so you have random clingers at the end of your string.

Alright lets do it your way.
I suggest looking at the full_controller because that is the shortest.
It just playbacks one single color all the time.
That is by the loop() calling the full_controller::clock() method repeatedly.
To clarify:
The bug occurs both at full_controller and rain_controller.
All the LEDs (approximately 10 meters) flash in one color (not the porgrammed one) and after wards everything is back to how it should be, right color, right mode. But that repeats every some 30 seconds or a minute which is why i bother.
Please tell me it is solved by good practice.

files

deleted

Alright i found the source.
In this project i introduced reactions to wifi sent commands.
I had checked this already but forgot to disable the "wifi.begin" command.
If i disable all lines that start wifi then the flickering stops.
Which means it is a hardware issue what i suspected from the start.

Anyone who knows how to keep the wifi waves away from the spi on a 3 centimeter preprinted esp32 d1 mini board is welcome.

The timing of the neopixel signal is critical, wifi interrupts can easily disturb this. Maybe you can select another way how the neopixel signal is generated. Personally I use the Neopixelbus library with I2S and DMA on an ESP32-S2 without any issue. However, please note that Neopixelbus doesn't support I2S on all ESP32 variants.

No neopixel. I am using a standard WS2801 chip that receives all the data for the 10 successive meters of equal chips.
If the first signal comes through right (from SPI to the first LED) then the whole line is correct. No Problems there.
But if i turn on WIFI, the SPI picks up noise before the line leaves the box and the first LED transmission is corrupted.
How and where this occurs, in library or on air i don't know yet.

What i know:
-Standard ws2801 chip for the leds.

-the wifi library is #include <WiFi.h>

-the spi library for the leds is #include "Adafruit_WS2801.h" i've tried FASTLED with equal wiring before, that was not better.

-i am using Dupont jacks so far, will be trying to omit them and solder directly.
update: Leaving the dupont plug lines out and soldering the wires directly to the board does not solve the issue.

-The I2C seems about fine although its closer to the antenna than the SPI. (I2C used for a gpio extension for a keypad)

-the board name and pin locations, see Anything ring a bell?

Solution:
Update first, never apologize.
I updated all libraries from Adafruit that i used via the Tools->"Manage Libraries" Tab.
But more important: Updated the esp32 Core library from expressif via the "Boards Manager" Tab to Version 2.0.14

https://support.arduino.cc/hc/en-us/art ... uino-Board

Of course i got the idea only after i disconnected everything, rewired it at least ten times, uploaded my whole source code, stuck in different capacitors at different places, used different libraries and remodeled the code completely multiple times, revieved the adafruit ws2801 calls and found it led of the default SPI library. And it only took me five days.
Only thing that really keeps me from crying is that it finally works and that no one that read all this had the idea before i had it.
You decide if you want to laugh or cry.