nRF52840 Power Management Stage 1 (Boot Lock) - v2.3 preparation work

[entr0p1]

This commit lays some of the ground work for the upcoming power management fix that allows users to configure the boot lock behaviour.

It is not the full fix yet. The goal is to break up the larger commit into smaller chunks so it is easier to review and softer to merge.

Regression tests done on a Xiao nRF52840 and no issues experienced with the pre-existing lock and recovery.

Improvements:

• MainBoard: Add bool to check if power management has been initialised (later to be consumed by CommonCLI to validate we can safely configure the settings)
• MainBoard: Add bool to validate LPCOMP is supported on the board (gates LPCOMP config so it doesnt wedge on an unsupported board)
• NRF52Board: Rename initPowerMgr() -> pwrmgtInit() to align with the "pwrmgt" prefix being used by any power management related functions in the upcoming new version
• NRF52Board: Add a shutdown reason for "None" so the get pwrmgt.bootreason command doesnt erroneously return "Unknown"
• NRF52Board: Add gate in configureVoltageWake to not arm LPCOMP when power management isn't initialised or the board doesn't support LPCOMP (i.e. we havent defined the AIN pin)
• NRF52Board: Reference the LPCOMP AIN pin directly instead of from the per-board definitions to align to the upcoming deprecation of the per-board static configs
• NRF52Board: Drop LPCOMP hysteresis as it broadens the wake voltage too much and makes the board less likely to self-recover
• NRF52Board: Separate LPCOMP and VBUS wake arm into their own functions

[oltaco]

Looks good for laying the groundwork for a transition to runtime configurable power management.

I think we will need to be very careful not to let users footgun themselves with bad settings when those options do arrive in CommonCLI?

[entr0p1]

Looks good for laying the groundwork for a transition to runtime configurable power management.

I think we will need to be very careful not to let users footgun themselves with bad settings when those options do arrive in CommonCLI?

Thank you!

It's a good callout RE misconfigurations on the CLI. The safeguard is the bypass; in the existing code, boot lock is automatically bypassed if there is external power being fed (VBUS - via the USB port or solar input).

This is kept in the new version of the power management code as well. So, if anyone soft-bricks their device by setting a voltage too high, they can plug it in to power to boot it and change the setting.

Once this one gets merged in, I'll carve out the next batch of changes and put another PR in.