Robot vacuum programmes fail in a predictable way. The engineering sample works. The pilot run works. Then, between the first ten thousand units and the first year of service, a storage-related failure rate appears and refuses to go away. It is rarely an obvious design error. It is usually a decision that was correct for a prototype and wrong for a product that would be charged nightly, dropped, run to empty and left on a dock in a humid apartment for three years.

Where storage sits

The application processor runs navigation, mapping, the UI and connectivity, with external DDR3 or DDR3L from 1Gb to 4Gb plus a managed or raw NAND for firmware and data. The sensor front end adds a small but latency-sensitive frame buffer on camera models. Motor control, the wireless module and power management carry their own MCU flash or EEPROM, and are largely settled by module vendors' reference designs.

Three failure modes that only appear at volume

Bad block distribution is not uniform across lots. Raw NAND ships with a specified maximum bad block count, and a handful of engineering units show far fewer. A production lot is a different statistical object. Firmware that assumes a clean device, or a file system without adequate spare area, passes every engineering build and then fails on a predictable fraction of production units. Reserve the specified spare area, test with an artificially aged device, and treat the maximum count as the design case rather than the average.

Power loss happens constantly, always at the worst moment. A vacuum runs to battery cutoff and powers down; users lift it off the dock, unplug mid-clean, pull the battery during servicing. If the map is being written then, consistency decides between a usable map and a corrupted partition that needs a factory reset. This is the most common cause of the "it forgot my map" complaint, and it is entirely an architecture decision: journaling or copy-on-write on raw NAND, a managed device with reliable write and correct cache configuration, or an application-level scheme writing maps to alternating slots with a checksum and a generation counter. The third is often the most robust, because it assumes nothing about the underlying flash.

Vibration, dust and heat act continuously. The board sits within tens of centimetres of brush motors and a fan, in an enclosure that filters but does not seal. Solder joint fatigue on large BGA packages is real over a multi-year life, worsened by thermal cycling between warm running and cool docked states. Underfill or corner bonding is cheap to specify at NPI and expensive to retrofit after field returns.

Temperature deserves its own line. The board runs well above ambient and the memory device is often closest to its limit. DDR3 timing margins narrow with temperature, so a design validated at room temperature may behave marginally after forty minutes of running. Validate with a continuous-load soak at the enclosure's internal temperature, not a short functional test.

The arithmetic of dual-bank OTA

Almost every vacuum ships with OTA and two firmware slots so a failed update can fall back, which doubles the firmware requirement. That is where capacity planning usually goes wrong.

A mid-range application image, including navigation, connectivity and voice resources, runs 8 MB to 32 MB. Two slots means 16 MB to 64 MB before any data storage. Add a bootloader, configuration and calibration regions, a map store, a log ring buffer and voice files, and the total can exceed 100 MB on a product the team scoped at 32 MB.

Three options. Two full slots is simplest and fixes the storage decision for the platform's life. A compressed delta update cuts download size but not necessarily storage, since the device still needs a complete image to boot; in-place reconstruction saves capacity but adds complexity and brick risk if power fails mid-way. A single slot with a recovery loader halves the requirement at the cost of longer recovery and a worse experience when an update fails. For most vacuums the first is correct: the price gap between 1Gb and 2Gb NAND is small against a field recovery, and the second slot holds the old map database during a migration.

Map persistence is an endurance problem

Mapping data is the most frequently written data on the device and the least carefully budgeted. A full cleaning cycle may update the map hundreds or thousands of times. Rewriting the whole structure each time can push daily writes into tens of megabytes, which over three years consumes a meaningful share of a small NAND device's endurance.

The fix separates a compact snapshot from an append-only log. The snapshot is written rarely, on dock or when the log crosses a threshold; the log is appended in small records and replayed at boot. Appending to an erase block does not require rewriting it until the block is full, so write amplification drops sharply.

Two details decide whether the scheme lasts. The log must survive power loss: a partially written record must be detectable and discardable, which means a length field and a checksum written after the payload. The snapshot write must be atomic: write to a second slot, then update a pointer, with that update erase-block aligned or protected by a redundant copy.

On raw NAND the file system's journaling covers part of this, but relying on it makes recovery depend on internals that are hard to test exhaustively. An application-level scheme is more code and less magic, usually the right trade at volume.

Interface choices that matter more than they look

Brush motors are PWM-driven at frequencies that couple into adjacent traces, the fan adds its own contribution, and the storage interface often sits close to the drivers because of space constraints.

SPI and quad-SPI have fewer lines to filter but no differential signalling and no physical-layer error detection. Long traces running parallel to motor drive pick up noise, and the symptom is intermittent read errors at one particular duty cycle. Route away from the drivers, keep traces short, add series termination, and prefer a device with on-die ECC and a robust status register. eMMC tolerates common-mode noise better but demands tighter impedance control: eight data lines plus command and clock, all matched, over a solid reference plane. Manageable on four layers; a source of intermittent problems on two.

A pre-production checklist

1. Bad block handling tested at the maximum specified bad block count, not a clean sample.

1. Power loss tested at every point in the write path, including map snapshot and firmware update.

1. Continuous-load thermal soak at the internal enclosure temperature, with timing margins measured there.

1. Vibration and drop testing, then inspection of the memory package for solder joint integrity.

1. EMC testing with brush and fan motors at multiple duty cycles, watching for storage read errors.

1. Second-source qualification, including a layout that accepts both packages.

None of this is unusual. These are simply the checks most often skipped under schedule pressure, and the ones that determine the field failure rate two years later.

We supply memory and interface devices into appliance and robotics designs and work with teams on storage architecture during NPI, including endurance budgeting, power-loss behaviour and second-source qualification. If a platform is moving from pilot to volume, that is the right moment to review these decisions.