Calling FastLED.show() sometimes causes reboots...

Calling FastLED.show() sometimes causes reboots…

I have an animation program you can find here: https://pastebin.com/ZUpbWwAa

This is to feed a snowflake with 145 neopixels. The arduino waits for a command from the serial port to run an animation. Each command is 6 bytes.

If you care, 1st byte is the address, 2nd byte is the animation I’m asking for, 3rd byte is how long I want the animation to run for, 4th through 6th are parameters for the animation (starting color perhaps, and so on)

So, if I send the command to do a starburst affect (0x06 0x02 0x08 0x00 0x38 0x02), this works fine. The fourth byte (0x00 in the above example) is which hue to start with (assumed full sat, etc…). I wanted to be able to have a white starburst as well so I made a cheat for it where if someone sends a hue of 0x01, it actually gives a white starburst.

Finally, the last byte of the command (0x02 here) is the type of fade. 0 means no fade at all between frames, 1 means there is fading but there will still be something left at the end of the animation and 2 means there is fading and the star will be pretty much black at the end of the animation.

The problem is when I ask for a white star with no fading. If I do that, the arduino resets itself. If I blank out the FastLED.show line on line 327, no more reboots. I can’t figure it out.

Sorry this is so complicated. I’ve got a bunch of arduinos in my christmas show and the snowflake is a new feature for next Christmas , so there’s timing stuff in there as well that looks a little complicated. Oh, and I store geometry information about the star in eeprom to save space.

Finally, I’m not a good coder, just a hacker so be gentle.

Do you see the reboot even if the LEDs are not connected?

I see what you’re getting at. Of course it has to be the power supply not keeping up. It’s at work, I’ll check that theory tomorrow. Thank you.

I noticed you have a in bounds check (line 226) for fill_eeprom_array_with_RGB, but not in the fill_eeprom_array_with_HUE function. Is it possible line 215 could be trying to write to a pixel that doesn’t exist? I think writing to out of bounds would cause a lockup (instead of a restart), but I figured I’d mention it for you to check anyway.

Will’s question is probably the better one. And along that line of thinking, do you have a 1000uF capacitor across your pos/gnd connections on your strip?

With my white color hack I’m phasing out the rgb functions to save space. Wasn’t using them at all in this test anyhow. Thanks though.

I do have caps galore on the snowflake. Pretty sure it’s power starving as I use to have the snowflake at 150 power and only recently bumped it to 255.

You can check it with a voltmeter. I think in case of no fade white (i.e. all LEDs are on at max) the voltage drop is worse than Arduino can handle.

As a workaround, try using, say
http://FastLED.setMaxPowerInMilliWatts(2500); // this is 5V 500mA

in setup() and see if it fixes the issue.

See also: https://github.com/FastLED/FastLED/wiki/Power-notes

Well, it was the power supply giving up. Better power supply yields no issues. I should have realized this was the issue since it wouldn’t reboot at exactly the same spot each time which should tip me off it wasn’t a software issue. Thanks all for the guidance. Back to coding!