Skip to content

SX1262 Driver #63

@anarchyysm

Description

@anarchyysm

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.hsx1262_hal_destroy()
  • components/Drivers/sx1262/sx1262.c / include/sx1262.hsx1262_deinit()
  • components/Applications/test_app/test_screens.csx1262_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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions