Menu
Home Videos BlogTech ProjectsAiHardwareSoftware Shop Digital Designs Physical Art Layered Maps Chinese Paper Cuttings About Contact Cart (0)

Conclusion

Hardware

The core question this project set out to answer — can the W1700K’s onboard EFR32MG21 be unlocked and reused as an open radio, independent of its stock ISP firmware — has been answered yes, and demonstrated three separate ways. Everything that follows applies to one radio, reflashed between three jobs, evaluated one protocol at a time by deliberate scope, not because three at once is known to be impossible: the MG21 has 64 KB of RAM, which likely rules out a combined BLE+Zigbee+Thread image, but a two-protocol multiprotocol build (Silicon Labs’ CPC architecture exists for exactly this) was never attempted here and isn’t ruled out by anything found in this project. As built, switching between BLE, Zigbee, and Thread means stopping the current host service, reflashing the application region over the now fully reverse-engineered UART DFU path, and starting the next one.

Current state by radio personality

Reverse engineering / flashing pipeline. Fully verified and the foundation for everything else: the J10 Mini Simplicity connector is mapped and continuity-confirmed on all ten pins; the silicon’s security state (Debug Lock disabled, Device Erase enabled, Secure Boot disabled) is measured, not assumed; the flash map, bootloader table, and NVM3 region are recovered from structural signatures; the AN7581-to-MG21 UART transport (/dev/ttyS1, 115200 8N1, GPIO536/537) is proven live; and the BGAPI UART DFU wire protocol is reverse-engineered from local SDK source and independently WSTK-verified across two separate successful uploads. mg21-flash-upload.sh/-v3 is a working, if still validation-grade, flashing tool — a production-quality mg21-flash utility (a small poll()/select()-based C program, ideally with LuCI integration) has not yet been built.

BLE. Complete and verified end-to-end. A custom BLE NCP runs bidirectionally over BGAPI, flashes cleanly via both SWD and UART DFU, and drives a working generic H5075 reader deployed live on the router.

Zigbee. Complete and verified against a real device. A custom Zigbee NCP forms a coordinator network, pairs and re-pairs an IKEA PARASOLL door sensor, correctly delivers IAS Zone open/close notifications after being pointed at the right (coordinator-side, client) cluster, and survives a controlled restart with recovered listeners. Zigbee2MQTT and Home Assistant Discovery both work against an isolated test container, deliberately kept separate from the user’s production Zigbee2MQTT/USB-coordinator setup.

Thread. The most advanced integration, and the least finished. It works but not perfectly. Native otbr-agent runs directly on the router against /dev/ttyS1, LuCI and apk both work after a snapshot OpenWrt reflash, a real firewall-zone gap was found and fixed, and an IKEA ALPSTUGA Matter-over-Thread smart plug is commissioned and controllable from Home Assistant. But an intermittent RadioSpinelNoResponse crash remains only partially resolved: a genuine stack-buffer-overflow bug in otPlatUartSend() was found and fixed (measurably improving, not eliminating, the crash), the physical UART link and the RCP’s CPU were both directly exonerated via live SWD debugging, and the leading hypothesis — a side effect of the project’s own pre-existing HFXO_E301 errata workaround forcing every post-boot HFXO relock through a slower recalibration path — was never directly confirmed, because the live register capture needed to prove it was cut short by a debugging-tooling mishap.

Honest next steps

  1. Retry the live HFXO register capture during an actual in-progress Thread stall, more carefully this time: exactly one GDB/J-Link session at a time, a hardware watchpoint instead of continuous polling if the tooling supports it, and a mandatory GPIO536 reset pulse immediately after the session regardless of outcome.
  2. If the HFXO hypothesis is confirmed, investigate whether the errata workaround’s slow-relock cost can be selectively mitigated for relocks after the first one, without reintroducing the original hang.
  3. Build the production-grade mg21-flash utility that the current shell-script prototype was always meant to be superseded by.

To be clear about scope: I don’t plan to keep pushing this forward myself. This was meant as a starting point, not a finished product - proof that the hardware and software are both already capable enough to be worth building on. The reverse engineering is done, the flashing pipeline works, and all three radio personalities have been shown to run. If any of the open items above interest you, the hard part — figuring out how to talk to this chip at all - is already out of the way. Take it further. That is the whole point of the project: a piece of cheap hardware, reused as a genuinely general-purpose IoT radio hub.