Board crashes upon cold boot

[LeGuipo]

I've made an ARGB controller for my PC case to manage two fans. The board gets its power from the 5V line of the PC power supply. The setup is supposed to be complete, and everything works fine as expected. However, the Arduino hangs after a cold boot of the PC, and the fans' LEDs do not light up. This issue also happens with the "snake" example program.

I cannot connect another computer via USB to debug it since the issue seems power-related. Instead, I used the built-in LED of the board to pinpoint where the fault occurs. It turns out the issue happens during the ARGB.write section of my code in the main loop:

cli();
// Rotor
for (uint8_t i = 0; i < NOMBRE_LEDS_ROTOR; i++) {
  ARGB.write(rouges_rotor_i[i], verts_rotor_i[i], bleus_rotor_i[i]);
}
// Stator
for (uint8_t i = 0; i < NOMBRE_LEDS_STATOR; i++) {
  ARGB.write(rouges_stator_i[i], verts_stator_i[i], bleus_stator_i[i]);
}
sei();
delayMicroseconds(100);  // Latch the data.

The built-in LED can be lit before this section, but never after it.

Pressing Arduino’s reset button makes everything work fine again. I have already tried inserting a 1-second delay just before this section during the first iteration of the loop, but it still crashes just after that. Extreme input signals have also been tested and are correctly handled by my program. I have not yet modified anything between cli() and sei().

Unfortunately, I lack the expertise to delve into the library's internals to find a solution.

Is there something else I can check or do to ensure the reliability of the first call to ARGB.write() ?

[ClemensAtElektor]

Thank you for your report. Unfortunately, I cannot help you much, because you don't provide a lot of detail. The usual approach to solve problems like this is to simplify the program as much as possible while keeping the problem. In other words, provide the full source code of the simplest program that shows the issue. In your case, I do not know if your program is a super simple sketch or a huge multitasking application, or if you try to control one LED or 10,000.

The library blocks in the function SPI_transfer (called by ARGB.write) that waits for a transfer to complete. If this doesn't happen, the program will wait forever. As at this point interrupts have been disabled by your program, nothing will happen anymore.

As for the reason why it hangs there, I can only guess. Maybe there is a glitch on the +5V supply that confuses the SPI peripheral in some way? Maybe the fan motors starting up produce so much noise that the LEDs get messed up? You could try delaying the start of the program by inserting a delay(5000) (there is no hurry, is there?) as the very first line of setup() before calling ARGB.begin() (that you should do somewhere) to give the rest of the system some time to settle before starting your own stuff.

[LeGuipo]

I’ll prepare a narrowed version of my sketch as soon as possible. I might also borrow an oscilloscope soon to check that power supply and to conduct further troubleshooting.

The program does not multitasking, and has to generate a signal to drive 28 LEDs on the same bus. The computer’s case’s hub then duplicates the signal to identically feed each of the two frontal RGB fans. I use the full CPU speed and the recommended circuit setup. I am actually very happy with the visuals I get from this project and I take the opportunity to thank you for this library that helped me to achieve that result.

Anyway, as I mentioned in my OP, the issue is also reproducible with the "snake" example sketch provided by the library. And the board must be completely shut down without juice still left inside the computer’s power supply. So USB connection is not allowed for troubleshooting the Arduino board in real time. The issue does not happen if I shut down the computer for less than a minute before restarting it. Unfortunately the only devices with WS2812B I have are those fans so I can’t try with something else.

Inside both setup() and loop(), delays have already been tested, but could not prevent the board to freeze upon the first call to ARGB.write. To confirm that is may not be a delay or stability issue, I’ve removed any unnecessary delays from the program and tested pressing the arduino’s reset button immediately after the hang, then it worked fine. That test was executed in less than half a second.

[LeGuipo]

Well, I can’t troubleshoot anything anymore for now because the thing just works every time. The only difference made is the room temperature since the abrupt come back of the summer three weeks ago in my region. It was around 18°C, now it’s around 23°C. This may not be a software related issue after all. This needs to be confirmed next autumn though.

[ClemensAtElektor]

Maybe you have a bad contact or solder joint somewhere, or an unreliable PCB trace?