Firmware development has always been a challenging endeavor, but recent industry trends have made it much more difficult to get firmware out the door on time. I want to explore a few of these trends and how Stratify Labs can help.
Defining Firmware Firmware, per se, does not have a nice clear definition. It is something between hardware and software. For the purposes of this post, firmware is the code that runs on microcontrollers.
- Hardware is becoming more capable and more complex
- Software requirements are expanding due to IoT requirements
Historically, firmware has been developed as a monolithic program that runs in a single address space. This was great for microcontrollers that featured tens of kilobytes of storage and were designed for simple applications (like an old-school alarm clock). Now that microcontroller memory measure in the 100’s of kilobytes or even megabytes and powers “smart” devices that are self-updating and internet connected, the traditional approach is not scaling to this increasing complexity.
Why is firmware so hard in the first place?
Programming a microcontroller (firmware) is much more difficult than programming a computer (software) because there are more things that can go wrong. You can have:
- Hardware Design Errors
- Manufacturing Errors
- Firmware Errors
That ends up being a lot of variables to manage. The more engineers can isolate variables and solve one issue at a time, the faster they will get things working.
Hardware Design Errors
The best firmware engineers to deal with these are the ones that have a solid harware background and can understand the schematic and its implications on the firmware. If possible, your firmware engineers should be included in the hardware design process and given the chance to review the proposed design.
Another good way to mitigate these errors is to develop the firmware on known good hardware (as in off-the-shelf development boards) then port the firmware over to experimental hardware. So you have:
- Experimental firmware on known-working hardware (isolate firmware issues)
- Known-working firmware on experimental hardware (isolate hardware issues)
Even if the design is correct, manufacturing prototypes is prone to error. The manufacturer can misunderstand the documents. The distributor can put the wrong parts in the bag. The PCB fabrication process itself can be erroneous.
It is usually left to the firmware engineers to come across these errors and figure out exactly what went wrong. Again, having firmware engineers that understand hardware is critical.
Also, building more than one board in a batch of prototypes can be helpful. If only one board is having problems, that usually points to a PCB assembly/fabrication error. If all the boards have an identical problem, that usually means a design error or a manufacturer misunderstood the design.
When programming a microcontroller, the chip doesn’t do anything at all until it is programmed. Sometimes it is a challenge just to get the board to accept firmware (due to the above error types). Once the firmware is loaded, how the firmware interacts with the hardware can cause the firmware to stall or crash or behave in unexpected (and baffling) ways.
The best approach is a layered, methodical approach. Firmware engineers start by getting low-level drivers working. Many times these drivers are provided by the microcontroller manufacturer (many times these provided drivers have bugs). Each driver should be unit-tested and working robustly before developing the next layer of firmware.
After the drivers are done, middleware and helper libraries are integrated. If these are not known to be stable and reliable, unit testing should be done on these as well (preferably on known-working hardware).
Lastly, the application is developed. If everything below the application is well tested, the development goes much more smoothly because experimental code is limited to the application layer.
Even with this approach, firmware engineers need to constantly be thinking about how resources are being utilized in order to avoid