Bootladder Engineering

I did some work for a startup in California that created a toy and mobile app for toddlers and grandparents to play with each other remotely during the pandemic. A lot of grandparents and grandchildren were unable to spend time together. It's kind of like zoom with games and a physical toy. It.

The toy is similar to a Nintendo Wi controller. It is based on a ESP 32 platform and has a IMU RGB LEDs and a speaker and a push button. The ESP 32 communicates via Bluetooth low energy to an iPad app where the game controller interacts with the elements in the app.

The project was in the late stages, close to production. When I joined it. There were some features and bugs to take care of, but I was focusing on factory testing and preparing for production. At the contract manufacturer, I created Script to prepare Binaries for release, scripts to do the flashing and Script to do the testing. There were some challenges due to the product being battery powered, very small size, and that the enclosure was ultrasonic quickly welded shut, preventing access after.

Provisioning factory testing factory reset over the air updates, ping pong, bootloading and and setting Wi Fi credentials are all related in a complicated way. Communication happens over MQTT as well as Bluetooth. When the device is shipped to the customer, it is not connected to WiFi. The WiFi credentials are set during the first use, but in the factory. WiFi needs to be connected to do tests and also perform a Ota update. Because the ESP 32 software would be continuing development after product launch, ota both at the factory and in the field was necessary for reliability and risk mitigation. There needed to be a factory reset app which has the minimum capability. Fetch and perform an Ota update.

Similarly, the iPad app was still in development and would continue to develop after launch. Although there was a special test app prepared, this was not comprehensive and automatic enough to be useful at the scale and requirement of factory production. Also, iPads are expensive, so I used Python libraries like Bleak to automate interactions over Ble to the ESP 32. Additionally, I implemented test best functionality on the ESP 32.

One annoying gotcha that we faced was related to the iPad behavior of Caching Ble characteristics associated by Mac address it there was a problem when switching between factory test mode and application mode. The two app modes expose a different set of characteristics and moreover, the behavior of those characteristics was not stable. This caused the problem of the iPad not recognizing that the ESP 32 had changed its characteristics. This behavior on the iPad is at the platform level not easily controllable by the application. So the workaround was to change the Mac address of the Ble interface to increment one of the digits once production was streamlined. This issue is less is important. But when all of this factory business was created, this was certainly an annoyance that had to be resolved.

Regarding the ESP 32, one big takeaway for me was that I grossly underestimated the power of the ESP 32 platform and the libraries and layers exposed by Espresso. I had previously thought it was not to be taken seriously similar to attitudes about Arduino. But seeing a well designed product created by a high caliber Silicon Valley team using ESP 32 was humbling. For example, Ble SPI file system, http MQTT ota free RTOs, event based messaging system, bootloader all worked near flawlessly. There is a lot of stuff going on in this list. These are serious stacks and to be able to to develop applications on top of all of that so easily is extremely impressive to me.