This was a project I did for a client, a small startup that had created a wearable device. They had a product in the field which communicated via cellular and the product worked. But there were issues with cellular, eg. latency and coverage across all of their customer sites, so they decided to respin the hardware to incorporate Bluetooth. This choice of hardware was centered around the switch from the Microchip MSP430 to the STM32WB, which is a microcontroller with an integrated BLE radio. It is quite a powerful system on chip. It not only has the radio, but also a second processor called a coprocessor which can handle the lower layers of the BLE stack. My task was basically to port all of the old software onto the new target and prepare for release to customers. This was a fun and interesting project for me because there are a lot of peripherals on this device. It has a ring of nine RGB LEDs, vibrating motor, GPS, cellular six axis IMU, compass, codec/speaker. All of these peripherals worked together to deliver the end user experience. Although most of the peripheral components and subcircuits were reused, it was not straightforward to do this porting of software, particularly because the coprocessor system introduces a level of asynchrony that is incompatible with the traditional main loop architecture. Also, figuring out how to use the BLE stack was quite a challenge, but once you get it working, it's quite straightforward. All of the peripherals had their little issues such as the behavior of the GNSS module when it is in bad reception.
Bringing a product like this into market has a number of unique challenges, particularly because of how small the device is. It also because of the Bluetooth. It actually a lot of software effort went into preparing this product for production much more than just the development of the firmware. Split the firm where into three projects the application, the factory test and the bootloader. It is hard to do a complete factory test with Bluetooth because there is so much software required to get the Bluetooth stack up and running. The more software you have for the purpose of factory testing, the more risk you have for the factory test not working. And really the purpose of factory test is to test hardware, not software. Issues include provisioning of Mac addresses, it unlocking the stack for testing. There are also challenges similar to IoT devices. In general, when the device is designed to communicate with a mobile app, it is not suitable for testing. Even if you were willing to have a mobile app present during factory testing and bench testing, the mobile app developers need working firmware and vice versa. To combat this, my approach was to define a communication protocol over the ble characteristics that would allow me to test my firmware without the mobile app. By creating a set of Python scripts that could be ran on a laptop host, simulating the behavior of the mobile app. Conversely, the mobile app developers could be given a bare bones simple firmware application that will only return valid values for any requests. Just sensible, hard coded defaults so that the mobile app can test its behavior regarding pairing, connecting and disconnecting and going out of range of the device.
A particularly challenging part of the system is the audio. There is a speaker driven by a class D amplifier driven by a codec which is controlled from the microcontroller. The problem is that there are a lot of different sounds to play and there is limited persistent storage available on the device. So the audio samples had to be encoded and compressed to a smaller format to be stored on the persistent storage. And also the target device needed to have a decoder so that it could play the sounds. The decoding had to happen in real time, so the audio sample, which could be nominally 500 milliseconds, had to be chopped up into buffers of the correct size so that both decoding and playback could happen simultaneously without causing noticeable latency to the user. It was also particularly difficult to port the driver code to the STM32 because there is heavy coupling to the microcontroller. There is I2C control of the codec registers and there is also SAI for audio data. Getting the registers right with left and right channels and time slots can be challenging always.
Another thing I did to prepare for production was to create a release script. This was for preparing a single binary image for release to the contract manufacturer. The binary image consists of three regions the bootloader, the factory test and the application. There is also a section of flags so the factory test can be marked as passed as well as for the bootloader to identify a valid application image. It was important to have this captured in a script because development was going to continue happening very late until production. By controlling this release process, I was always sure that I could make changes and be sure that I was testing what I thought and releasing what I thought.