Maker Pro
Maker Pro

Attiny85 Flickers, Reboots With High Input. Where am I going wrong?

supared

Jan 26, 2023
6
Joined
Jan 26, 2023
Messages
6
I'm out of ideas and hoping someone can help. I have a 12v - 15v source. I also have a separate 12v - 15v source that I want to use as an input. I've used a MIC5219 5v regulator to lower both to usable levels for the Attiny85.

When the 5v VCC is applied, I have RGBW LEDs go through a sequence and then stop on one color. From there, if the other 12v signal delivers 5v to the PB1 input on the Attiny, then I double the brightness of the LEDs. The loop continues and it either goes back to normal or remains brighter. The function is like that of a brake light.

The problem is that when I hold the 5v signal on PB1, the lights start to flicker and the Attiny reboots, repeating the initial color sequence.

I've tried pulling down PB1 with a 10k resistor to ground. I've tried swapping the regulator with a series resistor (240 ohm and then 1000 ohm to limit current more) and 0.5w zener limiting the voltage on PB1 to 3.5-4.0v to ensure it stays below VCC. None of these things worked. I'm out of ideas.

Any help would be deeply appreciated.
 

Attachments

  • MMEIPR RGBW R2_1.pdf
    138.6 KB · Views: 1

supared

Jan 26, 2023
6
Joined
Jan 26, 2023
Messages
6
Oh, btw, I also tested my code using a digispark attiny85 board and it worked fine with no rebooting or lights flickering. It uses a 78L05 voltage regulator and adds USB, bur otherwise it is not so different from my circuit. It doesn't have the second voltage regulator, so I test by touching the 5v out from the digispark to the PB1 and it does increase in brightness.
 

Harald Kapp

Moderator
Moderator
Nov 17, 2011
13,651
Joined
Nov 17, 2011
Messages
13,651
No problem with the code but with the hardware.
Each adressable LED can require up to ~ 50 mA. YOu have 28 LEDs which add up to 1.4 A.
The MIC5219 is good for 500 mA only. Therefore when setting the LEDs to high brightness, the voltage regulator is overloaded and switches off, thus causing the reboot. You need a 5 V power supply that is at least capable of 1.5 A or more. You could, for example, use a step-down regulator module to generate the 5 V from teh 12 V at much higher power than the poor MIC5219 can.
 

supared

Jan 26, 2023
6
Joined
Jan 26, 2023
Messages
6
No problem with the code but with the hardware.
Each adressable LED can require up to ~ 50 mA. YOu have 28 LEDs which add up to 1.4 A.
The MIC5219 is good for 500 mA only. Therefore when setting the LEDs to high brightness, the voltage regulator is overloaded and switches off, thus causing the reboot. You need a 5 V power supply that is at least capable of 1.5 A or more. You could, for example, use a step-down regulator module to generate the 5 V from teh 12 V at much higher power than the poor MIC5219 can.
Thanks for replying Harald. This is something I can certainly check and at least gives me another lead. The datasheet (attached) for these LEDs claim 5mA current for R, G, or B and 12mA for White.

From that, I estimated a max of 420mA if I were using all three RGB diodes at once, which I kind-of do on startup. I guess if I were using white I would need to add the 12mA x 28 too. But when this reboot happens, I am only using the red LEDs.

Also, I don't have this problem on the Digispark Attiny85. I think the 78L05 it uses is also 500mA.

I'm actually tripling the brightness. I'll try instead to double it instead and see if the problem improves.

Thanks again for the input!
 

Attachments

  • Shiningopto SK6805SIDE-FRGBW-BW-P6 OP0311 REV A0 EN-1.pdf
    795.1 KB · Views: 1

supared

Jan 26, 2023
6
Joined
Jan 26, 2023
Messages
6
No problem with the code but with the hardware.
Each adressable LED can require up to ~ 50 mA. YOu have 28 LEDs which add up to 1.4 A.
The MIC5219 is good for 500 mA only. Therefore when setting the LEDs to high brightness, the voltage regulator is overloaded and switches off, thus causing the reboot. You need a 5 V power supply that is at least capable of 1.5 A or more. You could, for example, use a step-down regulator module to generate the 5 V from teh 12 V at much higher power than the poor MIC5219 can.
With all red LED's in the RGBW lights lit (brightness at 85) the circuit is pulling 80mA. When I turn the brightness to max (255), I can see it jump to 1xx mA before rebooting. I tried anyways to reduce the max current by turning the 170 instead of 255. It still rebooted after a few moments. By the way. This is the third circuit like this that I've built just to be sure it wasn't a single component that was bad.
 

supared

Jan 26, 2023
6
Joined
Jan 26, 2023
Messages
6
No problem with the code but with the hardware.
Each adressable LED can require up to ~ 50 mA. YOu have 28 LEDs which add up to 1.4 A.
The MIC5219 is good for 500 mA only. Therefore when setting the LEDs to high brightness, the voltage regulator is overloaded and switches off, thus causing the reboot. You need a 5 V power supply that is at least capable of 1.5 A or more. You could, for example, use a step-down regulator module to generate the 5 V from teh 12 V at much higher power than the poor MIC5219 can.
I tried something else, and I believe you are at least partially correct. Because of the restarting, I could not get a good read on actual current draw. I replaced the MIC5219 with an L7805 good for 1A. It wasn't pretty, but it worked. That allowed me to get a read on the current drawn when the button is pressed. It came up to 110mA. 28 LEDs/110mA = 3.9mA/LED. This makes sense because I am only using the red LEDs and brightness is set to 66%. 3.9mA x 1.33 = 5.2mA/LED. This is exactly what the spec calls for.

At the moment, I am never using more than 150 mA. So technically, the MIC5219 should be fine. What I suspect is happening is a spike/ripple when the button is pushed and the LEDs are increasing brightness suddenly.

I recall reading somewhere about putting some buffer around the button press so that it doesn't pick up multiple presses when it should be one. I'm going to find that code and add it. It was a sinple loop using millis() to make sure the button or input was held for at least a few milliseconds. But I think this is the spike that is the real problem here.

Any suggestions how to deal with that?
I'm going to start researching.
 

Attachments

  • 20230126_215749.jpg
    20230126_215749.jpg
    250.1 KB · Views: 1

supared

Jan 26, 2023
6
Joined
Jan 26, 2023
Messages
6
The magic keyword is "debouncing".
Ahh, yes. That was the word I couldn't remember when I was typing last night. I am a Mechanical Engineer and former Navy Electronics Technician. I learned a lot about solid state electronics, but only C++ in college. So, I am learning all of this on my own building on my former experience. I don't expect to do it long. I need to find freelancers to help me with projects ‍ and then eventually I'll hire some full time folks.
 
Top