0.2pcb/0.3pcb/0.4pcb/0.5pcb - RGB leds might come up with random color

[colinoflynn]

Not repeatable, but some LEDs seem to come up with random color (seen on 1/6 boards so far). Hypothetically related to data line getting pulled down on start-up, and may also have some toggling due to the power supply sequencing.

May try to change the MOSFET gate to have a pull-down instead of a pull-up, which will result in the data line being held high.

I've also seen some reports of people having issues with the WS2813B leds & them being sensitive to solder temp:

• https://www.eevblog.com/forum/projects/am-i-just-unlucky-or-worldsemi-ws2813-leds-are-crappy/
• https://www.makerfabs.cc/article/why-ws2812-sk6812-failures-after-smt-soldering.html

Hard to troubleshoot with small batch size. Will make the pull-down option on next rev or will test with a simple PCB mod:

[colinoflynn]

There is now a pull-down by default, that will result in the LED input being held high. Check if that works better.

[alees24]

A couple of other points: Although LEDs have on a couple of occasions been observed to illuminate spontaneously without having previously been programmed with valid data, the normal failure mode is that the 5V rail has not fully discharged and the RGBLEDs have internally retained their most recently-programmed state. It is to this colour, rather than a random colour, that they commonly return when normal power is restored.
This is suspected of happening on all boards, having been repeatedly demonstrated on the two that we have in the lowRISC office, but it is not normally observed on other boards because they have not recently been programmed with colour information.

[colinoflynn]

There may be two separate issues here, but not sure if worth making two issues:

1. The random colour power-on which is observed so far only on one PCB.
2. The memory effect - this is due to the 5V rail going down slower than the 3.3V rail. Also I'd put into this item the problem of the FPGA being reset/reprogrammed, and no longer using the RGB led.

Possible solution to 2 is to use the RP2040 to drive a power-off sequence to the LED when the RP2040 detects the 'done' pin indicating the device isn't programmed (either on power-on, OR if the device is reprogrammed from any interface). This would avoid needing a separate power enable for the RGBLED, which will require shuffling a FPGA pin.

I've tested the "fix" I pushed (pull-down) and it doesn't fix the reset/memory issue. TBD if it fixes the random colour issue, as that needs to be tested on the board that exhibits it.

[alees24]

With the pull down mod (but, just to confirm, still the slow MOSFET) the original 'problem board' seems to have lost its ability to retain and reinstate colours beyond about 3 seconds. Disrupting the power for up to about 3 seconds still exhibits the memory effect, although looking at the signals using the analog inputs of the logic analyzer, there is now no glitching of the DIN/BIN line to the RGBLEDs and it rises along with the 5V rail, tracking it exactly through the 1k pull up, with no lag.

These devices interpret the DIN/BIN being low for >= 280us as the 'reset' signal and set the LEDs to the programmed value. In normal use the delay between programming and signaling a reset seems not to matter, and note that it's not the rising edge of the DIN/BIN that triggers the change, but still being low after ~280us. Holding it low when idle, and then issuing the programming sequence just once in response the 'nav' button being pressed, I am able to set the LEDs to the colour of my choosing using the DIP switches.

It is true that DIN/BIN takes > 280us to reach the 2.7V 'Vin high' threshold at power on, but that's because it's taking that long for the 5V rail to rise from a quiescent level of ca. 630mv to 2.7V, and although I guess there's a chance that a shorter rise time would sidestep the memory effect, it seems unlikely that it can be eliminated completely without explicit programming of the LEDs on power up.

No more information at this stage on the 'unprompted, random and not remembered illumination' It hasn't been seen again post-mod, but it was a very infrequent occurrence anyway.

[alees24]

@colinoflynn I wonder whether the memory effect could be sidestepped by experimentally removing C5 which would both cause the 5V rail to drop faster, and produce a sharper rise when powered is connected. A smaller capacitor may eliminate the memory effect?

Whilst the LEDs are illuminated, if the FPGA is reprogrammed with a design that doesn't drive the LEDs, they will of course remain on indefinitely. The user is surely less likely to remove the power for just a couple of seconds, so if this issue requires further discussion/attention, we should perhaps focus on the the FPGA reprogramming case rather than the memory effect.

It's not really on a par with accepting that memory contents must be put into a known, defined state at power up/reset, since there is a clear user-visible effect, but personally I'm happy for us to leave this to 'Sonata 2' as and when that happens, and just record it as a quirk/erratum of this board.

[colinoflynn]

Ok, good news on random light I think then right? I'll probably leave major fixes to a possible later rev, although with this first batch we'll have a better sample size to actually see if we get random power-on "normally" either (e.g., maybe your board had other soldering issues beyond those we know about).

I wouldn't want to mess with C5 as that could impact the stability of the (more important) regulators.

On the next rev (e.g., for production) I'll see if I can at least throw a connection to the RP2040, which we could use to clear it if we're really bothered by it later. But I think for now it sounds like we've reached a good enough state to continue with production...

[colinoflynn]

There is now a 07 rev which allows the RP2040 (via a 1K resistor) to drive the RGBLED. If needed we can have the RP2040 drive this potentially.

[colinoflynn]

Leaving open until confirmed RP2040 "fix" works fully.

[colinoflynn]

The RP2040 can turn these off OK. Quick code to do so for ref:

import machine
import neopixel

class NeoPixelInverted(neopixel.NeoPixel):
  def __init__(self, pin, n, bpp=3, timing=1):
    super().__init__(pin, n, bpp, (850, 400, 450, 800))
    
  def write(self):
    self.pin.value(1)
    super().write()
    self.pin.value(1)
    
np = NeoPixelInverted(machine.Pin(15), 2)

np[0] = (0, 0, 0) # off
np[1] = (0, 0, 0) # off

np.write()

#Back to floating so FPGA can take control again
p15 = machine.Pin(15, machine.Pin.IN)