Add LP5562 driver, M1 smoke test, and milestone-based plan

- Integrate LP5562 driver from sibling project (ntag5-samd21-lp562)
  with full doc comments restored
- Update main.rs with complete M1 test: I2C init, GPIO EN, RGBW cycle
- Rewrite DEVELOPMENT_PLAN.md from waterfall to milestone-based groups
  organized by hardware availability (Groups A-E)
- Rewrite STATUS.md with milestone checklist tracking
- Add LP5562 timing constraints and flash script docs to CLAUDE.md
- Add flash_when_ready.sh for auto-flash dev workflow
- Add brainstorm design doc for plan redesign rationale

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/DEVELOPMENT_PLAN.md

@@ -2,333 +2,268 @@
 
 ## Overview
 
-xblink is an NFC-powered LED implant. Development proceeds in phases, starting with dev board prototyping (XIAO M0 + LP5562EVM + NTAG5Link Click) and progressing to a custom SAMD21E PCB suitable for implantation.
+xblink is an NFC-powered LED implant. Development is organized into small milestones grouped by hardware requirements. Each milestone is scoped to roughly one session of work. Abstractions (traits, pattern formats) are deferred until we have hands-on experience with the hardware they'll abstract.
 
-LED controller code is modular via a `LedController` trait — the LP5562 is the primary target, but the architecture supports other LED driver ICs and simple GPIO PWM for single-color LEDs.
+### Guiding Principles
+
+- **Hardware-first**: Get real LEDs blinking before designing abstractions
+- **YAGNI**: No traits, formats, or protocols until we need them
+- **Small milestones**: Each should produce a flashable, testable result
+- **Test equipment**: Multimeter for power budget, logic analyzer (optional) for I2C debugging
 
 ---
 
-## Phase 1: LP5562 Driver Integration
+## Group A — LP5562 Only
 
-**Goal**: Get LP5562EVM running RGBW LED patterns from the XIAO M0.
+**Hardware needed**: XIAO M0 + LP5562EVM + mini-USB cable
 
-**Hardware**: XIAO M0 ↔ LP5562EVM via I2C (A4/A5) + EN on D0/A0.
+### M1: LED Smoke Test
 
-### Tasks
+**Goal**: Verify LP5562 direct PWM control works over I2C.
 
-1. **Copy LP5562 driver** from `../ntag5-samd21-lp562/src/lp5562.rs` into `src/led/lp5562.rs`. This is a complete 757-line driver covering all LP5562 features: direct PWM, current control, engine programming, LED mapping, power-save, and clock config. It is generic over `embedded_hal::i2c::I2c` (1.0).
+Copy the proven LP5562 driver from `../ntag5-samd21-lp562/src/lp5562.rs` into the project. Wire up I2C and GPIO EN in `main.rs`. Light up each RGBW channel to confirm wiring and driver work.
 
-2. **Define `LedController` trait** in `src/led/mod.rs`:
-   ```rust
-   pub trait LedController {
-       type Error;
-       fn set_channel(&mut self, channel: u8, brightness: u8) -> Result<(), Self::Error>;
-       fn set_all_channels(&mut self, values: &[u8]) -> Result<(), Self::Error>;
-       fn all_off(&mut self) -> Result<(), Self::Error>;
-       fn channel_count(&self) -> u8;
-       fn supports_engines(&self) -> bool;
-       fn load_pattern(&mut self, pattern: &[u8]) -> Result<(), Self::Error>;
-       fn stop_pattern(&mut self) -> Result<(), Self::Error>;
-   }
-   ```
+**Tasks**:
+1. Copy `lp5562.rs` → `src/led/lp5562.rs`
+2. Create `src/led/mod.rs` with `pub mod lp5562;` re-export
+3. Update `main.rs`: I2C init (A4/A5, 400kHz), GPIO EN on D0/A0, LP5562 enable → 1ms delay → `init_direct_control(Internal)` → `set_all_current(100,100,100,100)` → cycle through RGBW
+4. Flash and verify all 4 LED channels light up
 
-3. **Add GPIO EN pin** to LP5562 wrapper. The LP5562EVM EN pin is connected to D0/A0 for hardware power control:
-   ```rust
-   pub struct Lp5562Gpio<I2C, EN> {
-       lp: Lp5562<I2C>,
-       en_pin: EN,
-   }
-   ```
-   This wrapper manages the hardware enable alongside the I2C driver, allowing complete power-down for energy savings.
+**Reference**: Sibling project `main.rs` lines 40-114 — proven working sequence with LP5562EVM.
 
-4. **Test sequences**:
-   - Direct PWM: set individual channel colors, verify RGBW output
-   - Current control: set 2-5mA per channel (suitable for EH power budget)
-   - Engine programs: breathing pattern (ramp up/down with branch loop)
-   - Engine programs: RGB color cycle (3 engines with synchronized triggers)
-   - Engine programs: heartbeat pulse (fast ramp, slow decay)
+**Done when**: All 4 RGBW LEDs cycle on the LP5562EVM.
 
-### Reference Code
+### M2: Engine Patterns
 
-The sibling project's `main.rs` (lines 49-114) provides a complete working example:
-- LP5562 init: `enable()` → 1ms delay → `init_direct_control(Internal)` → `set_all_current(100, 100, 100, 100)`
-- Color cycling loop with `set_all_pwm()` and delay
-- This exact pattern works with the LP5562EVM
+**Goal**: Program LP5562 execution engines to run patterns autonomously — the core value proposition.
+
+After engine programming, the MCU can sleep while LP5562 keeps running patterns on its own internal oscillator. This milestone proves the architecture works.
+
+**Tasks**:
+1. Build engine programs using `EngineCommand` builder (already in driver):
+   - **Breathing**: `set_pwm(0)` → ramp up → ramp down → `branch(0, 0)` (infinite loop)
+   - **Heartbeat**: `set_pwm(0)` → fast ramp up → slow ramp down → wait → `branch(0, 0)`
+   - **Color cycle**: 3 engines with staggered phases, synchronized via `trigger()`
+2. Map LED channels to engines via `set_led_mapping()`
+3. Load programs, set engines to Run, verify LEDs animate without MCU loop
+4. Verify MCU can `stop_engine()` and resume with a different pattern
+
+**Done when**: LP5562 runs a breathing pattern while `main()` sits in an idle loop (no `delay_ms` driving the LEDs).
+
+### M3: Hardcoded Pattern Library
+
+**Goal**: Build a set of const patterns in firmware, selectable at boot.
+
+This gives us real pattern data to inform the EEPROM storage format later (M5), without designing that format prematurely.
+
+**Tasks**:
+1. Define 4-5 patterns as `const` or `static` data:
+   - Solid RGBW (direct PWM, no engines)
+   - Breathing (single channel, 1 engine)
+   - Heartbeat pulse (1 engine, asymmetric ramp)
+   - RGB color cycle (3 engines, trigger sync)
+   - Rainbow fade (3 engines, staggered offset)
+2. Simple pattern selector in `main.rs` (e.g., cycle through patterns on each boot, or use a compile-time `const`)
+3. Reduce LED current to 20-50 (2-5mA/ch) to simulate EH power budget
+
+**Done when**: Can flash different patterns by changing a const, each runs autonomously on LP5562.
 
 ---
 
-## Phase 2: NTAG5Link Driver (MCU-side I2C)
+## Group B — Add NTAG5Link
 
-**Goal**: Read and write NTAG5Link EEPROM and SRAM from the SAMD21 over I2C.
+**Hardware needed**: + NTAG5Link Click board + I2C jumper wire
 
-**Hardware**: XIAO M0 ↔ NTAG5Link Click via I2C (shared bus with LP5562).
+### M4: NTAG5 EEPROM Read/Write
 
-**Important**: The MCU accesses the NTAG5Link as a standard I2C slave at address 0x54. This is plain register read/write — completely different from the NFC-side ISO15693 custom commands (0xD2 READ_SRAM, 0xD4 WRITE_I2C, etc.) used by the Python `ntag5sensor` tooling.
+**Goal**: Communicate with NTAG5Link over I2C as a slave device.
 
-### Driver Design
+**Important**: The MCU accesses NTAG5Link as a standard I2C slave at address 0x54 — plain register read/write. This is NOT the NFC-side ISO15693 custom commands used by the Python ntag5sensor tooling.
 
-```rust
-pub struct Ntag5Link<I2C> {
-    i2c: I2C,
-    addr: u8,  // 0x54 default
-}
-```
+**Tasks**:
+1. Write `src/ntag5/mod.rs` — `Ntag5Link<I2C>` struct, generic over `embedded_hal::i2c::I2c`
+2. Write `src/ntag5/registers.rs` — register map constants from `ntag5link.py`
+3. Implement EEPROM block read/write (2-byte block address, 4 bytes per block)
+4. Implement session register read (single-byte address)
+5. Test: write known data to EEPROM via PCSC reader (ntag5sensor), read back on MCU, display result as LP5562 colors (visual verification)
 
-**EEPROM access** (2048 bytes, 512 blocks of 4 bytes each):
-- Read: I2C write 2-byte block address, then I2C read 4 bytes
-- Write: I2C write 2-byte block address + 4 bytes data
-- Bulk read: iterate blocks into caller-provided buffer
+**NTAG5Link config** (one-time setup via PCSC reader):
 
-**SRAM access** (256 bytes, 64 blocks of 4 bytes):
-- Same read/write pattern as EEPROM, different address range (0xF8-0xFF)
-- Used as NFC ↔ I2C mailbox for phone communication
-
-**Session registers** (7 bytes at 0x00-0x06):
-- Single-byte address, read/write 1 byte
-- Include EH status, field detection, arbiter mode control
-
-### NTAG5Link Configuration
-
-Must configure NTAG5Link for our use case (via NFC-side config write before first use, or via I2C config registers):
-
-| Setting | Value | Constant (from ntag5link.py) |
-|---------|-------|------------------------------|
+| Setting | Value | Constant |
+|---------|-------|----------|
 | Use case | I2C slave | `CONFIG_1_USE_CASE_CONF_I2C_SLAVE = 0 << 4` |
 | Arbiter mode | SRAM pass-through | `CONFIG_1_ARBITER_MODE_SRAM_PASSTHROUGH = 2 << 2` |
 | SRAM enable | On | `CONFIG_1_SRAM_ENABLE = 1 << 1` |
 | EH mode | Low field strength | `CONFIG_0_EH_MODE_LOW_FIELD_STRENGTH = 2 << 2` |
-| EH voltage | 3.0V | EH_CONFIG register bits 2:1 = 10 |
-| EH current | 9.0mA+ | EH_CONFIG register bits 6:4 |
+| EH voltage | 3.0V | EH_CONFIG bits 2:1 = 10 |
 
----
+**Done when**: MCU reads EEPROM data written by PCSC reader and displays it as LED colors.
 
-## Phase 3: Pattern Storage Format
+### M5: Boot-from-EEPROM
 
-**Goal**: Define a compact binary format for LED patterns stored in NTAG5Link EEPROM.
+**Goal**: Design pattern binary format (informed by M2-M3 experience) and boot from stored patterns.
 
-### Format Specification
+By now we know exactly what engine programs look like in practice, so the format design is grounded in real usage.
 
+**Tasks**:
+1. Design binary pattern format — header + engine programs + LED mapping (see format spec below)
+2. Write `src/pattern/mod.rs` — deserializer (parse EEPROM bytes → engine programs)
+3. Write `src/pattern/engine.rs` — convert parsed pattern → LP5562 engine program load sequence
+4. Update `main.rs` boot sequence: read EEPROM → parse pattern → program LP5562 → idle
+5. Write a Python script (or extend ntag5sensor) to serialize patterns to EEPROM via PCSC
+6. Test: write pattern via PCSC, power-cycle, verify LP5562 runs the pattern
+
+**Pattern format** (preliminary — will be refined based on M2-M3 learnings):
 ```
-Pattern Header (16 bytes):
-  [0-3]   Magic: 0x58 0x42 0x4C 0x4B ("XBLK")
+Header (16 bytes):
+  [0-3]   Magic: "XBLK" (0x58 0x42 0x4C 0x4B)
   [4]     Version: 0x01
-  [5]     Flags:
-            bit 0: has engine 1 program
-            bit 1: has engine 2 program
-            bit 2: has engine 3 program
-            bit 3: has direct color values
-            bit 4-7: reserved
-  [6]     Number of pattern entries (1-255)
-  [7]     Current setting for all channels (0-255 → 0-25.5mA)
-  [8-9]   Reserved
-  [10-13] Direct color values (R, G, B, W) — used when flag bit 3 set
-  [14-15] CRC-16 of bytes 0-13 + all entry data
+  [5]     Flags (which engines used, direct color mode)
+  [6]     Number of pattern entries
+  [7]     LED current setting (0-255 → 0-25.5mA)
+  [8-13]  Reserved / direct RGBW color values
+  [14-15] CRC-16
 
-Pattern Entry (2 + N*2 bytes each):
-  [0]     Entry type:
-            0x01 = Engine program (LP5562 engine commands)
-            0x02 = Direct PWM keyframes
-  [1]     Length in 16-bit words (1-16 for engine programs)
-  [2..N]  Command words (big-endian, LP5562 engine format)
+Entry (2 + N*2 bytes):
+  [0]     Type (0x01 = engine program)
+  [1]     Length in 16-bit words (1-16)
+  [2..]   Engine command words (big-endian)
 
-Engine Assignment Block (4 bytes, after all entries):
-  [0]     Engine 1 → entry index (0xFF = unused)
-  [1]     Engine 2 → entry index (0xFF = unused)
-  [2]     Engine 3 → entry index (0xFF = unused)
-  [3]     LED mapping byte (LP5562 LED_MAP register 0x70 format)
+Assignment (4 bytes, after entries):
+  [0-2]   Engine 1/2/3 → entry index (0xFF = unused)
+  [3]     LED_MAP register value
 ```
 
-**Size**: A typical 3-engine pattern with 16 commands each: 16 + 3×(2 + 32) + 4 = **122 bytes**. Even complex multi-pattern configs fit comfortably in the 2048-byte EEPROM.
+Typical 3-engine pattern: 16 + 3×34 + 4 = **122 bytes** (fits easily in 2048B EEPROM).
 
-### Built-in Default Patterns
+**Done when**: MCU boots, reads pattern from EEPROM, LP5562 runs it autonomously.
 
-Hardcoded in firmware as fallbacks:
-- **Solid color**: Direct PWM, no engines needed
-- **Breathing**: 1 engine — ramp up, ramp down, branch to start
-- **RGB cycle**: 3 engines — staggered phase with trigger synchronization
-- **Heartbeat**: 1 engine — fast ramp up, slow exponential decay
-- **Rainbow fade**: 3 engines — slow ramp with offset phases
+### M6: SRAM Mailbox
+
+**Goal**: Phone writes a new pattern via NFC, MCU picks it up and reprograms LP5562.
+
+**Tasks**:
+1. Write `src/ntag5/sram.rs` — SRAM block read/write (64 blocks × 4 bytes at 0xF8-0xFF)
+2. Design SRAM mailbox command/response protocol:
+   ```
+   Command (NFC → MCU):  [cmd, seq, len_lo, len_hi, payload...]
+   Response (MCU → NFC): [status, seq, len_lo, len_hi, payload...]
+   Commands: 0x01=write_pattern, 0x02=get_info, 0x03=set_color, 0x04=get_version
+   ```
+3. Configure NTAG5Link FD pin for SRAM write indication
+4. Implement polling or interrupt-based command detection (EIC wake comes in M7)
+5. MCU receives pattern → stores to EEPROM → reprograms LP5562
+6. Test with PCSC reader first, then VivoKey RawNFC app
+
+**Done when**: Pattern update works via NFC without power-cycling the MCU.
 
 ---
 
-## Phase 4: Power Management
+## Group C — Power + Recovery
 
-**Goal**: Minimize MCU power draw so LP5562 gets maximum current budget from energy harvesting.
+**Hardware needed**: + Hall effect sensor + multimeter
 
-### Sleep Architecture
+### M7: Sleep/Wake
 
-1. After boot and LP5562 engine programming, enter SAMD21E **STANDBY** mode (~5µA)
-2. LP5562 runs autonomously using its internal 256Hz oscillator — no MCU involvement
-3. Wake sources via External Interrupt Controller (EIC):
-   - **NTAG5Link FD pin**: NFC field detection or SRAM write indication
-   - **Hall sensor GPIO**: Recovery trigger (magnet proximity)
+**Goal**: MCU enters STANDBY after programming LP5562, wakes on NFC activity.
 
-### Power Budget Analysis
+**Tasks**:
+1. Configure SAMD21 EIC for NTAG5Link FD pin (wake source)
+2. After LP5562 engine programming, enter STANDBY (~5µA)
+3. On EIC interrupt (FD pin), wake, process SRAM mailbox, return to sleep
+4. Verify LP5562 keeps running patterns during MCU sleep
+5. Measure current with multimeter: active vs standby vs total system
 
-| Component | Active | Sleep/Idle | Notes |
-|-----------|--------|------------|-------|
-| SAMD21E | 3-5mA @ 48MHz | ~5µA standby | Sleep ASAP after boot |
-| LP5562 | 0.5mA quiescent + LED current | Power-save mode | LEDs dominate budget |
-| LP5562 LEDs (4ch) | 2-5mA × 4 = 8-20mA | 0mA (PS_EN) | Must stay within EH budget |
-| NTAG5Link | ~100µA | ~1µA standby | Minimal contributor |
-| **Total (steady state)** | **9-21mA** | **~5µA** | EH max: ~12.5mA |
+**Power budget reference**:
 
-**Key insight**: The system budget is tight. At 12.5mA EH and ~0.6mA quiescent (LP5562 + NTAG5), that leaves ~12mA for LEDs. At 3mA per channel, 4 channels = 12mA — right at the limit. Consider:
-- Running fewer channels simultaneously
-- Using LP5562 engine PWM duty cycling to reduce average current
-- Pulsed patterns (breathing, heartbeat) inherently use less average current than solid-on
+| Component | Active | Standby |
+|-----------|--------|---------|
+| SAMD21E | 3-5mA | ~5µA |
+| LP5562 quiescent | ~0.5mA | ~0.5mA |
+| LP5562 LEDs (4ch @ 3mA) | ~12mA | ~12mA |
+| NTAG5Link | ~100µA | ~1µA |
+| **Total** | **~17mA** | **~12.5mA** |
 
-### Energy Harvesting Configuration
+Key insight: LED current dominates. MCU sleep saves ~4mA. Total must stay under EH max (~12.5mA), so LED current must be limited.
 
-Set via NTAG5Link config registers (one-time setup via PCSC reader):
-- Voltage: 3.0V (EH_CONFIG bits 2:1 = 10)
-- Current threshold: start at 9.0mA, increase if patterns are dim
-- Mode: Low field strength (CONFIG_0 bits 3:2 = 10) — better for phone NFC
-- FD pin: SRAM write indication mode (for NFC communication wake)
+**Done when**: MCU sleeps after boot, LP5562 runs patterns, MCU wakes on NFC to accept new pattern.
+
+### M8: Recovery Mode
+
+**Goal**: Hall sensor provides safe mode entry for post-implant recovery.
+
+**Tasks**:
+1. Wire hall sensor to EIC-capable GPIO pin
+2. Boot-time check: if hall sensor asserted → recovery mode
+3. Recovery behavior: load hardcoded solid white (low brightness), skip EEPROM, stay awake
+4. Set recovery flag in SRAM so phone app can detect it
+5. Add hall sensor as runtime EIC wake source (e.g., cycle patterns)
+
+**Done when**: Holding magnet near hall sensor at boot triggers recovery mode with default LED pattern.
+
+### M9: Power Characterization
+
+**Goal**: Measure real power consumption and tune EH settings.
+
+**Tasks**:
+1. Measure current draw: MCU active, MCU standby, LP5562 at various current settings
+2. Test NTAG5Link EH output with phone NFC at different current thresholds
+3. Find optimal balance: maximum LED brightness within EH budget
+4. Document actual power budget (replaces estimates in this plan)
+
+**Done when**: We have real numbers and documented EH configuration that works reliably.
 
 ---
 
-## Phase 5: NFC Communication Protocol
+## Group D — Abstraction + Polish
 
-**Goal**: Enable phone-to-MCU communication through NTAG5Link SRAM mailbox.
+**Prerequisite**: Groups A-C working. Now we know the real interface needs.
 
-### SRAM Mailbox Protocol
+### M10: LedController Trait
 
-The NTAG5Link's 256-byte SRAM is accessible from both NFC (phone) and I2C (MCU) sides. We use it as a command/response mailbox.
+**Goal**: Extract trait from proven LP5562 usage patterns.
 
-```
-Command Frame (NFC → MCU, written to SRAM by phone):
-  [0]     Command byte:
-            0x01 = Write pattern (followed by pattern data)
-            0x02 = Read current pattern info
-            0x03 = Set direct color (4 bytes RGBW follow)
-            0x04 = Get firmware version
-            0x05 = Enter bootloader (reserved)
-  [1]     Sequence number (for request/response matching)
-  [2-3]   Payload length (little-endian, max 252)
-  [4-255] Payload data
+After M1-M9, we know exactly what `set_channel`, `load_pattern`, and `stop_pattern` actually need to look like. Design the trait from real experience, not speculation.
 
-Response Frame (MCU → NFC, written to SRAM by MCU):
-  [0]     Status:
-            0x00 = OK
-            0x01 = Error (error code in payload)
-            0x02 = Busy
-            0x03 = Ready for next chunk
-  [1]     Sequence number (echoed from command)
-  [2-3]   Payload length (little-endian)
-  [4-255] Payload data
-```
+**Tasks**:
+1. Define `LedController` trait in `src/led/mod.rs` based on actual usage in `main.rs`
+2. Implement for LP5562 wrapper (including GPIO EN pin)
+3. Refactor `main.rs` to use trait-based API
+4. Verify everything still works
 
-### Chunked Transfer
+### M11: SimplePwm Driver
 
-For patterns larger than 252 bytes (unlikely but supported):
-- Command 0x01 payload starts with chunk header: `[chunk_index: u8, total_chunks: u8, ...]`
-- MCU accumulates chunks in RAM
-- After final chunk, MCU writes complete pattern to EEPROM
-- MCU responds with 0x03 (ready for next chunk) or 0x00 (complete)
+**Goal**: Single-color LED support via GPIO PWM — only if we have hardware to test.
 
-### Communication Flow
-
-1. Phone writes command frame to NTAG5Link SRAM via NFC
-2. NTAG5Link asserts FD pin (SRAM write indication)
-3. SAMD21E wakes from STANDBY via EIC interrupt
-4. MCU reads SRAM via I2C, processes command
-5. MCU pauses LP5562 if needed (set engines to Hold)
-6. MCU performs action (update pattern, read info, etc.)
-7. MCU writes response frame to SRAM via I2C
-8. MCU resumes LP5562 engines if paused
-9. MCU returns to STANDBY
-10. Phone reads response from SRAM via NFC
+Implement `LedController` for direct GPIO PWM. Skip this milestone entirely if we don't have single-color LEDs to validate against.
 
 ---
 
-## Phase 6: Recovery and Safe Mode
+## Group E — Future
 
-**Goal**: Provide a way to recover from bad patterns or firmware issues post-implantation.
+Deferred until Groups A-D are solid.
 
-### Hall Sensor Recovery
+### Custom PCB (SAMD21E)
 
-A hall effect sensor connected to a SAMD21E GPIO pin (EIC-capable) provides recovery triggering by holding a magnet near the implant.
+- Port from `xiao_m0` BSP to `atsamd-hal` with `samd21e` feature
+- Add `cortex-m-rt = "0.7"`, custom `memory.x` linker script
+- Remap SERCOM and pin assignments for 32-pin QFN
+- PCB design: SAMD21E (5×5mm) + LP5562 (3×3mm) + NTAG5Link (1.45×1mm) + hall sensor + antenna
+- Target: disc <15mm diameter or capsule <12×30mm
 
-**Boot-time check**:
-1. On every boot, before reading EEPROM, check hall sensor GPIO state
-2. If asserted (magnet present): enter recovery mode
-3. If not asserted: normal boot, read EEPROM pattern
+### Companion App (React Native)
 
-**Recovery mode behavior**:
-- Load hardcoded default pattern: solid white at 25% brightness (~1.5mA/ch)
-- Do NOT read EEPROM pattern (in case it's corrupted or causes issues)
-- Set recovery flag in NTAG5Link SRAM so phone app can detect recovery state
-- Remain awake (do not enter STANDBY) to allow firmware update operations
-- Optionally: blink onboard LED in recognizable recovery pattern
+- NFC via platform APIs (Android NFC, iOS Core NFC)
+- ISO15693 access to NTAG5Link SRAM mailbox
+- Pattern editor UI + upload
+- Status display (firmware version, current pattern, recovery state)
 
-**Runtime trigger**: Hall sensor also serves as EIC wake source during sleep. Possible uses:
-- Cycle to next stored pattern
-- Enter diagnostic mode
-- Force re-read of EEPROM pattern
+### Firmware Update (NFC OTA)
 
----
-
-## Phase 7: Firmware Update Strategy
-
-### Analysis
-
-| Approach | Pros | Cons | Feasibility |
-|----------|------|------|-------------|
-| **NFC pass-through bootloader** | True OTA, no physical access | Complex, slow (256B SRAM chunks for 256KB flash = thousands of transactions), custom bootloader needed | Possible but hard |
-| **UF2 bootloader (USB)** | Fast, well-established, standard tooling | Requires USB access — impossible once implanted | Dev phase only |
-| **Hybrid (recommended)** | Best of both: UF2 for dev, NFC OTA deferred | Two bootloader systems to maintain | Practical |
-
-### Recommended Approach
-
-1. **Development phase**: Use UF2 bootloader on XIAO M0 for rapid iteration. Flash with `cargo hf2 --release`.
-2. **Pre-implant**: Thoroughly test final firmware via UF2. Ensure pattern system works perfectly since that's the primary update mechanism post-implant.
-3. **Post-implant updates**: The pattern storage in NTAG5Link EEPROM provides the most common update path — new patterns without new firmware. This covers the majority of use cases.
-4. **Future NFC OTA**: Implement minimal NFC pass-through bootloader in a later phase if needed. Would require:
-   - ~8KB reserved flash for bootloader code (BOOTPROT fuse)
-   - Custom chunked transfer protocol over SRAM mailbox
-   - CRC verification before committing new firmware
-   - Fallback to known-good firmware on verification failure
-
----
-
-## Phase 8: Custom PCB (SAMD21E)
-
-### Porting from XIAO M0 to SAMD21E18A
-
-| Change | From (XIAO M0) | To (Custom PCB) |
-|--------|----------------|------------------|
-| BSP crate | `xiao_m0 = "0.13"` | `atsamd-hal = { version = "0.17", features = ["samd21e"] }` |
-| Runtime | Included in BSP | Add `cortex-m-rt = "0.7"` |
-| Linker script | Included in BSP | Custom `memory.x` for SAMD21E18A |
-| Package | SAMD21G18A (48-pin TQFP) | SAMD21E18A (32-pin QFN, 5×5mm) |
-| SERCOM | SERCOM0 (BSP-configured) | Remap to available SERCOM on E variant |
-| Pins | BSP pin names (a0, a4, a5, led0) | Direct PAC pin references |
-
-### PCB Design Targets
-
-| Component | Package | Size |
-|-----------|---------|------|
-| SAMD21E18A | QFN-32 | 5×5mm |
-| LP5562 | QFN-16 | 3×3mm |
-| NTAG5Link (NTP53x2) | XSON-8 | 1.45×1mm |
-| Hall sensor | SOT-23 | 2.9×1.6mm |
-| NFC antenna | PCB trace loop | ~12-15mm diameter |
-
-Target form factor: disc under 15mm diameter or capsule under 12×30mm.
-
----
-
-## Phase 9: Companion App
-
-### React Native App
-
-- NFC communication via platform-native APIs (Android NFC, iOS Core NFC)
-- ISO15693 NTAG5Link access for SRAM mailbox protocol
-- Pattern editor: visual LED color/pattern picker
-- Pattern upload: serialize to XBLK format, send via SRAM mailbox
-- Status display: firmware version, current pattern info, recovery state
-- Testing: use VivoKey RawNFC and DT NFC Identifier as reference
+- Custom bootloader in protected flash (~8KB, BOOTPROT fuse)
+- Chunked firmware transfer via SRAM mailbox (256B per chunk)
+- CRC verification, fallback to known-good firmware
+- Development: use UF2 via USB; NFC OTA only if needed post-implant
 
 ---
 
@@ -337,8 +272,8 @@ Target form factor: disc under 15mm diameter or capsule under 12×30mm.
 | Risk | Severity | Mitigation |
 |------|----------|------------|
 | Power budget too tight for 4ch LED | High | Limit current to 2-3mA/ch, use pulsed patterns, run fewer channels |
-| I2C bus contention (LP5562 + NTAG5) | Medium | Always pause LP5562 before NTAG5 I2C access, resume after |
-| EEPROM write endurance (~100K cycles) | Low | Use SRAM for transient communication, EEPROM only for pattern persistence |
-| Boot time too slow for user experience | Low | Estimated ~15-20ms total — fast enough to appear instant |
-| NFC coupling distance too short | Medium | Optimize antenna, use low field strength EH mode, accept 1-3cm range |
-| Firmware bug post-implant with no OTA | High | Hall sensor recovery, thorough pre-implant testing, pattern-only updates cover most needs |
+| I2C bus contention (LP5562 + NTAG5) | Medium | Pause LP5562 engines before NTAG5 I2C access, resume after |
+| EEPROM write endurance (~100K cycles) | Low | SRAM for transient comms, EEPROM only for pattern persistence |
+| Boot time too slow | Low | Estimated ~15-20ms — appears instant to user |
+| NFC coupling distance too short | Medium | Optimize antenna, low field strength EH mode, accept 1-3cm |
+| Firmware bug post-implant | High | Hall sensor recovery, thorough pre-implant testing, pattern-only updates |