WS2811 ATTiny85 issue

[paulca]

So having used the same circuit a dozen times to run WS2811s I designed and sent off for a PCB to be manufactured.

It doesn't work.  I'm baffled.

I wasted an hour tonight trying to program the ATTiny with a USBAsp, but when I fell back to using the Arduino as ISP again, bingo, it programmed fine.  Then I wasted an hour because I forgot that while the ATTiny85 doesn't have a bootloader you still have to use the "Upload bootloader" to set the clock bits to 16Mhz.  It was only when I used "blink" and found my 1 second delay was a lot more like a 16 second delay that it twigged.

However, with the clock now running at 16Mhz and the data line going to the LEDs showing an appropriately fast slightly shifting square wave with the pauses in the right place (I didn't write the base frequency down)...

It still doesn't work.

There are three things different about this circuit.

1.  I used an actual PCB.
2.  I used a SOIC-8 ATTiny.
3.  This circuit has a pull up on pin 3 (arduino pin 4)

The rest is the same, including the code.  The FastLED demo reel.

The only lead I have is that the fall time on the square wave is far too soft it drops fast initially but then softens out into a curve.  However I have never probed the breadboard or protoboard LED controllers as they just worked.

Is this likely to be some form of track capacitance issue?  Is there anyway to help cure it, or even confirm it?

Capture of the board is here:


The only revision to this board since is reversing the +12V and GND as they were backwards for the DC jack foot print.  So in fact the data line is running under the GND not the 12V rail in the current PCB.

[paulca]

So done a bit of debugging.

From an UNO the LEDs confirm as working, the data output waveform is in the order of 600-800Khz.

Same sketch uploaded to the ATTiny85 produces an output of only 500Hz.

I have confirmed the fuses are set for 16Mhz and uploaded a 2ms delay() square wave using "blink" and confirmed on the scope it produces a frequency of 500Hz.

Still baffled.

[chris_leyson]

Are you using bit-bashing to drive the WS2811s ? I can't see SPI working as the 8-bit Atmel processors insert a single clock delay between 8-bit SPI packets. So to get the delays in your bit bash routine are you using timers, if so, it looks like you've got a prescaler set up wrong. It's also a good idea to put a small, a few hundred ohms, series resistor in the PWM data line.

[paulca]

I'm using this: http://fastled.io/

It can't be anything to do with the software.  I have tested the exact same sketch on an Uno and an ATTiny85 (DIP package) on a prototype board and they work fine.

So it has to be either the SOIC-8 ATTiny85 has differences or my PCB is causing issues.

In case I cooked the ATTiny85 air soldering it, I remade a new PCB hand soldering it, focusing on not heating the chip.  Oddly this seems to have had an effect in that the ATTiny now runs at the correct speed.  But the waveform it produces is absolutely rubbish.

It looks like capacitance.  At the correct frequency the lows never actually get to fall, so I see a low frequency square wave with a saw tooth peak.  The saw tooth is the data.  So rather than seeing a full amplitude 800Khz sqr wave, I get about 400Hz square wave with an 800Khz modulation.

I'm getting fed up and discouraged.

One more thing I can try is soldering one of these SOIC-8 ATTiny85s onto a DIP adapter and trying it on a breadboard to see if these chips are just shit or if it's my PCB.  I could also try hot wiring a DIP Attiny onto the SMD pads and seeing that works, but that does not sound like fun.

[paulca]

So the good news is that most of the problem with the waveform was actually my mini desk scope which has a 1Mhz bandwidth.

So I got the OWON on the case and the bad news is the waveform is still broken.

Watching this on the scope I can see the data, I can sees 1s and 0s and when zoomed out I can see the patterns, such as the tracers moving across the waveform.

However I believe that fall time is far too slow for the LEDs to register.

Is there any suggestions as to how to fix this?

I did try a 100R and a 220R resistor on the data line, no effect.  I tried powering the LEDs from an separate PSU, no effect.

[paulca]

Ah ha!

A 100R pull down on the data line sharpens the fall time and the LEDs suddenly spring into action.

So now what I have work out is what size of resistor should I use.  A 10K did nothing, actually made the waveform worse, but a 100R pull down will pull an awful lot of current though the uC.

The ATTiny pins are capable of 40mA, if I half that for engineering grace, that means I can only really afford a 250 Ohm resistor.  I'll start at 1k and work down, but no lower than a 220Ohm.

[paulca]

1k works, 2k2 doesn't.  1k will only pull 5mA.  So I soldered the botch resistor onto the back of the board.

Now I can proceed

Thanks guys.

[chris_leyson]

Hi glad you got it working. I must admit WS2811s and 2812s do some strange things sometimes. I was going to say it can't be capacitance because that would effect the rising and falling edges equally. I would have thought that the ATTiny output drive should be good enough but then again the last time I used WS2812s I used a 74HCT1G08 buffer and 330 Ohm series resistor driving the string. The buffer was in there to translate 3.3V logic levels and it just wouldn't work without the series resistor.

[cv007]

You sure that data pin is set to an output? I have not touched an avr in many years, but I think if its set to an input a write of 1 will turn on the pullup and a write of 0 will disable the pullup. Which somewhat is similar to what you show- pullup on drives high (although weakly), and the pullup off would float. Maybe your breadboard version is the same, except the 'float' stage goes down fast enough from whatever is hanging on the pin in the breadboard configuration.


datasheet 10.2.1

If PORTxn is written logic one when the pin is configured as an input pin, the pull-up resistor is activated. To switch
the pull-up resistor off, PORTxn has to be written logic zero or the pin has to be configured as an output pin.

[paulca]

You sure that data pin is set to an output? I have not touched an avr in many years, but I think if its set to an input a write of 1 will turn on the pullup and a write of 0 will disable the pullup. Which somewhat is similar to what you show- pullup on drives high (although weakly), and the pullup off would float. Maybe your breadboard version is the same, except the 'float' stage goes down fast enough from whatever is hanging on the pin in the breadboard configuration.

All the port settings disappear off into the library.  It's not just the breadboard that worked I also have an ATTiny on a little prototype board in the same configuration, no pull down needed.  So the only two things different here are the PCB and the SMD version of the chip.  I even tried using DuPont wires to match the prototype board for connecting the LED data line.  Seems the 1K resistor was the only thing that worked.  <shurg>  One botch resistor on the back side of the board won't even be visible with the case lid off.

Effectively running WS2811s is pushing the ATTiny to it's limits really.  I tried to program a string of 144 LEDs with one and got a nasty surprise when the IDE reported I didn't have enough memory to create 144 LED instances.

The FastLED library, as far as I understand writes the data high low routines in assembler underneath to ensure the timing which is very, very tight, something like 0.5us.  +-150ns.

As a final grumble about the ATTiny.  Atmel/microchip are taking the piss with the SOIC-8 package.  It barely fits on a standard footprint, it's considerably wider than most other SOICs I have seen.

If you are thinking of making a PCB for one, make sure and choose LONG pads.

[cv007]

I don't anything about fastled, but I found this-
https://github.com/FastLED/FastLED/blob/master/fastpin.h
and maybe you are ending up in this place-

Code: [Select]

inline void setOutput() { /* TODO: Set pin output */ }
inline void setInput() { /* TODO: Set pin input */ }where the code is not setting the pin as output, but is still writing to the port, hence getting only the pullup on/off.

You could also set the pin as output yourself, to make sure. I would want to know that the pin is set to an output just to eliminate the scenario I described.

It barely fits on a standard footprint,

Always check the datasheet. I always make my own footprints from the datasheets. With good pcb software it is fast/simple to make footprints and will always be right (well, mostly, since I still make mistakes).

The datasheet shows 2 soic8 packages.

[paulca]

I don't anything about fastled, but I found this-
https://github.com/FastLED/FastLED/blob/master/fastpin.h
and maybe you are ending up in this place-

Code: [Select]

inline void setOutput() { /* TODO: Set pin output */ }
inline void setInput() { /* TODO: Set pin input */ }where the code is not setting the pin as output, but is still writing to the port, hence getting only the pullup on/off.

You could also set the pin as output yourself, to make sure. I would want to know that the pin is set to an output just to eliminate the scenario I described.

It barely fits on a standard footprint,

Always check the datasheet. I always make my own footprints from the datasheets. With good pcb software it is fast/simple to make footprints and will always be right (well, mostly, since I still make mistakes).

Yea, my version of FastLED has got:

Code: [Select]

    inline void setOutput() { pinMode(mPin, OUTPUT); }
    inline void setInput() { pinMode(mPin, INPUT); }

So they are implemented in my release anyway.

On footprints, yes I should have checked, I was foolishly assuming that SOIC-8 is SOIC-8, a standard footprint like DIP.  Then again there are normal DIPs, wide DIPs, narrow DIPs.

KiCAD makes footprints easy, but as you point out it's so easy to make a mistake.  I had to get the manufacturer to suspend production (got them just in time) because my DC Jack foot print was back to front!  Also, I cooked the first ATTiny I put onto this PCB, because that ISP header in the lower right corner has 5V and GND swapped!  The MCU did not enjoy 1A of -5V from the programmer, both got quite hot and upset and I have a blister on my finger as witness.  "Is that getting ho... aahh f****$%^$%!"    That was easy fixed I just make an adapter with DuPont leads.

[cv007]

Yea, my version of FastLED has got:

Yes, so does the link I provided, but also has an #if/#else defined to choose which one.

In any case, I would still want to know that the pin is set to an output. Put in a line of code to do it yourself and see if it makes any difference.

There is no reason the pin can't sink as well as source (when set to an output). The output sink is a lot stronger than your pulldown resistor.

but as you point out it's so easy to make a mistake.  I had to get the manufacturer to suspend production

Making a footprint, and making a mistake is easy to solve- print out the footprint, lay the part on it. Correct if needed. I'm sure much easier than suspending productions.

[paulca]

Yea, my version of FastLED has got:

Yes, so does the link I provided, but also has an #if/#else defined to choose which one.

In any case, I would still want to know that the pin is set to an output. Put in a line of code to do it yourself and see if it makes any difference.

There is no reason the pin can't sink as well as source (when set to an output). The output sink is a lot stronger than your pulldown resistor.

but as you point out it's so easy to make a mistake.  I had to get the manufacturer to suspend production

Making a footprint, and making a mistake is easy to solve- print out the footprint, lay the part on it. Correct if needed. I'm sure much easier than suspending productions.

I'll add a pinMode(3, OUTPUT) just in case.

The footprint was absolutely fine, it was that I had labelled the feet back to front.  If you look at the image, it looks great.  I was only about 5 minutes after I hit "SEND" on the website that I was sitting looking at the DC jack on the bench and had that sinking feeling, "Uh oh."

[cv007]

just in case

Its a one time test. Its either being set properly, or not. If it is not, your problem is solved, if it is already being set to output, no need to do it again. Set the pin as output yourself, eliminate the pulldown, check the output. Or, you can simply check if the ddr bit is set and go into an endless loop if not- if gets in endless loop (nothing happening), ddr bit is not being set to  output. Again, a one time test.

When you know, you will either have solved the problem, or eliminated a possible cause.