OTA updates in Wi-Fi plush: designing the update path before you need it

Once a plush has Wi-Fi, firmware updates stop being optional. New phrases, new songs, bug fixes — the product is expected to improve after purchase. But updating a toy a child sleeps with is its own engineering discipline.

Two slots, always

The baseline is a backup-slot updater: the new firmware writes to a spare partition while the running system keeps playing. Only after a verified complete image does the toy swap slots at next boot. A failed download is a non-event; a failed swap is a bedtime catastrophe we designed away in advance.

Power guards are not optional

A toy dies mid-update at 4% battery and the news writes itself. The updater checks state of charge, refuses to start below a threshold, and pauses if voltage sags. Charging-dock-triggered updates — “the toy updates while it naps on its base” — are the pattern that sidesteps most of this class of problem and reads as charm instead of maintenance.

Staged rollout belongs in toys too

A phrase that triggers a bug should not reach every unit overnight. Staged deployment — a small cohort, verify, then the fleet — is standard practice in connected devices and belongs in plush programmes as well. The update server is part of the deliverable, not an afterthought.

What the update carries

Phrase packs and behaviour tweaks are data, not firmware, and ride the same pipeline with much lighter validation. Keeping a clean line between content updates (frequent, low-risk) and firmware updates (infrequent, guarded) makes both cheaper and calmer.