The ESP32 BLE controller glue guards ble_enc_funcs_reset() on
CONFIG_BT_CTRL_BLE_SECURITY_ENABLE, an ESP-IDF sdkconfig symbol that is never
defined in a Zephyr build. The call is therefore compiled out and the
controller's LE Secure Connections encryption table is left uninitialised, so
SC pairing derives a wrong session key and the link is terminated with HCI
reason 0x3D (MIC failure).
This breaks pairing for SC-capable centrals (e.g. Pixel 7 / recent Android);
legacy-pairing centrals use a different path and are unaffected. The existing
CONFIG_ESP32_BT_CTLR_LE_SECURITY_ENABLE=y only sets .enc_en and does not reach
this guard.
Correct the guard to BLE_SECURITY_ENABLE, which esp_bt.h already derives from
CONFIG_ESP32_BT_CTLR_LE_SECURITY_ENABLE (the Zephyr knob) and already uses for
.enc_en. Carried as a managed hal_espressif patch via the existing
zephcore_apply_patches() mechanism (mirrors the loramac-node patch).
Verified on Heltec Wireless Tracker (ESP32-S3): device reaches security
level 4, pairing complete bonded=1; Pixel 7 bonds over SC and the companion app
communicates; older Samsung still pairs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a board-aware battery SOC system replacing the two independent
linear approximations that existed in the UI helpers.
New helpers/battery_curve.{h,c}: a 21-point (5% step) OCV lookup table
with integer linear interpolation. The default generic LiPo curve is a
weak symbol — any board can override it by dropping a battery_curve.c
into its board directory. CMakeLists.txt selects the board-specific file
when present, falling back to the generic.
Board.h gains getBattPercent() (default 0); ZephyrBoard implements it
via battery_curve_lookup().
Board-specific curves added for boards with measured cell data:
t1000_e, rak_wismesh_tag, thinknode_m6, sensecap_solar, wio_tracker_l1.
ADC multiplier corrections applied across all nRF52840 boards:
- Boards using a correctly-derived 3600×ratio formula get +0.5% to
compensate for nRF SAADC gain error (7200→7236, 6300→6332, etc.)
- rak_wismesh_tag, rak3401_1watt, gat562_30s had multipliers copied
from Arduino's 3.0V AREF formula; corrected to 3600×1.73×1.005=6259
- xiao_nrf52840 (10911) left unchanged — empirically calibrated value
above the theoretical, assumed already correct for that hardware
get adc.multiplier now reports current mV reading and the board's
curve 100% target, making field calibration self-guiding.
liquidraver