What goes wrong
Firmware updates for smart glasses run through the companion app on the phone. The app downloads an image, sends it to the glasses over Bluetooth Low Energy, and the glasses write it to flash, check it and restart. On two-temple designs, the primary temple may then pass the update to the secondary side. Every step can fail, and the failures look different to the customer: the update stalls at a percentage and never finishes; it finishes but the glasses will not power on; one temple updates and the other does not, so the two sides stop pairing with each other; or the update installs and introduces a new problem - shorter battery life, a connection bug, controls that behave differently.
The last case is a release problem rather than an update failure, but customers report it the same way. A buyer needs to manage both: the mechanism that moves firmware onto the glasses, and the process that decides which firmware gets released.
Root causes
| Layer | Typical root cause | Symptom |
|---|---|---|
| Update design | Single flash bank, so an interrupted write leaves no working image; no automatic rollback | Glasses will not start after an interrupted update |
| Update design | No battery threshold before starting; no resume after a dropped link | Update fails at random points, more often on low charge |
| Two-temple sync | Secondary temple update not verified; version mismatch tolerated | One side silent or out of sync |
| App | App version not matched to firmware; background restrictions on the phone operating system stop the transfer | Stalls when the phone screen locks |
| Release control | Build not tested on the full phone list; regression in power or connection code | New bugs after a successful update |
| Use | Glasses walked out of range, put in the case mid-update, phone switched off | Interrupted update |
Design causes are the most important because they decide whether an interrupted update is an inconvenience or a return. Glasses with two flash banks - often called A/B or dual-bank firmware - write the new image to the inactive bank and switch only when it has been verified. If anything goes wrong, they boot the old image. Single-bank designs need a protected recovery mode to achieve the same safety.
The phone side deserves the same attention. Phone operating systems increasingly restrict what apps may do in the background to save power, and a firmware transfer that takes several minutes is exactly the kind of task that gets paused when the screen locks. The app should keep the transfer in the foreground, show clear progress and tell the user not to leave the screen. Those details are app design, but they decide much of the field failure rate.
Recovery routine for support teams
- Charge fully first. Put the glasses on the charger and keep them there during the retry if the design allows charging and updating together.
- Keep the phone close and awake. Keep the phone within a short distance, screen on, app in the foreground, until the update completes.
- Update the app. Make sure the companion app is the current version before retrying the firmware.
- Restart both devices. Restart the phone and power-cycle the glasses per the manual.
- Use recovery mode if documented. Many designs have a button or charging sequence that forces the bootloader to accept a new image.
- Check both temples. After the update, confirm the version shown in the app and test audio on both sides.
- Escalate with data. If the unit still fails, record serial number, old and target firmware versions, app version, phone operating system version and where the update stopped.
When several failures share the same target version or the same phone operating system version, pause the rollout. A staged rollout - a small share of users first, then the rest - is one of the simplest protections a brand can ask for.
Spec lines for the update mechanism
- Fail-safe update. Require dual-bank firmware or a protected recovery mode, so an interrupted update cannot leave the glasses unusable.
- Pre-checks. Battery threshold before starting, and resume or restart after a dropped link.
- Image integrity and signing. Updates should be integrity-checked and signed. Under the CE RED, cybersecurity requirements under Delegated Regulation (EU) 2022/30 apply to glasses as wearable radio equipment from 1 August 2025, with EN 18031 as the harmonised standard; confirm the scope with your test lab and see RED cybersecurity and EN 18031.
- Two-temple verification. Both sides report the same version before the update is marked complete.
- Rollback policy. Define whether users can roll back, and whether the brand can stop a rollout from the server side.
- App ownership. For white-label apps, state who hosts firmware images, who publishes releases and who holds the signing keys. The options are on firmware and app.
Release control and inspection
A firmware release is a change to the product. Treat it like a material change: written notice, a test record and a sign-off.
- Version lock. The golden sample defines the shipping firmware. Mass production units must carry that version unless a change has been approved in writing.
- Release test list. Each candidate build is tested for pairing, reconnect, audio, calls, controls, charging and runtime on the agreed phone list before release.
- Update path test. The update itself is tested from each version in the field, including interrupted updates at different stages.
- Release notes. Each release comes with notes the brand's support team can use.
During pre-shipment inspection, typical checks, confirmed per order, are a firmware version read-out on every sampled unit, a full update cycle on a few units using the production app, and a functional check afterwards. The lot routine is on testing and inspection.
Who owns the problem
Update failures sit between the plant's firmware team, the app developer and the brand's support team, and nobody owns them unless the contract says so. The spec should name who builds, tests, signs and publishes each release, and how quickly a faulty release can be stopped. For catalog models, the update mechanism is what the platform already provides; adding dual-bank firmware, a white-label app or brand-controlled release servers is usually a logo or custom program, with typical MOQ and lead time on MOQ and lead time. The quote form asks whether you need your own app, which helps the desk shortlist platforms that already support it.