A hardware-to-firmware handoff that names the exact board revision
A useful hardware handoff says which design firmware should use, which assumptions changed, and where questions should go. A schematic image helps answer a pin question; the review also needs the identity of the source that produced it.
Start with a version
This guide is for a hardware engineer handing a KiCad design to a firmware colleague. The record can live in a repository, review ticket or approved workspace. It complements electrical review, firmware testing and bring-up on the actual hardware.
Record the project name, baseline source identifier and candidate source identifier. An identifier might be a Git commit or a saved project version. Record the physical board revision marking separately: a silkscreen label and a repository commit identify different things.
A moving link to the latest design is useful for navigation. Also record exactly what firmware reviewed. If your tool offers a version-specific link, reopen it in the intended reviewer session and check the selected version.
KiCad's project manager supports Git operations. A handoff record can complement your existing repository. See the KiCad 10 manual for version-specific behavior.
Explain the interface changes
Name the assumptions firmware should verify. This table is an illustrative prompt, not a completed review of a circuit.
| Item | Record for both versions | Reviewer question |
|---|---|---|
| Connector signal | Connector and pin mapping | Does the firmware mapping match the candidate schematic? |
| Enable signal | Active level and supporting component reference | Which firmware assumption needs confirmation? |
| Optional peripheral | Assembly variant and population choice | What behavior is expected when it is absent? |
Include applicable supply, reset, boot and address assumptions. The engineer responsible for the design determines which questions matter. Mark each item changed, unchanged or not checked. An empty cell should not silently mean unchanged.
Connect supporting information to the chosen revision. If you attach a BOM, image or check result, record which source produced it and how. A separately updated export may describe a different design.
Make the context reopenable
State the KiCad version, project and design files, project-local library dependencies, and locations of review notes. Confirm what the recipient can open before starting. A colleague inspecting a schematic and a contractor returning changed source may need different access.
Record the granted access and its intended duration. Keep confidential records inside the approved workspace. A blank public template is not a place to paste private links. When sharing open designs, preserve the original creator and applicable license.
Attach the decision to the candidate
Ask the recipient to record the version inspected, unresolved questions and the decision for the stated scope. If hardware changes afterward, record the new candidate and identify what needs another review.
When work resumes, confirm the source opened in KiCad. A browser view, downloaded archive and local project can point at different revisions. Review observations do not certify electrical safety, manufacturability or product compliance.
Download a blank review packet
Start with identity and intended change, then add the questions relevant to your handoff. These original templates work with your existing repository or issue tracker. No sign-in is required to download them.
For BoardRepo version selection and access prerequisites, read Compare PCB revisions and Share a board privately. The packet is a suggested review method, not an automated approval feature or a report of a measured team outcome.
Continue your work
Choose member and reviewer access, agree a source workflow, and arrange organization setup.
For KiCad projects, BoardRepo for KiCad lets you Push and Pull versions from the editor.