Persistent RGB power consumption until reset
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.
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.
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.
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):
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?
maybe you can search all spi3 and replace to spi2 in your board files.
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
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.
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.
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.
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.