ws2812 only white on custom LED board

Other Hardware LEDs and Multiplexing
1

I recently received the PCB for an LED board I am designing. I flashed the FastLED blink example onto the board using my nano as my isp. The ws2812 lit up white, and stayed white. Didn't blink red so obviously there was a problem. I tried other examples, and had the same problem. The ws2812 just stayed white. I then changed the data pin from PD5 to PD4 and got the same result. I am really confused at to why the ws2812 would be acting this way. The circuit for the PCB is below:

Capture10.JPG
Capture10.JPG1356×812 256 KB

Is this a software or a hardware thing? Did I forget some crucial component in my circuit to make this work?

Capture10.JPG
Capture10.JPG1356×812 256 KB

2

Besides a serious lack of of 0.1uF caps in the design - on the 328P you should have one on each of the VCC and AVCC pins, and each WS2812B should have one as well - the design doesn't look too bad.
Can you post the code you are running?

3

Without your code we clearly have no idea. How could we? :astonished:

Are you sure you did not purchase white WS2812s?
<---------

4 
#include <FastLED.h>

// How many leds in your strip?
#define NUM_LEDS 1

// For led chips like WS2812, which have a data line, ground, and power, you just
// need to define DATA_PIN.  For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
// Clock pin only needed for SPI based chipsets when not using hardware SPI
#define DATA_PIN 3
#define CLOCK_PIN 13

// Define the array of leds
CRGB leds[NUM_LEDS];

void setup() { 
   // Uncomment/edit one of the following lines for your leds arrangement.
   // ## Clockless types ##
   FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);  // GRB ordering is assumed
   // FastLED.addLeds<SM16703, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<TM1829, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<TM1812, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<UCS1903B, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<UCS1904, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<UCS2903, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
   // FastLED.addLeds<WS2852, DATA_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
   // FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
   // FastLED.addLeds<GS1903, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<SK6812, DATA_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
   // FastLED.addLeds<SK6822, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<APA106, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<PL9823, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<SK6822, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<WS2813, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<APA104, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<WS2811_400, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<GE8822, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<GW6205, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<GW6205_400, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<LPD1886, DATA_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<LPD1886_8BIT, DATA_PIN, RGB>(leds, NUM_LEDS);
   // ## Clocked (SPI) types ##
   // FastLED.addLeds<LPD6803, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
   // FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
   // FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<WS2803, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
   // FastLED.addLeds<P9813, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // BGR ordering is typical
   // FastLED.addLeds<DOTSTAR, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // BGR ordering is typical
   // FastLED.addLeds<APA102, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // BGR ordering is typical
   // FastLED.addLeds<SK9822, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // BGR ordering is typical
}

void loop() { 
 // Turn the LED on, then pause
 leds[0] = CRGB::Red;
 FastLED.show();
 delay(500);
 // Now turn the LED off, then pause
 leds[0] = CRGB::Black;
 FastLED.show();
 delay(500);
}

So this is the code for the FastLED blink example. Its supposed to blink the WS2812 red, but it just stays white. Its the same with all the other FastLED examples. As far as using just white WS2812, I don't think so. I got the board pre-assembled by JLCPCB, and they look like the black PCB RGB in the above post. I feel like its a software problem, but I recently tried it with AdaFruit's NeoPixel library, and still got the same thing

5

I see you have no capacitors on the crystal. This means it will not run at the correct speed. The ws2812 needs precise timing and if the circuit is not running close to 16 MHz then you will not get the timing right.

You need to check the signal timing or the processor clock with an oscilloscope.

6

There are capacitors on the crystal, C2 and C3. I could still check the timing tho

7

Sorry I missed that, it is one of those schematic that is shattered by in page links making it hard to read.

I would also put some 0.1uF caps in it as well as a big capacitor on the LED power rails.

8

To me, it seems like it could be a timing thing. I could hook up the signal line to my oscilloscope, but I don't know what I am looking for. Or could it be that some other connection on the microcontroller is somehow interfering with the signal?

9

Update: Fixed it. It was not a hardware thing, it was a software thing. The fuses were set to use the internal clock rather than the external clock. I flashed the bootloader to set all the fuses, then flashed the sketch and it fixed it.

10

It was not a hardware thing, it was a software thing.

I would say that is hardware or at least firmware. But you could have spotted this with a scope you would be looking for the overall length of a single cycle. It should be 800KHz with a two state duty cycle.

Anyway well done for getting to the bottom of it. I would still add those capacitor for stability and EMI immunity.