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 does not 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 does not 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 cannot 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 cannot 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, and 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. It gives the team confidence. It 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 initialise hardware differently.

The deeper issue is not that factory firmware is bad. Test firmware can be useful.

The issue is making the factory bring-up dependent on it.

If a board cannot be identified, powered safely, programmed, or minimally validated without a custom runtime image, then the factory process is fragile from the start.

A factory bring-up process should not 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 do not depend on complex firmware behaviour.

These include 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, and 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,
• and safe default states on enable pins.

These checks are not glamorous, but they are 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 does not 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 is part of the product architecture.

If a board cannot 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 should not 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 initialisation.

The board should be programmable even when the previous firmware image is corrupted, incomplete, or absent.

This is 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 it reports the board type or serial number.

That is too late for factory bring-up.

The factory needs to know what it is testing before it runs complex tests.

Board identity can be established through several mechanisms: 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 is this? Which revision is it? What test limits apply? Which interfaces should exist? Which sensors are expected?

Without that, factories often compensate with manual process rules, which increases risk.

For example, a board variant without one optional sensor should not fail a test designed for a different variant. A sensor SOM should not be programmed with firmware intended for another module. A carrier board should not be validated against the wrong connector map.

Identity is not documentation.

Identity is a test input.

Power Rails Should Be Testable Before Firmware

Power is the first functional behaviour of any board.

If power is wrong, firmware results are meaningless.

A factory fixture should be able to verify that key rails come up as expected before flashing or running application tests. This becomes especially important in boards with multiple rails, such as MCU core rails, sensor rails, camera rails, IO rails, and switched feature rails.

The factory does not always need deep analogue characterisation. It needs practical confidence that the rail is present, within range, sequenced correctly enough, and not drawing abnormal current.

For example, before programming the board, a fixture may check:

• input current does not exceed a safe threshold,
• primary 3.3V rail is valid,
• MCU rail is active,
• reset supervisor releases reset,
• switched sensor rails remain off by default,
• high-current feature rails are not 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.

That means 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 behaviour.

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 are not deterministic, programming may fail randomly.

The safest factory-friendly boards behave predictably even when the MCU is blank.

That means careful use of pull-ups, pull-downs, reset supervisors, default-off feature enables, and deterministic boot strapping.

A blank MCU should not 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 should not 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 should not 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 is not factory-ready.

The best fixture relationship is clean:

The board exposes stable test access.
The fixture applies controlled stimulus.
The board responds in predictable ways.
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 are designed to 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 Are Better Than 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 behaviour.

A practical structure may look like this:

1. Fixture detects board and revision.
2. Fixture applies controlled power and checks current.
3. Fixture verifies reset and boot-mode behaviour.
4. Fixture programs known firmware through standard programming access.
5. Firmware performs self-test using normal production pathways.
6. Fixture records calibration, identity, and pass/fail results.
7. Final product firmware or configuration is applied.

The important point is not the exact sequence.

The important point is that the early stages do not depend on the full application already working.

Factory bring-up should reduce uncertainty step by step.

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 initialisation sequence, power timing, sensor configuration, or bus behaviour.

This creates a dangerous situation where boards pass factory tests but fail in real operation.

The better approach is to keep factory-specific behaviour small and infrastructure-like. Use 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 initialisation paths.

The factory should not become a parallel firmware universe.

Design the Board to Be Testable When Partially Populated

Production does not always happen in one clean step.

Boards may be tested before all modules are attached. Some variants may be partially populated. Some assemblies may be validated before final enclosure installation. 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.

That means the absence of an optional peripheral should not prevent basic programming. A missing sensor should not hold the main bus in an undefined state. A disconnected module should not cause a rail fault. A board should expose enough test access to validate itself before the rest of the system exists.

This is particularly important in modular product families.

The more modular the hardware becomes, the more valuable independent bring-up becomes.

A board that can only be tested after full assembly creates late-stage failures.

A board that can be tested independently catches defects early.

Factory Diagnostics Should Produce Useful Failure Categories

Factory testing is not only about passing or failing.

It should produce failure categories that help manufacturing and engineering respond quickly.

A failed board should not 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.
CAN interface not detected.
Camera rail sequencing failed.

These categories help the factory decide whether a board needs rework, rejection, inspection, or engineering review.

They also create feedback loops. If many boards fail the same category, the team can identify assembly issues, supplier problems, test fixture wear, or design weaknesses.

The goal is not just to test boards.

The goal is to learn from failures at scale.

Hoomanely’s View: Factory Bring-Up Is a Design Constraint

At Hoomanely, we do not see factory bring-up as a manufacturing-only concern.

It is a hardware architecture requirement.

A board should be designed so that a factory can safely and repeatably:

• power it,
• identify it,
• program it,
• verify its rails,
• control reset,
• test critical interfaces,
• detect major assembly faults,
• and move it forward without relying on custom one-off firmware.

This mindset changes design reviews.

Instead of asking only whether the circuit works, we ask whether it can be tested before the full system is alive. Instead of asking only whether firmware can initialise the sensor, we ask whether the factory can detect if the sensor rail is missing. Instead of asking only whether a debug connector is convenient for engineering, we ask whether it is reliable enough for repeated fixture use.

These questions make the product more manufacturable.

They also make it more recoverable, debuggable, and scalable.

Final Thoughts

Factory bring-up should not depend on luck, tribal knowledge, or special firmware that only one engineer understands.

It should be designed into the hardware.

The strongest embedded products are not just functional. They are testable before they are fully alive. They expose 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, and far more scalable.

And that is the difference between a prototype that works and a product that can be built repeatedly.