Embedded Firmware Handover: What to Request Beyond Source Code

A source-code archive is not a complete firmware handover. The receiving team needs enough information to build the agreed revision, program the intended hardware and repeat the agreed checks. Define those acceptance steps before the final delivery milestone.

This guide is for buyers taking over an embedded development project or transferring maintenance to another team. It proposes a handover workflow; it does not promise that any particular project is reproducible, compliant or free of defects.

Define exactly what is being handed over

Identify the hardware revision, processor variant, bootloader boundary and application revision. List the deliverables separately: source tree, dependency manifest, build instructions, binary image, programming procedure, configuration description and test evidence. Record whether production programming fixtures and factory calibration data are included or excluded.

Ask for a release manifest mapping each delivered artifact to its intended use. An application binary, a combined bootloader image and a debug executable are not interchangeable merely because they came from the same project folder.

Distinguish buildable from reproducible

Reproducible Builds defines reproducibility in terms of recreating identical specified artifacts from the same source, environment and instructions. A project that compiles successfully on another workstation has passed a useful portability check, but that alone does not establish identical output.

Choose the requirement that matches the project. If exact binary reproducibility matters, name the artifacts and comparison method. If the initial milestone is only a clean build plus functional checks, describe it that way and retain any binary differences as unresolved evidence.

Record the build inputs

The build-environment documentation should identify relevant tool versions and configuration. As a practical handover checklist, request the compiler and linker version, SDK or middleware revision, target settings, linker script, generated configuration files and commands needed for a clean build. Include dependency acquisition instructions with lawful access requirements.

Keep credentials out of the source archive. Where signing or deployment needs an account, define the approved access process and owner separately. Document which build steps can run without that access and which cannot. Do not make a vendor’s personal workstation the only described release procedure.

Run a receiving-team exercise

1. Start from the delivered revision in a clean working directory. Record the machine and tool versions.
2. Follow the supplied instructions without undocumented assistance. Record missing steps instead of silently fixing them.
3. Save build logs and artifact hashes. Compare the specified outputs using the agreed method.
4. Program a designated test board using the documented interface and memory layout.
5. Run the agreed functional and recovery checks. Attach the build identifier to each result.
6. Record open defects, excluded features and the owner of each follow-up action.

Engineering Example: the delivered application builds but the receiving team cannot boot its board. The handover investigation first checks board revision, bootloader presence, image address and programming steps. A successful compilation does not answer these integration questions. This example is a proposed diagnostic workflow, not a reported InnovChip customer outcome.

Use hashes within their limits

A cryptographic hash is useful for checking whether two artifacts match. Matching hashes do not establish functional correctness, licensing rights or the authenticity of an untrusted reference file. Retain the manifest through the agreed trusted delivery process and review the test evidence separately.

Prepare a focused inquiry

Provide the current delivery list, accessible source revision, board description and the exact step your receiving team cannot repeat. Ask for a bounded review of the handover gap before requesting a complete redesign. The existing firmware development information is a starting point for discussing the scope.

Make the acceptance boundary explicit

Before requesting a handover, decide whether the receiving team must maintain the source, reproduce a release, program production units or all three. These jobs overlap but have different prerequisites. A team may be able to compile an application while still lacking the authorized signing process or the calibration records needed to prepare a finished device.

Write the boundary as a list of demonstrated actions. Name the board and revision used for each action. Record whether a debugger, bootloader, manufacturing tool or external service is needed. Avoid a vague requirement such as “all development files” when nobody has agreed whether it includes design tools, production fixtures or third-party components.

A practical delivery manifest

The following categories form a proposed review checklist. They are not a claim that every project requires the same artifacts. Mark non-applicable categories explicitly and explain why, so a missing item cannot be confused with a deliberate exclusion.

• Source identity: repository revision, release tag and any local changes that are part of the delivered release.
• Build inputs: dependency versions, configuration files, target definitions and scripts, with access instructions.
• Outputs: intended binary images, addresses or partitions, artifact identifiers and checksums.
• Hardware assumptions: board revision, processor variant, required peripherals and the test setup.
• Operation: programming, recovery and configuration procedures, including prerequisites and excluded states.
• Evidence: test cases, actual results, logs, known defects and a mapping to the delivered build.
• Ownership: who maintains each component, who controls release access and who decides whether an open issue blocks acceptance.

Keep the manifest tied to a particular delivery. A folder named “latest” is convenient for browsing but does not identify which revision produced an accepted artifact. If a delivery changes, issue an updated manifest that identifies the changed items and the reason for the change.

Use a clean-room exercise within a practical scope

Have a receiving engineer follow the delivery instructions without relying on the original author’s remembered steps. The exercise does not need to recreate every developer habit. It needs to demonstrate the agreed build, programming and test operations from documented inputs. Record any interactive assistance, because it identifies a missing instruction or an assumption that should become part of the handover.

If the environment relies on a licensed tool, confirm how the receiving organization obtains legitimate access. Do not copy an installation or an account simply because that would make the test easier. Where an external dependency cannot be redistributed, identify its version and lawful acquisition route. A technically complete archive can still have unresolved access or rights constraints.

Triage a failed receiving-team build

First preserve the exact command, log and source revision. Then compare the documented inputs with those actually used. A missing dependency, wrong target configuration and undocumented generated file require different corrections. Repeatedly modifying settings until compilation succeeds can hide the original defect and leave the receiving team unable to repeat the result.

If the output differs from the reference binary, distinguish the fact of a difference from its cause. Do not label it harmless merely because a basic functional test passes. Identify which artifacts were supposed to match, investigate the differing inputs and report the remaining uncertainty. Where exact reproducibility was not part of the contract, retain the narrower evidence of a successful build and the observed functional checks.

Compare handover proposals fairly

When comparing development or maintenance suppliers, ask how each one will demonstrate the receiving-team exercise, document unresolved dependencies and deliver test evidence. Compare the proposed scope, access requirements and responsibilities rather than relying on a promise to deliver “complete source.” Clarify whether fixing inherited build problems is included or is a separate assessment.

The work involved depends on the state of the repository, dependency availability, hardware access, programming process and required test coverage. These are cost factors, not a basis for inventing a universal fee. Ask for assumptions and exclusions alongside any quote. If the supplier cannot identify the release inputs, scope a discovery task before agreeing that a transfer can be completed on a fixed schedule.

Close the handover with an actionable record

Keep the final manifest, receiving-team results and open issues together. For each unresolved item, state its practical effect: unable to build, unable to program, unable to repeat a test, or unable to establish a particular claim. Assign an owner and a follow-up decision. Avoid describing the whole delivery as accepted when a critical operation remains dependent on undocumented assistance.

A useful final decision says what the new team can now do and under which conditions. If the release can be built but production programming remains outside scope, record that boundary. If a key dependency is unavailable, pause the affected acceptance step and resolve access. This creates a usable maintenance baseline instead of a source archive whose completeness nobody has tested.

Questions before you proceed

Does receiving source code establish ownership of every dependency?

No. The contract and dependency licences need their own review. The handover manifest should identify included components and access constraints without assuming redistribution rights.

Should the final acceptance require identical binaries?

Only if that requirement is agreed and the build inputs and comparison scope are defined. Otherwise report the narrower build and test results actually demonstrated.

Must production credentials be included in the archive?

No. Describe the authorized access process and responsible owner separately. The receiving team should know which operations require privileged access without embedding secrets in a general source delivery.

What if the original compiler is no longer available?

Treat tool access as an unresolved input. Investigate lawful access to the required version or scope a migration with its own validation. Do not label a build made with a substitute toolchain as an exact reproduction without evidence.

Does a successful handover end maintenance responsibilities?

The technical exercise establishes the operations demonstrated, not the commercial support terms. Clarify responsibility for known defects, new features and later dependency changes in the agreement, and keep those terms distinct from the test results.