LR1121 bootloader-mode-*and*-loader-mode SPI transport, standalone from the running RadioDriver. More...

#include "radio_interface.h"
#include "esphome/core/hal.h"

Include dependency graph for radio_lr1121_firmware_updater.h:

This graph shows which files directly or indirectly include this file:

Detailed Description

LR1121 bootloader-mode-*and*-loader-mode SPI transport, standalone from the running RadioDriver.

Entirely wrapped in IOHOME_LR1121_FIRMWARE_UPDATE so it compiles to nothing unless a user opts in (components/home_io_control/__init__.py's lr1121_firmware_update: block sets the define). Bootloader-mode code is deliberately kept out of RadioDriver and RadioLR1121 — this class reimplements its own SPI transport against SpiAccess directly rather than sharing RadioLR1121's, because RadioLR1121::write_command_() takes a uint8_t length and WriteFlashEncrypted needs 4 + 256 = 260 parameter bytes in a single NSS cycle; that alone rules out sharing the transport, not just the class boundary.

The transport itself is mode-agnostic and always was: update_bootloader()/ verify_bootloader()/updater_reboot() (gated behind IOHOME_LR1121_BOOTLOADER_UPDATE, the bootloader-*rewrite* feature — see ADR 0021) send the 0x81xx opcode family while the chip is running the special loader transceiver firmware in NORMAL mode, not while it is in the bootloader — the 0x8xxx prefix misleads. Only this class's previous users (bootloader-mode only) made it look bootloader-specific.

Takes the firmware image as a (const uint32_t *, size_t) parameter and never #includes the generated image header, so it stays host-testable with a small synthetic image and the ~64 KB blob stays out of every translation unit except the one that generated it.

Definition in file radio_lr1121_firmware_updater.h.