zmk icon indicating copy to clipboard operation
zmk copied to clipboard

Persistent RGB power consumption until reset

Open MickiusMousius opened this issue 5 months ago • 9 comments

After deactivating the RGB on a board with a NRF52840 the controller continues to consume an extra 1mA until the board is rebooted.

The board I've tested this on has a separate power control for the RGB so consumes less than 2uA when not in use.

I've verified that this isn't a pin leakage issue by setting the SPI pin for the LED strip to an unconnected pin on the controller, I'm still observing the same behaviour even though there is nothing attached to that pin.

MickiusMousius avatar Jul 12 '25 12:07 MickiusMousius

I've tested this with an oscilloscope today now, when the RGB is on there's a clear signal on the data pin for the RGB, when the RGB is off there's no signal.

This definitely looks as though the processor is wasting cycles on something.

MickiusMousius avatar Jul 13 '25 04:07 MickiusMousius

Yes if SPI3 is used as the signal output for RGB, it will be timed to produce additional CPU work (guessing, as there will be a fixed frequency producing power consumption at this point). change SPI3 to SPI2, Of course the circuit needs MOS to switch the power supply of the RGB, otherwise the RGB LED does not light up is also have and large current counts well.

afayge avatar Aug 01 '25 02:08 afayge

Hi, thanks for that.

Changing to SPI1 or 2 does improve the consumption.... although, it also stops the RGB from working at all.

In the debug log I get a whole lot of this (clearly I've done something wrong):

Image

I checked the nordic doc, and what you say adds up, the SPI3 device is the fast one with high energy consumption.

I did not realise that the SPI labels referred to the internal device & was operating on the assumption that these were in fact just aliases and an attribute would need to be set to force the use of a specific device otherwise zephyr would make decisions for you.... seems I was wrong on that front too!

It's a stretch but do you have a working configuration that uses SPI2 so I can verify this?

MickiusMousius avatar Aug 01 '25 07:08 MickiusMousius

-pinctrl,dtsi, pinctrl changed all spi3_xxx to spi2_, and .dtsi &spi3 to &spi2, pinctrl-0 = <&spi3_default>; and pinctrl-1 = <&spi3_sleep>; to pinctrl-0 = <&spi2_default>; and pinctrl-1 = <&spi2_sleep>;

maybe you can search all spi3 and replace to spi2 in your board files.

afayge avatar Aug 06 '25 02:08 afayge

Hey, sorry for the slow reply. What you've described is precisely what I did.

I even went so far as to remove my display SPI device. Still no dice. Though I won't discount the possibility of having made some trifling error in doing so.

I will try again this coming weekend & report back, thank you for the follow up.

Cheers

Mickius

MickiusMousius avatar Aug 11 '25 08:08 MickiusMousius

Wanted to add that I'm running in to the same issue (As discussed on discord: https://discord.com/channels/719497620560543766/1410186780585627688). Adding CONFIG_ZMK_RGB_UNDERGLOW_ON_START=n makes the power draw normal until you turn on the RGB LEDs and then back off again which makes it be in the off but consuming 1mA state.

VeyPatch avatar Aug 27 '25 09:08 VeyPatch

I've just got back to this and can confirm the fix from @afayge

However, unlike with SPI3 use of SPI2 (for example) requires that SCK is also defined. I was missing this detail!

I'd suggest this is not a bug so much as a documentation issue.

MickiusMousius avatar Aug 28 '25 08:08 MickiusMousius

I agree that this could be useful if documented. I'm not sure where it would be best to put this information under ZMK though, if at all. If you have a good idea a PR is very welcome though.

nmunnich avatar Aug 28 '25 11:08 nmunnich

Well the ZMK docs has a example implementation that uses spi3: https://zmk.dev/docs/development/hardware-integration/lighting/underglow. I think just changing this to spi2 and having a comment about adding SCK needing to be an unused pin could be enough for now.

VeyPatch avatar Aug 28 '25 11:08 VeyPatch