Why This Decision Is Harder Than It Looks
Firmware engineering is a narrow discipline. The pool of engineers who can bring up a BSP on an unfamiliar SoC, write a reliable flash storage layer, and also reason carefully about real time scheduling constraints on a constrained device is smaller than most hardware founders expect. When you add domain requirements like medical device, industrial, or consumer connected, the overlap narrows further.
The consequence is that many hardware companies end up evaluating firmware partners primarily on availability and price, because the technical criteria are hard to assess quickly. That is understandable, but it tends to produce engagements where the partner can code but cannot navigate the specific problems your hardware will surface. Firmware bugs on shipping silicon are expensive. Bring up delays when a new board revision arrives set timelines back weeks. A partner who has done this before on similar hardware and similar constraints is worth considerably more than one who is technically capable but learning on your project.
The questions that actually matter when evaluating a firmware partner have less to do with headcount or tool certifications and more to do with how they approach the parts of the work that go wrong. Something always goes wrong on a new hardware bring up.
What Goes Wrong on Firmware Engagements
The failures we see most often are not catastrophic. They are slow. A bring up that takes three weeks instead of one because the partner is unfamiliar with the toolchain. A flash storage implementation that works in development but develops wear issues in field units at six months. An OTA update system that handles the happy path cleanly but corrupts device state on an interrupted update. A test suite that covers unit behaviour but misses the timing interactions that only appear under real load.
None of these are caused by incompetence. They are caused by a partner who has not encountered this specific class of problem before and is solving it for the first time on your schedule. The most useful question to ask any firmware partner is not what they have built. It is what broke, and how they found it.
The Areas That Separate Good Partners from Adequate Ones
Board Support Package bring up is the first real test. Initialising peripherals, validating clock configurations, getting the bootloader stable. On a new SoC or custom board revision, this is often where engagements lose weeks. A partner who has brought up hardware on a similar platform will move significantly faster. The difference between a one week and three week bring up is usually one or two finicky errata items that are not obvious until you have seen them before.
Flash storage is one of the most consequential firmware decisions and one of the least visible until it fails. Wear levelling, erase block management, and power loss recovery all need explicit design. NAND flash has failure modes that only manifest after extended field use. For workhorse products where storage reliability is critical, we treat storage architecture as a first class design decision, not an implementation detail.
Connected devices in industrial environments have constraints consumer IoT does not. Intermittent connectivity, long periods without network, voltage fluctuations, electromagnetic interference, and multi year field life without physical access. Connectivity stacks that behave well in a lab can be fragile in the field. Message queuing, reconnection logic, and local buffering need to be designed for actual conditions.
Over the air firmware update appears straightforward until a field update goes wrong and a device in a remote installation is left unrecoverable. The requirements are well established: atomic updates, verified rollback, integrity checking before commit. What varies is whether the partner has built this before or is implementing it for the first time under deadline. First implementations tend to handle the happy path and miss the edge cases.
The Part Most Engagements Underinvest In
Firmware testing is genuinely difficult. The hardware and software are interdependent in ways that make unit testing alone insufficient. Timing behaviour, interrupt latency, peripheral interactions, and power state transitions all need testing in conditions that approximate the real device. Most firmware engagements give testing a fraction of the time it warrants, because it is easy to underestimate until a field issue surfaces.
The partners worth working with have a testing methodology that goes beyond running the firmware on a development board and observing that it works. Hardware in the loop testing, fault injection for power failure and connectivity loss scenarios, and endurance testing for flash wear are the kinds of work that prevent the slow failures described earlier. They are also the work that most budget constrained engagements skip, which is why we are direct about it in scoping conversations. Skipping testing is a cost transferred to field maintenance and hardware revision cycles, not a saving.
The most revealing questions are specific. Ask how they test interrupt driven code. Ask what their process is for validating flash behaviour under power loss. Ask how they handle regression testing when hardware changes between revisions. Ask what monitoring they put in place for field deployed devices. A partner with real depth in this area will answer these questions with specifics. A partner who is adequate but not experienced will describe a reasonable sounding process that turns out to be mostly manual.
How the Working Relationship Affects the Outcome
Firmware development works best when the partner is closely integrated with the hardware team, not operating at arm's length. The feedback loop between hardware behaviour and firmware response is tight. A peripheral that does not behave as the datasheet describes, a power rail that is noisier than expected, a timing assumption baked into the firmware that the board does not satisfy: all of these require fast iteration between the people writing the firmware and the people who designed the board.
Engagements where the firmware partner is handed a specification and asked to deliver against it without ongoing hardware access tend to accumulate problems that only surface during integration. The specification is always incomplete. The hardware always has surprises. The question is whether the partner is close enough to the hardware to find those surprises early or whether they discover them at bring up when the schedule has no room left.
We work as part of the product team rather than as a separate delivery track. On embedded projects that means direct access to hardware, direct communication with the electrical engineers, and involvement in board revision decisions where firmware constraints are relevant. That is not a preference. It is what makes the firmware reliable.
For hardware products in regulated domains like medical devices, industrial equipment, or products that need IEC 62443 or DO-178 compliance, the firmware engineering requirements go beyond what a general embedded partner can cover. Traceability from requirements to test cases, documented development processes, specific coding standards, and the ability to support a verification and validation exercise are all requirements that need to be confirmed before an engagement starts. If your product has any regulatory dimension, that conversation needs to happen in the first meeting with any firmware partner you are evaluating.
Common Questions About Choosing a Firmware Partner
Why is choosing a firmware development partner difficult?
Firmware engineering is a narrow discipline. The pool of engineers who can bring up a BSP on an unfamiliar SoC, write a reliable flash storage layer, and reason carefully about real time scheduling constraints is smaller than most hardware founders expect. When you add domain requirements like medical device or industrial, the overlap narrows further.
What typically goes wrong on firmware engagements?
The failures are usually slow rather than catastrophic. A bring up that takes three weeks instead of one because the partner is unfamiliar with the toolchain. A flash storage implementation that develops wear issues in field units at six months. An OTA update system that corrupts device state on an interrupted update. These are caused by a partner solving problems for the first time on your schedule.
What should I look for in BSP bring up capability?
A partner who has brought up hardware on a similar platform, same silicon family and similar peripheral set, will move significantly faster than one reading the reference manual alongside you. The difference between a one week bring up and a three week bring up is usually one or two finicky errata items that are not obvious until you have seen them before.
Why is flash storage architecture so important?
Flash storage is one of the most consequential firmware decisions on a connected device. Wear levelling, erase block management, and power loss recovery behaviour all need to be explicitly designed for. NAND flash has failure modes that only manifest after extended field use. If the storage layer was not designed with those modes in mind, fixing them in a shipped product is a firmware update that carries its own risk.
What questions should I ask a firmware partner about testing?
Ask how they test interrupt driven code. Ask what their process is for validating flash behaviour under power loss. Ask how they handle regression testing when hardware changes between revisions. Ask what monitoring they put in place for field deployed devices. A partner with real depth will answer with specifics, not a reasonable sounding process that turns out to be mostly manual.
How does SequoiaAT approach firmware development?
SequoiaAT works as part of the product team rather than as a separate delivery track. On embedded projects that means direct access to hardware, direct communication with electrical engineers, and involvement in board revision decisions where firmware constraints are relevant. This is what makes the firmware reliable.