Firmware development and bring-up
Illuminious is a U.S. NPI engineering company, and our engineers write firmware for your board and prove it on real units, from the first power-on to the release build the factory loads on every unit. Engineered in San Francisco. Prototype builds, DFM and mass production in our own factory in Shenzhen.
What does firmware development cover?
It covers the code that runs on your board: bring-up, drivers, power management, the radio stack, the bootloader and the update path. We test it on a dev kit, then on the demo build and the validation units. The release candidate is frozen at PVT and runs on the golden sample.
What we write
We work across three platform classes: bare-metal 8-bit and 16-bit microcontrollers, 32-bit microcontrollers with an RTOS, and application processors running embedded Linux. Motor control and embedded Linux are two of the specialist gaps we fill. FPGA designs sit with the electronics work, and the firmware that talks to them sits here.
Firmware written on a dev kit meets new trouble on the real board: a different pin map, a noisy rail, a radio detuned by the housing. That is why our firmware engineers review the schematic before layout starts and work beside the product design team, not after it.
- Board bring-up. First power-on, clocks, memory, debug access, and a check of every rail and interface on the schematic.
- Drivers. Sensors, displays, motor drives, storage and the buses between them, such as UART, I2C, CAN and LIN.
- Power management. Sleep states, wake sources and the battery budget the product needs.
- Connectivity. Bluetooth, Wi-Fi and Ethernet stacks, and LoRa or LTE-M where the product needs them.
- Bootloader and update path. A way to load firmware at the factory and to update units in the field.
- Production test firmware. The code that the test fixture runs to check each unit on the line.
How firmware moves from bring-up to the factory
Bring-up comes first. The first boards from the demo build power on, we check each interface, and you receive a bring-up record that lists what works and what needs a board fix. Features then arrive in tagged builds, each tested on real units, and the demo you show investors or film for Kickstarter runs on one of them.
At EVT, the firmware exercises every interface, so a hardware fault shows up before DVT. At DVT, it is close to feature-complete and includes the radio test modes the certification path needs. At PVT, the release candidate is frozen. It runs with production test firmware on production fixtures, and the golden sample you sign carries it. A later firmware change is a change to the signed product, so it goes through the same approval.
In production, the factory loads the release build on every unit and runs the production test firmware. Test results are kept per unit, by serial number, so a field return can be traced to its test record.
Which microcontroller or module should my product use?
The one that meets the power budget, the radio, the memory and the part supply with room to spare. We choose it with the electronics design, not after it. For a first product, a certified radio module can save a certification step. For embedded Linux, the choice also sets the boot time and the update method.
A certified module also moves the RF layout risk to its maker, which matters when the team has no RF specialist. Part supply matters as much as performance. A chip that is short in the market can stop a production run for months, so we check availability and alternates before the schematic is drawn. See the guide to AI hardware startup BOM strategy and component availability.
How do firmware updates reach units in the field?
Through a bootloader and an update path that we design with the first release, not after it. Units update over the radio they already carry, such as Bluetooth, Wi-Fi or LTE-M, or over a cable. We design the path to verify each image and fall back to the last good one.
An update path added after launch has to work around hardware that was not designed for it: too little flash for two images, no way to recover a failed update, no key storage. Planned at the schematic stage, it needs some extra flash and a key-storage part. Added after launch, it can need a board change. Plan for units that sat on a shelf, too: the first update such a unit receives may skip several releases, so each image must install over any older one.
Who owns the firmware source?
On an engineering project, you do. You receive the firmware source and its build instructions at each stage gate, and design files and IP are assigned to you at hand-off. A fixed-price firmware order in the portal delivers reviewed binaries. If you need the source, say so in your brief: the free engineering review adds it to the scope and the official quote.
Owning the source only helps if another engineer can build it. The handover includes the toolchain version, the build steps and the programming procedure, so someone outside our team can produce the same binary from the same source.
Order firmware online
Firmware development is a fixed-price portal service, with tiers set by platform class and code size, from bare-metal microcontrollers to embedded Linux. The free engineering review takes 2 business days and confirms that your platform fits the tier before you pay. Firmware that ships with a new board, through EVT, DVT and PVT, is scoped with an engineer as part of the project.
Recent work: an idle current above the battery target
A logistics startup needed a LoRa tracker to run for years on one battery. During EVT, our engineers worked on the antenna keep-out and the sleep current. One board respin and firmware fixes to the radio module's sleep states brought the idle draw within the battery target. At PVT, units went through RF and over-the-air update checks. Read the case study.
Facts and questions
Can you take over firmware someone else started?
Yes. We read the code, build it, flash it onto your board and list what works, what is fragile and what is missing. Then we agree a plan at the next stage gate. Code a founder wrote on a dev kit is a common start, and much of it can carry over to the real board.
Do you work on FPGA designs?
Yes. FPGA is one of the specialist gaps we fill, for example in instruments, high-speed data capture and motor control. The FPGA design sits with the electronics team and the firmware that drives it sits with the firmware team, so both are reviewed against the same schematic at each stage gate.
How do you test firmware in production?
The factory loads the release build on every unit. Production test firmware then runs on fixtures built for your product, through in-circuit and functional test. Results are kept per serial number, so each unit has a test record you can look up later.
How do you protect firmware on the device?
Protection starts in the hardware. A key-storage part holds the signing keys, and the bootloader checks each image before it runs. Debug ports are locked on production units. We plan all three at the schematic stage, because adding them after launch can need a board change.
Tell us what you are building
- An engineer runs a free engineering review of your files, and nothing is charged when you submit.
- You see the findings first.
- We publish the official quote with an itemized total, lead time and validity window.
- You accept the official quote, and only then does payment open.