Embedded Firmware Development Process

The demo worked. The motor spun, the data streamed, and the investors nodded. Then someone asked the most expensive question in electronics development: "So the firmware's basically done, right?"

It isn't. A demo looks in at a movie set — everything is perfect from one camera angle with nothing beyond what a carefully positioned camera can see. The embedded firmware development process is how you build the rest: seven stages, each ending at a gate through which you either pass or don't.

Here's the fast version: one question per gate. If your team can't answer one of them with a straight face, you've just found your schedule risk.

Technical Summary

The embedded firmware development process has multiple gates: requirements, architecture, reduction to practice with component and circuit topology selections, bring-up and debug of hardware, and then full integration with embedded/driver/application code. Following that is system verification, test of any update mechanism, and final tweaks for production. Note that thanks to “evaluation” platforms for microprocessors, some of the debug of basic code can be done before actual hardware is available, so some of what’s listed above is – and by rights should be – done concurrently. Also note the use of the term “final tweaks” for production. In reality, particularly for products that will run at high volumes, the people on the assembly line actually making the final product should be involved in engineering discussions early and often.
Producing a working demo is one of the smaller parts of the overall job.
Architecture and pinout mistakes found after layout usually cost a board respin.
Update paths are now a legal topic: EU Cyber Resilience Act reporting obligations apply from 11 September 2026, and its security-update requirements from December 2027.
Firmware is done when someone else can rebuild it from source code using a makefile (or equivalent). If there are chips in the design that require that their memories are loaded with firmware and the chips are not purchased from distribution already programmed, one should be able to load it “in system” on the assembly line, whether the memory is “flash” or “OTP.” If the product requires field reflashing, one can demonstrate that it can be updated in the field and that if a field reflash is somehow interrupted or fails, the device will revert back to a “last known good” or “failsafe” state for recovery. “Bricking” a reflashable device is not allowed.

The embedded firmware development process must answer these 7 questions

1. Can every requirement be stated as a test that can be passed or failed?

"Fast" is not a requirement. "Responds within 20 ms" is. If a requirement can't potentially fail a test, it can't pass one either — and nobody will ever agree on when you're done.

2. Did the firmware team sign off on the schematic before PCB layout was finished?

Circuit topologies, driver definitions and requirements, and operating system choices (or the decision to run code across bare metal) have to be decided before layout. Particularly where drivers are concerned, firmware engineers must review chip and connector pinouts. A peripheral on the wrong pin is at a minimum a firmware limitation for the life of the board. At worst, it can block the entire design from completion. (Not sure you even need an MCU rather than an FPGA or SoC? Start here.)

3. Does every peripheral pass a test on the real board?

The answer to this question should not be "it worked once on Tuesday." The bare minimum is a repeatable test under normal operating conditions, on the current hardware revision, with every hardware bug written down.

4. What happens when something breaks?

Brown-outs, stuck sensors, dropped connections are a fact of life, so design for them. On a 1970s motorcycle refit we built, one noisy aftermarket ignition made by a third party could occasionally reset the controller. A watchdog recovered so quickly that almost no rider noticed, and no critical system on the bike was ever compromised. That's the goal: failures your customer never sees but which are noticeable to the discerning eye of someone who’ll make the effort to fix the problem.

And yes, we did get the nature of the problem diagnosed and we redesigned some of the noise-blocking circuits on the board to be more resilient in the face of a third-party ignition controller that was exceedingly noisy.

5. Can a robot run your tests?

If every release needs an engineer clicking through a checklist, generally every release gets slower than the last. (Features are almost always added. Deleting them occurs only very rarely.) Or a great many things get skipped over to allow someone to go home at 5pm. Robots can run 24/7/365. So it’s best to have complete test coverage and let the machines do the testing even while the engineer isn’t at work.

6. What happens if the power dies mid-update?

If the answer is "it bricks," you don't have an update system. You have a recall plan. You want signed images, automatic rollback (open-source bootloaders like MCUboot do both), and debug ports that are locked (to prevent IP theft) but can be reopened with a magic encryption key (so an emulator/debugger can attach).

For products sold in the EU, the Cyber Resilience Act makes this a legal question, not just good manners.

7. Could a stranger rebuild the source code and create a downloadable binary image?

(And is it under version control such that it doesn’t produce something weird or out-of-date when it’s built?) Could this stranger load the code, and if it goes in flash memory, could he update it under field conditions?

Once you have a clean piece of hardware that can load an identical image built from version-controlled source code, a programming procedure the factory can follow. Serial numbers and keys can be provisioned per unit if appropriate.

If the only person who can build the release is on vacation, so is your product. (This is where turnkey manufacturing support earns its keep.)

Score yourself

Count the confident yeses:

7: ship it.
5–6: you know exactly where the next month goes.
4 or fewer: your demo is still sitting on a movie set somewhere.

Want a second opinion about any (or all) of your answers?

We design the hardware and write the firmware, so these seven questions are our day job. Tell us where you're stuck and we'll tell you honestly what it takes to ship. See our embedded firmware development services →

📞 +1 (512) 246-9012 (or 1-888-FOC-7924) 📧 info@focusembedded.com 🌐 focusembedded.com/contact

‍