Project 11: Custom Bootloader with OTA Updates

Build a dual‑slot A/B bootloader with integrity checks and rollback.

Quick Reference

Attribute Value
Difficulty Level 4: Expert
Time Estimate 2 weeks
Main Programming Language C
Alternative Programming Languages Rust
Coolness Level Level 4: “update‑safe firmware”
Business Potential 4. Real production requirement
Prerequisites Boot flow, flash layout, CRC/SHA
Key Topics A/B slots, integrity checks, rollback

1. Learning Objectives

  1. Design a flash layout with two firmware slots.
  2. Implement image validation and selection logic.
  3. Detect failed boots and roll back safely.
  4. Update firmware via USB/UART.

2. All Theory Needed (Per-Concept Breakdown)

2.1 Flash Layout and Boot Strategy

Fundamentals

A/B bootloaders keep two firmware images. The bootloader chooses the newest valid one and can roll back if the update fails.

Deep Dive into the concept

A typical layout: Bootloader region, Slot A, Slot B, and metadata region. Metadata stores active slot, pending update flag, and version. Bootloader validates checksum or signature before jumping. A watchdog or health check marks success. If the new image fails to confirm, the bootloader reverts to the old slot.

2.2 Integrity Checks (CRC/SHA)

Fundamentals

Integrity checks detect corruption. CRC is fast; SHA is stronger but slower.

Deep Dive into the concept

CRC32 is good for accidental corruption; cryptographic hashes (SHA‑256) are needed for security. In this project, CRC is sufficient unless combined with secure boot. Compute checksum over the image region and compare to stored header.

2.3 Update Transport (USB/UART)

Fundamentals

Firmware can be delivered over USB (UF2) or UART (XMODEM/Custom). The bootloader must verify before swapping slots.

Deep Dive into the concept

USB UF2 simplifies flashing but requires a bootloader compatible with the ROM. UART updates are simple but need a protocol with checksums and timeouts.

3. Project Specification

3.1 What You Will Build

A bootloader that supports A/B updates with integrity checks and rollback. Updates arrive via USB or UART and are written to the inactive slot.

3.2 Functional Requirements

  1. Flash layout with two slots.
  2. Metadata struct to track active/pending slot.
  3. CRC validation before boot.
  4. Rollback on failed health check.
  5. Update transport over USB or UART.

3.7 Real World Outcome

A failed update automatically rolls back to the last good firmware, preventing bricking.

4. Solution Architecture

Boot ROM -> Bootloader -> Validate -> Slot A/B -> App

5. Implementation Guide

5.10 Implementation Phases

  • Phase 1: Flash layout + metadata
  • Phase 2: Integrity validation
  • Phase 3: Update transport + rollback

6. Testing Strategy

  • Corrupt image test
  • Forced rollback test
  • Power loss during update

7. Common Pitfalls & Debugging

  • Metadata corruption
  • Partial writes causing invalid CRC

8. Extensions & Challenges

  • Add encrypted OTA
  • Add secure boot integration

9. Submission / Completion Criteria

Minimum Viable Completion:

  • A/B boot with CRC validation.

Full Completion:

  • Rollback after failed health check.

Excellence:

  • OTA update pipeline with robust logging.