Making Factory Bring-Up Possible Without Special Firmware

Factory bring-up is where hardware design meets operational reality. In the lab, engineers can afford patience. They have debug probes, oscilloscopes, serial logs, source code, firmware builds, and the people who designed the board sitting nearby. If something doesn't respond, someone can flash a test image, jumper a pin, force an enable line, attach a debugger, or rebuild firmware with extra logs.

A factory doesn't work that way. A factory line needs repeatability. It needs a board to be powered, identified, programmed, tested, accepted, or rejected in a predictable flow. It can't depend on one engineer's laptop, one temporary firmware build, one undocumented debug command, or one special test binary that only works with a specific board revision. This is why we believe factory bring-up should not depend on special firmware.

At Hoomanely, this principle became important as our systems moved from single prototype boards to modular embedded products with multiple sensor boards, carrier interfaces, power domains, and communication paths. A board may include an MCU, image sensor, thermal sensor, proximity sensor, level shifters, CAN interface, RGB status indication, regulators, reset supervision, and multiple power enables. In such a design, factory testing can't rely on the full application firmware being healthy before the board itself can be validated. The hardware must provide enough structure for the factory to answer a simple question:

• Is this board electrically alive
• Identifiable
• Programmable
• Safe to continue testing? That question must be answerable before product firmware becomes part of the equation

The problem with special factory firmware

Special factory firmware usually begins innocently. During early development, an engineer writes a simple test image to toggle GPIOs, blink LEDs, read sensors, or exercise a bus. It helps during bring-up, gives the team confidence, and becomes useful enough that manufacturing starts using it.

Then the problems begin. A test image gets updated for one board revision but not another. A factory station expects one UART command set, while engineering uses another. A firmware binary assumes a sensor is populated, but a later production variant removes it. A line operator flashes the wrong test firmware. A board passes factory firmware but fails application firmware because the two initialize hardware differently.

The deeper issue isn't that factory firmware is bad, test firmware can be useful. The issue is making factory bring-up dependent on it. If a board can't be identified, powered safely, programmed, or minimally validated without a custom runtime image, the factory process is fragile from the start. A factory bring-up process shouldn't require the product application to already work. It should prove that the hardware is ready for the application.

Bring-up should start from hardware truth

The first stage of factory bring-up should verify hardware-level truths that don't depend on complex firmware behavior:

• Whether the board receives input power correctly
• Whether primary rails come up within expected limits
• Whether reset is released correctly
• Whether programming pins are accessible
• Whether boot configuration is valid
• Whether key identification paths are readable

A strong factory flow begins with things that are difficult to fake:

• Voltage rail presence
• Reset state
• Current consumption window
• Programming interface response
• Board ID or revision detection
• Continuity of critical communication paths
• Safe default states on enable pins

These checks aren't glamorous, but they're powerful. They catch assembly faults, wrong components, soldering issues, shorts, open rails, connector problems, and reset faults before the system reaches higher-level testing. More importantly, they create a foundation that doesn't depend on a custom firmware image being correct.

Programming access is part of the product architecture

Programming access should never be treated as a temporary development convenience, it's part of the product architecture. If a board can't be reliably programmed in the factory, everything after that becomes unstable. The programming interface must be physically accessible, electrically safe, and consistent across revisions. It shouldn't require holding random buttons, shorting pads manually, or depending on timing-sensitive power cycling.

In a modular system, this becomes even more important. A sensor board or SOM may be tested outside the final enclosure, attached to a carrier, or connected through a fixture. The programming path must remain deterministic across these conditions. A good factory-oriented programming design considers stable debug connector or fixture pads, predictable boot-mode selection, reset control from the fixture, power sequencing control where needed, clear ground reference, protection against misalignment, and no dependency on application-level initialization. The board should be programmable even when the previous firmware image is corrupted, incomplete, or absent. That's the difference between a recoverable manufacturing flow and a fragile one.

Identification must not depend on the main application

Every board should be identifiable before full firmware runs. This sounds simple, but many systems accidentally bury identity inside application software, the product boots, the application reads configuration, and then reports the board type or serial number. That's too late for factory bring-up. The factory needs to know what it's testing before it runs complex tests.

Board identity can be established through resistor straps, EEPROM, fixture-readable pads, bootloader-readable metadata, hardware revision pins, barcode mapping, or manufacturing database association. The exact method depends on the product, but the principle remains the same:

• The system should be able to answer what board this is
• Which revision
• What test limits apply
• Which interfaces should exist
• Which sensors are expected

Without that, factories often compensate with manual process rules, which increases risk. A board variant without one optional sensor shouldn't fail a test designed for a different variant, and a sensor SOM shouldn't be programmed with firmware intended for another module. Identity isn't documentation. Identity is a test input.

Power rails should be testable before firmware

Power is the first functional behavior of any board, and if power is wrong, firmware results are meaningless. A factory fixture should verify that key rails come up as expected before flashing or running application tests. This matters especially in boards with multiple rails, MCU core rails, sensor rails, camera rails, IO rails, and switched feature rails.

The factory doesn't always need deep analogue characterization, it needs practical confidence that the rail is present, within range, sequenced correctly enough, and not drawing abnormal current. Before programming the board, a fixture may check that input current doesn't exceed a safe threshold, the primary 3.3V rail is valid, the MCU rail is active, the reset supervisor releases reset, switched sensor rails remain off by default, high-current feature rails aren't accidentally enabled, and power-good or enable states match expectations. This prevents a damaged or misassembled board from being pushed deeper into the factory line, where failures become harder to isolate. A board that explains its power state makes factory bring-up faster and safer.

Default states matter more than people expect

Factory bring-up often happens before firmware has configured anything, so the board's default hardware states matter. Enable lines, reset pins, boot-mode pins, transceiver standby pins, level-shifter enables, LED drivers, sensor shutdown pins, and power switches must all have safe default behavior.

If a high-current load turns on before firmware runs, the board may fail current checks or damage itself. If a communication transceiver starts in the wrong mode, it may disturb a shared bus. If a sensor reset line floats, the device may enter an undefined state. If boot pins aren't deterministic, programming may fail randomly. The safest factory-friendly boards behave predictably even when the MCU is blank, which means careful use of pull-ups, pull-downs, reset supervisors, default-off feature enables, and deterministic boot strapping. A blank MCU shouldn't be a dangerous condition, it should be an expected factory state.

Fixtures should control the board without owning the design

Factory fixtures are extremely useful, but they shouldn't compensate for poor board architecture. A fixture can provide power, reset control, programming access, measurement points, and communication interfaces. It can automate tests and log results. But the fixture shouldn't need to perform strange workarounds to make the board testable.

If the fixture must manually force five internal signals, bypass a regulator, hold a floating enable line, or emulate undocumented timing to prevent the board from failing, the product design isn't factory-ready. The best fixture relationship is clean:

• The board exposes stable test access
• The fixture applies controlled stimulus
• The board responds predictably
• The test system records pass or fail

The fixture should accelerate bring-up, not rescue it. At Hoomanely, this thinking aligns closely with modular hardware, when boards expose programming, power, reset, communication, and identity in a structured way, the same fixture philosophy can scale across multiple SOMs and carrier combinations.

Minimal test paths beat full application tests

A common factory mistake is trying to validate everything through the full product application. That approach feels realistic because it tests the device "as used." But it also makes failures harder to isolate, if the application fails to report a sensor value, the issue could be the sensor, bus, rail, firmware driver, configuration, timing, calibration data, or communication stack.

A factory bring-up flow should separate basic electrical validation from higher-level product validation. The first stage should answer whether the board is electrically sane, later stages can test application behavior. A practical structure:

• The fixture detects board and revision
• Applies controlled power and checks current
• Verifies reset and boot-mode behavior
• Programs known firmware through standard programming access
• Firmware performs self-test using normal production pathways
• The fixture records calibration
• Identity
• Pass/fail results
• Then final product firmware or configuration is applied

The important point isn't the exact sequence, it's that early stages don't depend on the full application already working.

Special firmware creates version drift

One hidden cost of special factory firmware is version drift. The product firmware evolves, hardware revisions evolve, test requirements evolve, but the factory image often lags behind. Eventually the test image no longer reflects the product's real initialization sequence, power timing, sensor configuration, or bus behavior, creating a dangerous situation where boards pass factory tests but fail in real operation.

The better approach keeps factory-specific behavior small and infrastructure-like, using bootloader capabilities, standard debug access, fixture-controlled measurements, and production firmware self-tests wherever possible. If factory test code is required, it should be versioned, traceable, and aligned with production initialization paths. The factory shouldn't become a parallel firmware universe.

Design the board to be testable when partially populated

Production doesn't always happen in one clean step. Boards may be tested before all modules are attached, some variants may be partially populated, and some SOMs may be tested independently before being connected to a carrier. If factory bring-up assumes the fully assembled product is present, it becomes less flexible.

A robust board supports partial bring-up, meaning the absence of an optional peripheral shouldn't prevent basic programming, a missing sensor shouldn't hold the main bus in an undefined state, a disconnected module shouldn't cause a rail fault, and a board should expose enough test access to validate itself before the rest of the system exists. This matters particularly in modular product families, the more modular the hardware becomes, the more valuable independent bring-up becomes.

Factory diagnostics should produce useful failure categories

Factory testing isn't only about passing or failing, it should produce failure categories that help manufacturing and engineering respond quickly. A failed board shouldn't simply say "test failed," it should say something closer to "primary rail missing," "programming interface not responding," "reset stuck low," "board ID mismatch," "sensor rail overcurrent," or "CAN interface not detected." These categories help the factory decide whether a board needs rework, rejection, inspection, or engineering review, and create feedback loops so the team can identify assembly issues, supplier problems, test fixture wear, or design weaknesses across the fleet. The goal isn't just to test boards, it's to learn from failures at scale.

Final thoughts

Factory bring-up shouldn't depend on luck, tribal knowledge, or special firmware that only one engineer understands. It should be designed into the hardware. The strongest embedded products aren't just functional, they're testable before they're fully alive, exposing enough truth for the factory to validate power, reset, identity, programming, and basic interfaces in a repeatable way.

Special firmware can still exist, but it should be a tool, not a dependency. A factory-ready board should be able to enter the manufacturing flow as a blank, untrusted, partially assembled piece of hardware and still answer the most important questions:

• Who am I
• Can I be powered safely
• Can I be programmed
• Are my critical rails valid
• Can I move to the next stage? When the hardware can answer those questions without relying on full product firmware
• Factory bring-up becomes faster
• Cleaner
• Far more scalable
• The difference between a prototype that works and a product that can be built repeatedly