TX_WAIT_THREAD_STACK_SIZE was 1024 bytes, shared by every radio
adapter. On Xtensa (all ESP32/S3 boards) the windowed ABI needs ~3x
the stack of Cortex-M for the same code — Zephyr's own Kconfig
defaults reflect this (IDLE_STACK_SIZE: 1024 if XTENSA vs 320 ARM).
Measured peak usage on Heltec V4 (immediate-mode logging, full TX
cycle including startReceive/lora_config): 1252 bytes — already past
the old 1024 limit. The overflow corrupts the exception frame and
parks CPU0 in _DoubleExceptionVector (LoadProhibited @0x2c), a silent
total freeze at boot. Confirmed via the S3 built-in USB-JTAG:
current thread at crash = lora_tx_wait.
2048 gives ~39% headroom over the measured worst case.
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.
A device-side cable yank often skips the DTR=0 line-state change, so the
companion stayed stuck on the USB interface and rejected every BLE
connection until reboot. Treat USBD_MSG_VBUS_REMOVED as a DTR drop.
extract_via_aes_ctr used the void Utils::sha256, which silently zeroes
its output on PSA failure -> an all-zero AES key -> a constant,
device-shared Ed25519 identity that the degenerate check misses.
Re-inline psa_hash_compute with its status check so a failure reboots.
Production (LOG=n, ASSERT=n, RTT=n, reboot-on-fatal) is now the prj.conf
default; debug.conf is the opt-in bundle. Removed prod.conf and the
logging.conf auto-include; relocated RTT/ASSERT out of the always-on
platform confs so they no longer override the prod defaults.
Add CONFIG_ZEPHCORE_COMPANION_USB so the USB CDC companion transport
compiles independently of logging (default-y on USB-capable companions,
opt-in on ESP32-S3 via esp32s3_usb.conf). Gate all USB sites behind one
ZEPHCORE_USB_STACK macro.
Rework BLE/USB interface arbitration to first-come-first-served: neither
transport evicts a live session. Make active_iface mutation thread-safe
(mutex + atomic claim) across the BLE callback thread and USB workqueue.
Share the ESP32-S3 USB OTG / console DTS via common dtsi includes; enable
uart0 (GPIO43/44) on station_g2 and xiao so the console reroute works.
getEstAirtimeFor() set LDRO from `sf >= 11`, correct only at BW125. Now
matches the driver's should_enable_ldro() (t_sym > 16.38 ms) so the
estimate's DE tracks hardware DE on every SF/BW. Also drop dead
calcRxDelay() + unused MAX_RX_DELAY_MILLIS.
liquidraver