nRF devices with LTO batteries: PWRMGT_VOLTAGE_BOOTLOCK too high; prevents boot

[TheSlowGrowth]

For RAK4631 devices, PWRMGT_VOLTAGE_BOOTLOCK is set to 3.3V.
While this is fine for Lithium Ion batteries, it prevents booting without a USB connection when using LTO batteries, where the 0% voltage is around 1.8V.
This affects the popular mesh base boards by uart.cz if used with the LTO battery pack from the same website, and any other device using a different type of battery.

Obviously, the voltage can be adjusted using the PWRMGT_VOLTAGE_BOOTLOCK definition. But this would require a dedicated firmware for each potential battery chemistry, which sounds like a nightmare from the user perspective and the development perspective.

So ideally, the cutoff voltage would be user configurable in the node configuration.

Happy to help work out a solution and provide a PR. Let's discuss.

tagging @entr0p1 , I see you added the bootlock feature recently.

[entr0p1]

Hi,

I'll take a look at this. I'll need to look at the schematics and see how this board powers the Rak. I would've thought something like this would power the board by 5V rail not the battery connector since the MCU becomes unstable below 2.5V (and that is the manufacturer rated minimum if I recall correctly). But I'll confirm.

[TheSlowGrowth]

There's a DC/DC (U2) that generates 3.3V from either the USB power or the battery power (switched through U5 and U6).
VBATT is hooked up to AIN0 which is what fires the voltage bootlock, as far as I can see.

I think tailoring this to a particular boad isn't a good solution. If the voltage bootlock is tied to the battery voltage, then there must be a user configuration for selecting the voltage. The power delivery is very much dependent on the particular installation. Some may use a DC/DC boost converter (where battery voltages <2.5V are still totally fine to boot). Others may use a buck converter or a linear converter, where VBAT must be >2.5V.

[entr0p1]

Appreciate the legwork you've done, thanks heaps. I'll be at a computer a bit later and will look in more detail. Rest assured I'm keeping an open mind and mindful not to dismiss that the boot lockout solution might not be a good fit, so if I'm challenging you while we dig through this don't see it as resistance just as me seeking to understand better :)

My (albeit probably misguided) assumption here was that an externally managed power solution wouldn't be connected to VBATT and, if it was, that it would be regulated to the typical voltage the board would expect from a Li-ion battery.

In cases where we are feeding VBATT from a Li-ion, if we're below 2.5V (or even before this) we are very much in brownout territory. Voltage might be within tolerance, but as soon as we pull more power than baseline (e.g. boot advert), the cell can't provide it and the voltage drops too low. Then the board browns out.

This has been observed on Rak boards as well as others.

The challenge here is that this particular method (boot lockout) can't be a preference; we need to make the decision before the flash is initialised to prevent corruption and make the board able to safely boot when voltage normalises (if it browns out and the flash doesn't get corrupt, we still have a crashed board needing a physical reboot). No flash unfortunately means no preference file access at this stage of boot.

That said, I think we can make this work. I'll come back to you later once I've had a look in more detail.

[TheSlowGrowth]

don't see it as resistance just as me seeking to understand better

No problem, engineering is all about challenging assumptions. I appreciate the disclaimer, though!

we need to make the decision before the flash is initialised

Fair point, I wasn't aware of this limitation.

I guess another option could be to scale the ADC voltage to make the LTO voltages look like LiIon voltages (e.g. through adjusting the resistive divider, or potentially a opamp based scaling circuit). The SoC vs voltage curves of these two battery types look similar enough that the brownout detection would be fine and the charge % display in the app would become more useful (it's useless with LTO batteries).
However, I don't like the idea that the telemetry would show 3.3V when it's actually just 1.8V or so. It's bit of a hack, really.

I guess adding another PIO target with a different brownout voltage is always an option, but it would clutter up the list in the flasher very quickly.

Anyway, looking forward to hear from you. If there's anything I can help with, let me know. I have a the toochain setup already, and a Daplink adapter at hand to try out a few quick hacks if that's helpful.

[marcelverdult]

This is really bad. The board runs from 1,8V because it has a step-up. And we use it with LiFePo4 Batteries. So now our repeater don’t reboot even though they couöd run perfectly fine. And LiFePo4 have 60% capacity legt at 3.3V

[mattzzw]

In cases where we are feeding VBATT from a Li-ion, if we're below 2.5V (or even before this) we are very much in brownout territory

According to the NRf52480 data sheet chip brown out condition is met with VDD < 1.7V.
As LTO is pretty much empty with 2,6V (as is the case with Liion batteries) I would assume shifting the PWRMGT_VOLTAGE_BOOTLOCK voltage to 2,7V would be sufficiently safe.

A PWRMGT_VOLTAGE_BOOTLOCK value of 3.3V seems overly conservative to me. But maybe I am missing something else.

[TheSlowGrowth]

The image (and as a result your conclusions) apply to LiFePO ₄.
The voltage range of LTO is 1.8V (0% SoC) to 2.8V (100% SoC)

[mattzzw]

Thanks, my mistake indeed as I took the above image for LTO voltages. D'oh.

[TheSlowGrowth]

The issue is that the brownout voltage is

• 3.3V for Li-ion
• 2.6V for LiFePO4
• 1.8V for LTO.

There's no single voltage that fits them all.

In a properly designed, dedicated hardware product, the brownout detection should be realized with a hardware chip, or set with solder jumpers on the hardware itself. But of course we don't have that luxury here, running on various platforms built from off the shelf parts.

I wonder about this limitation of the flash being not available during this stage of boot. Surely some part of the flash is available, since the program code is loaded from somewhere. I'm not too familiar with the memory layout of the nRF mcu. But would it be feasible to store the brownout voltage in the same flash memory region?

[mattzzw]

The issue is not the flash itself but the flash filesystem partition becoming available much after the initial voltage check.
E.g. in simple_repeater/main.cpp the board.begin() function does the voltage check way before the radio, display and filesystem are initialised.
I don't know the reasons for this order. However, I think that changing the order to board, flash fs, voltage check, display, radio would make more sense as display and radio are way more power hungry than getting the flash fs ready, I suppose.

One option would be to make the cutoff voltage a configuration parameter.
The challenge could be timing. But I don't know how much a couple of extra milliseconds of getting the flash fs ready would actually be an additional risk of browning out on a low battery.

[entr0p1]

The challenge could be timing. But I don't know how much a couple of extra milliseconds of getting the flash fs ready would actually be an additional risk of browning out on a low battery.

The issue isn't so much the flash consuming enough power/time to brown the board out, its that if the flash fs is mounted we risk corrupting it and breaking the config.

A PWRMGT_VOLTAGE_BOOTLOCK value of 3.3V seems overly conservative to me. But maybe I am missing something else.

It is indeed conservative and I actually meant to lower it before the final commit. I'm going to suggest we go to 3.05V, but with some extra conditions. Read on and see what you think.

This is really bad. The board runs from 1,8V because it has a step-up. And we use it with LiFePo4 Batteries. So now our repeater don’t reboot even though they couöd run perfectly fine. And LiFePo4 have 60% capacity legt at 3.3V

In the short term a reasonable workaround is to downgrade to 1.11.0 or compile 1.12.0 with the -D NRF52_POWER_MANAGEMENT build flag removed for the variant.

OK, I've consulted with some folks who've spent a lot of time in the code base. There may be a way to pass some settings through to the board before the flash is init'd. With this in mind, I'm thinking the fix could be:

• Add in a new setting to configure battery chemistry - lto, lfp, lipo (we can then use this to inform the correct % for the battery)
• Use a dynamic voltage threshold for boot lockout based on this
• Add in a setting to enable/disable boot lockout and have it disabled by default

What does everyone think? I'll start chipping away at it tomorrow.

There was a second option I considered but have ruled it out for complexity at this time. I'll detail it below for posterity in case the devs prefer this.

###########################################################################

Measure VDD voltage and compare it to VBAT. If VDD measures ~500mV or more above VBAT, the board is almost certainly receiving regulated voltage and therefore should bypass boot lockout.

Current workflow

• Configure VBAT ADC, read VBAT once at boot.
• If PWRMGT_VOLTAGE_BOOTLOCK == 0 -> skip.
• If USB VBUS detected -> skip.
• Log VBAT reading
• If VBAT > 1000 mV and VBAT < threshold (3300mV) -> enter SYSTEMOFF with boot‑protect shutdown reason (LPCOMP armed on supported boards). Otherwise continue boot.

Proposed workflow

• Configure VBAT ADC, read VBAT once at boot.
• If PWRMGT_VOLTAGE_BOOTLOCK == 0 -> skip.
• If USB VBUS detected -> skip.
• Log VBAT reading
• Read VDD (SAADC VDD/4).
• if VDD >= 3050 mV and VBAT < 3000 mV and (VDD - VBAT) >= 500 mV -> log and skip lockout (treat as regulated/boosted supply).
• if VBAT > 1000 mV and VBAT < 3000 mV -> enter SYSTEMOFF with boot‑protect shutdown reason (LPCOMP armed on supported boards). Otherwise continue boot.

[mattzzw]

What does everyone think? I'll start chipping away at it tomorrow.

Thanks for your work on this. I think having power management, especially battery chemistry configurable is the right way to go.