Embedded Systems · 2025
ESP32-S3 wearable developing
Custom PCB & control system
The problem
Wearable electronics require extreme miniaturization without sacrificing functionality. Off-the-shelf dev boards are too large, too power-hungry, and lack the I/O configuration needed for custom wearable applications.
The solution
Designed a custom ESP32-S3 wearable platform from scratch — schematic, PCB layout, power management, and firmware. The board integrates USB-C charging, multichannel I/O, and wireless connectivity in a form factor small enough to embed in wearable accessories.
System architecture
How it's wired
ESP32-S3 wearable: power path, RF, I/O, and OTA update flow with A/B partition rollback. Animated arrows show power and data direction.
Engineering rationale
Technical decisions
Why this stack, what the trade-offs were.
Why ESP32-S3 instead of nRF52 or RP2040?
Needed Wi-Fi + BLE on a single chip with native USB for serial/programming without an external UART. nRF52 needed an extra Wi-Fi co-processor. RP2040 had no built-in radio. ESP32-S3 integrated everything at the cost of higher idle current — addressed via aggressive sleep modes.
Why A/B partition OTA instead of a simpler in-place update?
In-place updates are one bad flash from a bricked device. A/B partitions let firmware verify itself after boot — if the new image fails to come up cleanly, the bootloader reverts to the last-known-good partition automatically. Critical for a wearable you can't easily reflash in the field.
How is firmware pinned to hardware revisions?
Each board carries a hardware revision string burned into OTP fuses at production. The OTA server cross-references this against the firmware manifest before serving an update — a firmware built for rev B can't deploy to a rev A board even if the chip is identical. Prevents one bug from bricking an entire fleet.
How is the 5mm form factor maintained with USB-C, radio, and a battery?
Component selection: 0402 passives, integrated antenna (no external module), low-profile USB-C receptacle, flex-circuit interconnect so the battery sits adjacent rather than stacked. PCB is 4-layer with controlled impedance on the RF traces.
Failure modes
Edge case handling
What breaks at the edges, and how the system responds.
- OTA download interrupted mid-flash → A/B scheme keeps last-known-good partition intact; failed update marked, retried next cycle
- New firmware boots but watchdog never gets fed → bootloader auto-reverts to previous partition after N failed boots
- Battery over-discharge → protection IC cuts the load before cell damage; device wakes only on USB reconnect
- RF interference from nearby 2.4 GHz devices → Wi-Fi scan picks cleanest channel at boot; BLE uses adaptive frequency hopping
- USB-C plug inserted backward → CC pin handling ensures correct orientation; no damage from misorientation
Current scope
Limitations
What this system is not today — to be precise about scope.
- Prototype-stage hardware — not yet through full environmental qualification (drop, IP rating, ESD)
- OTA server is currently a static signed-file host — no rollout phasing, no canary cohort
- Power profile measured on bench, not yet validated across full temperature range
Scaling
What breaks first at 10x
Designed for batch manufacturing: test points on every rail, dedicated programming header, panelization-friendly outline, DFM-checked stencil apertures. Firmware build pipeline produces signed binaries that the OTA server pins to a hardware revision string — a firmware bug can't be deployed to the wrong board variant.
Roadmap
What I'd build next
Implementation notes
Build details
- ESP32-S3 selected for its dual-core processor, native USB, and BLE 5.0 + Wi-Fi connectivity
- Custom PCB designed with impedance-controlled traces for RF performance
- USB-C power path with charge management IC, LDO regulation, and battery protection circuit
- Multichannel GPIO breakout for sensors, actuators, and expansion — designed for modularity
- OTA firmware update system enables field updates without physical access to the device
- Production-ready design with test points, programming headers, and DFM considerations
Tech stack
Want to dig deeper?
Happy to walk through code, decisions, or design files.
Get in touch →