I encountered problems with LoRa initializaton on test firmware, just check if have the same problem here
SX1262 — re-running the LoRa test in the same boot
Symptom
The LoRa test (test_screen_lora) passed the first time it ran after boot,
but failed on every subsequent run without a reboot. The chip was healthy;
only the re-run reported a bad status.
P4 log (2nd run):
W SX1262_HAL_ESP32: HAL already initialized
I SX1262: Hardware reset complete
I SX1262_FSM: FSM initialized → STDBY_RC
I SX1262: Init OK — status: 0xA2, chip_mode: 2 (STDBY_RC=2) <-- init reads OK
E TEST_SCREEN: [lora] status 0x15 looks bogus (chip silent?) <-- test's get_status is wrong
Diagnosis
It was not a hardware/wiring problem: in both runs sx1262_init() reads
status 0xA2 (chip_mode 2 = STDBY_RC), so the radio responds correctly every
time. The failure was a non-idempotent re-init in the driver:
sx1262_hal_create() early-returns with "HAL already initialized" on the
2nd run (it sets s_ctx.is_initialized = true on first use and never tears
down). So the SX1262's SPI device handle, mutex and GPIO setup from the
first run persist into the second.
- With that stale HAL/SPI device, the test's separate
sx1262_get_status()
read came back corrupted (0x15, chip_mode 1 — a value that doesn't exist on
the SX1262), even though sx1262_init()'s own status read was fine.
The first run (fresh hal_create) always worked, so the fix is to make every
run start from a freshly created HAL/SPI device.
Fix
Add a clean teardown path and call it at the start of each test run:
sx1262_hal_destroy() (sx1262_hal.c) — spi_bus_remove_device() for the
SX1262, delete the SPI mutex, clear s_ctx.is_initialized. The shared SPI3
bus is left initialized because the ST7789 display uses it too — only the
SX1262 device is removed, not the bus.
sx1262_deinit() (sx1262.c) — sx1262_stop() (kill the IRQ task if
running) → sx1262_hal_destroy() → clear s_is_initialized. Safe to call
when nothing is initialized (no-op).
test_screen_lora() calls sx1262_deinit() before sx1262_hal_create().
Result: on the first run sx1262_deinit() is a no-op; on every later run it
fully tears the driver down so sx1262_hal_create() rebuilds the SPI device
from scratch — every run behaves like the (working) first run.
Files touched
components/Drivers/sx1262/sx1262_hal.c / include/sx1262_hal.h — sx1262_hal_destroy()
components/Drivers/sx1262/sx1262.c / include/sx1262.h — sx1262_deinit()
components/Applications/test_app/test_screens.c — sx1262_deinit() at test entry
Note
This is a test-harness re-entrancy fix. The SX1262 hardware and wiring on the
protoboard were correct throughout (CS=24, RESET=25, BUSY=17, DIO1=8, shared
SPI3 MOSI=19/SCLK=18/MISO=14).
I encountered problems with LoRa initializaton on test firmware, just check if have the same problem here
SX1262 — re-running the LoRa test in the same boot
Symptom
The LoRa test (
test_screen_lora) passed the first time it ran after boot,but failed on every subsequent run without a reboot. The chip was healthy;
only the re-run reported a bad status.
P4 log (2nd run):
Diagnosis
It was not a hardware/wiring problem: in both runs
sx1262_init()readsstatus 0xA2(chip_mode 2 = STDBY_RC), so the radio responds correctly everytime. The failure was a non-idempotent re-init in the driver:
sx1262_hal_create()early-returns with"HAL already initialized"on the2nd run (it sets
s_ctx.is_initialized = trueon first use and never tearsdown). So the SX1262's SPI device handle, mutex and GPIO setup from the
first run persist into the second.
sx1262_get_status()read came back corrupted (
0x15, chip_mode 1 — a value that doesn't exist onthe SX1262), even though
sx1262_init()'s own status read was fine.The first run (fresh
hal_create) always worked, so the fix is to make everyrun start from a freshly created HAL/SPI device.
Fix
Add a clean teardown path and call it at the start of each test run:
sx1262_hal_destroy()(sx1262_hal.c) —spi_bus_remove_device()for theSX1262, delete the SPI mutex, clear
s_ctx.is_initialized. The shared SPI3bus is left initialized because the ST7789 display uses it too — only the
SX1262 device is removed, not the bus.
sx1262_deinit()(sx1262.c) —sx1262_stop()(kill the IRQ task ifrunning) →
sx1262_hal_destroy()→ clears_is_initialized. Safe to callwhen nothing is initialized (no-op).
test_screen_lora()callssx1262_deinit()beforesx1262_hal_create().Result: on the first run
sx1262_deinit()is a no-op; on every later run itfully tears the driver down so
sx1262_hal_create()rebuilds the SPI devicefrom scratch — every run behaves like the (working) first run.
Files touched
components/Drivers/sx1262/sx1262_hal.c/include/sx1262_hal.h—sx1262_hal_destroy()components/Drivers/sx1262/sx1262.c/include/sx1262.h—sx1262_deinit()components/Applications/test_app/test_screens.c—sx1262_deinit()at test entryNote
This is a test-harness re-entrancy fix. The SX1262 hardware and wiring on the
protoboard were correct throughout (CS=24, RESET=25, BUSY=17, DIO1=8, shared
SPI3 MOSI=19/SCLK=18/MISO=14).