The `set freq <mhz>` handler saved the new frequency to prefs, then
reverted _prefs->freq to the old value in RAM to keep the running radio
on the old params until reboot. But _prefs is the source of truth for
every savePrefs(), so:
- `get freq` / `get radio` reported the old value right after a
successful `set freq`;
- the next savePrefs() from any other `set` command (e.g. `set rxduty`)
rewrote the old freq back over the persisted new one, losing the
change on reboot.
Mirror the `set radio` handler: keep _prefs->freq = f and freeze the
running radio on the old freq via freezeRadioParams() instead of
reverting the pref. Semantics unchanged (applies at reboot; the live
radio stays on the old freq until then); _prefs now correctly retains
the new value so `get` reflects it and later saves can't clobber it.
freezeRadioParams() is implemented for the Repeater and Room Server
roles; the CommonCLI base default is a no-op, so other roles are
unaffected.
Verified on Seeed XIAO MG24 + Wio-SX1262 (Repeater role, built from
release v20260704.220543 + this patch): `set freq 903.0` is retained by
`get freq` immediately and survives an intervening `set rxduty` + reboot.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fix Heltec V4 display (Vext PMOS polarity) and Xtensa TX-wait stack overflow.
Conflict in heltec_wifi_lora32_v4_procpu.dts resolved: kept the corrected
BatADC header line from 247ca65 (GPIO1 = ADC1_CH0 / &adc0, GPIO37 active-HIGH)
and took the PR Vext change (GPIO36 active-LOW PMOS rail switch).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
The V4's Vext rail switch is a PMOS: GPIO36 LOW turns the rail ON.
The DTS drove it ACTIVE_HIGH, leaving the OLED (and its I2C pull-ups)
unpowered — the rail floats at ~1.6V and SSD1306 init always fails
with -ETIMEDOUT.
Verified on hardware with a multimeter: GPIO36 high = 1.6V on Vext,
GPIO36 low = 3.3V, display works.
This matches what the working Arduino MeshCore firmware actually does
with the pin, despite its PIN_VEXT_EN_ACTIVE=HIGH define:
RefCountedDigitalPin::begin() initialises the pin to its *inactive*
level (LOW), and the V4 OLED build constructs the display with a NULL
periph_power (variants/heltec_v4/target.cpp) so nothing ever claims
it HIGH. GPIO36 is therefore driven LOW continuously under Arduino —
the exact state this fix reproduces via an ACTIVE_LOW boot-on
regulator.
liquidraver