The "Brick-Proof" Bootloader: Designing an A/B Swap Partition

In the unforgiving world of embedded systems, a failed firmware update can transform a functional device into an expensive paperweight. At Hoomanely, where our pet health monitoring devices operate continuously in homes worldwide, device reliability isn't just a technical requirement, it's essential for maintaining the trust of pet owners who depend on our technology for their companions' wellbeing.

The challenge of safe firmware updates becomes critical when devices operate in remote locations without technical support. A single corrupted update could render a pet monitoring system inoperable, potentially missing crucial health events. This drove us to develop what we call a "brick-proof" bootloader architecture, and across thousands of over-the-air updates in the field, we haven't seen a single unrecoverable device.

Our solution leverages dual-bank flash architecture with hardware-backed A/B partitioning, enabling instant rollback and maintaining system availability even during critical firmware failures.

The critical problem: update failure modes

Traditional firmware update mechanisms have fundamental vulnerabilities during the update process. Power failures, communication interruptions, or corrupted firmware images can leave devices in unrecoverable states. The most dangerous scenario is when the bootloader itself becomes corrupted, creating a complete system failure that needs physical intervention.

Our pet monitoring devices face additional pressure from their deployment environment. Unlike industrial systems with dedicated maintenance teams, these devices operate reliably in homes where technical support isn't readily available. A bricked device doesn't just mean downtime, it means potentially missing critical health indicators for a beloved pet.

Analysis of field failure modes revealed several critical vulnerabilities in standard update approaches. Single-bank updates overwrite existing firmware before validation, creating a vulnerability window where device failure during the update means total loss of functionality. Partial write failures can corrupt both bootloader and application code, requiring factory recovery.

Dual-bank architecture: hardware-enforced safety

The foundation of our brick-proof approach is dual-bank flash architecture available in advanced microcontrollers. This hardware feature provides two complete flash banks, letting one bank stay active while updates get written to the alternate bank. The key innovation is how we leverage the hardware bank-swapping mechanism to achieve atomic updates.

Each bank contains a complete firmware image, so the system maintains full functionality throughout the update process. The hardware bank swap operates at the memory controller level, remapping the entire address space instantaneously through a single option bit modification. That atomic operation eliminates the vulnerability window present in software-based update mechanisms.

// Bank mapping logic handles hardware swap state
bool swap_bank = (optsr_cur & FLASH_OPTSR_SWAP_BANK_Msk) != 0;
if (swap_bank) {
    // When swapped: Bank1 logical = Bank2 physical
    physical_bank = (bank_number == 1) ? FLASH_BANK_2 : FLASH_BANK_1;
} else {
    // Normal mapping: Bank1 logical = Bank1 physical  
    physical_bank = (bank_number == 1) ? FLASH_BANK_1 : FLASH_BANK_2;
}

Multi-stage boot process

Our bootloader implements a multi-stage boot process with multiple recovery points. The First Stage Boot Loader (FSBL) resides in protected flash memory and handles initial system validation, while the main bootloader manages application loading and update coordination. The FSBL performs critical hardware initialization and basic health checks before transferring control to the main bootloader, so even if the main bootloader gets corrupted, the FSBL can initiate recovery or activate the alternate bank directly.

Each boot stage validates both code integrity and hardware compatibility. CRC32 validation confirms firmware authenticity, and hardware-specific checks prevent loading incompatible firmware that could damage components. The sequence: FSBL for hardware init and validation, bootloader for application verification and bank management, application as the main firmware with an integrated update client, and automatic fallback recovery on any validation failure.

CAN FD over-the-air updates

Our OTA mechanism uses CAN FD for efficient firmware delivery, leveraging its enhanced payload capacity and built-in error detection. The process begins with comprehensive pre-validation, firmware size checks, compatibility verification, and available space confirmation. Chunked transfer with bitmap tracking means partial transfers can resume without restarting the entire update.

// CAN FD optimized chunk processing
uint32_t bitmap_size = (total_chunks + 7) / 8;
ota_session.chunk_bitmap = (uint8_t*)malloc(bitmap_size);

// Track chunk completion to enable resume capability
if (chunk_received_successfully) {
    ota_session.chunk_bitmap[chunk_id / 8] |= (1 << (chunk_id % 8));
    ota_session.chunks_received++;
}

Atomic bank switching: the safety guarantee

The core safety mechanism relies on atomic bank switching through hardware option bytes. Once new firmware passes complete validation in the inactive bank, a single option bit modification instantly makes it active while preserving the previous version for rollback. This atomic operation happens at the hardware level, eliminating any possibility of a partial completion leaving the system undefined. The previous firmware stays intact and accessible as an immediate fallback if issues show up with the new firmware.

Field performance: zero-brick achievement

Production deployment across thousands of devices has validated this architecture. Over eighteen months of field operation, we've had zero device failures due to firmware updates, including scenarios involving power failures during critical update phases. Update completion rates exceed 99.8% on the first attempt, with failed updates rolling back automatically without user intervention. Average rollback time measures under two seconds. We've encountered no scenarios where devices became unrecoverable due to firmware update failures, even under deliberate corruption tests and simulated power failures during bank switching.

Reliability in critical applications

Pet health events can occur at any time, making device downtime unacceptable. The dual-bank approach lets us deploy sophisticated health monitoring algorithms and machine learning models while keeping the safety net of proven firmware versions, particularly valuable for edge AI applications where new models must ship safely without risking device functionality. Teams can deploy experimental features knowing that any issues result in automatic rollback rather than device failure, which accelerates development while preserving the reliability pet owners depend on.

Implementation insights from production

A truly brick-proof bootloader requires attention to subtle details that only emerge in real-world deployment. Hardware timing considerations, flash memory endurance, and electromagnetic interference all affect update reliability in ways lab testing can't fully capture. One key insight involved the interaction between bank swapping and memory-mapped peripherals, careful coordination keeps hardware configurations valid across bank switches. Flash memory endurance also matters for systems doing frequent updates, and our architecture minimizes option byte modifications by batching validation checks before committing to bank switches.

Beyond basic safety

Production systems benefit from additional recovery mechanisms handling edge cases: intelligent retry logic, progressive timeout handling, and diagnostic capabilities supporting field troubleshooting. Remote diagnostics let us identify update issues without physical device access, and comprehensive logging throughout the update process gives visibility into failure modes. The system also implements intelligent update scheduling that defers automatically during critical monitoring periods.

Key takeaways

Building a truly brick-proof bootloader requires hardware-software co-design that leverages the safety features available in modern microcontrollers. Dual-bank flash with hardware-backed bank swapping provides the foundation for atomic updates that eliminate traditional firmware update vulnerabilities. Multi-stage boot processes, comprehensive validation, and instant rollback together create a system that can handle any conceivable update failure scenario, and field deployment across thousands of devices over extended periods backs that up.