PCB Clone Not Working? Check Hardware, Firmware and Test Conditions

Why can a copied PCB fail to work?

A PCB clone can fail because the recovered hardware differs, the assembly or components are incorrect, required firmware or settings are missing, or the test setup does not reproduce the original operating conditions. Visual similarity and manufacturing-file checks alone do not establish a working replacement.

Begin by defining “not working.” Does the board fail to start, reset intermittently, communicate incorrectly, give inaccurate measurements, or fail only when installed in the equipment? Record the conditions, board revision and repeatability. Each symptom narrows a different part of the investigation.

This guide helps owners and engineering teams prepare a structured review of an authorized replacement board. It is not a live-circuit repair procedure. Testing energized equipment requires an appropriate setup and qualified personnel. Preserve the original reference board and existing files before making changes.

Match the symptom to the evidence

Symptoms may have more than one cause. Keep hypotheses separate from established observations. A software-looking fault can originate in the hardware, and a correctly assembled board can still lack required program or parameter data.

Establish a trustworthy reference first

Confirm that the original board works in the same configuration used to assess the clone. A damaged or intermittent reference can make a comparison misleading. Record equipment model, board part number, revision, fitted options and software version wherever known.

Label every sample and file package. Keep photographs of the as-received assembly, including modifications and hand-fitted wires. A production board may contain changes that are absent from an older drawing. Conversely, an improvised repair should not automatically become part of the recovered design.

Before commissioning more copies, define the intended equivalence. A manufacturing duplicate, a functionally compatible replacement and a redesigned board have different verification needs. Our PCB copy service scopes the manufacturing package, while reverse engineering adds circuit documentation for analysis or changes.

Review hardware and assembly as separate layers

Recovered connections and construction

Check the relationship between the recovered layout, netlist and the reference sample. Hidden layers, vias and connector assignments need evidence beyond top and bottom photographs. A design-rule check can identify specified rule violations, but it cannot prove that the chosen connections reproduce the intended circuit.

Board construction can also matter. Stackup, copper thickness, controlled impedance, return paths and mechanical clearances may affect operation. Where those requirements are relevant, record how they were established and how the manufacturing package specifies them.

Components and build execution

Compare the assembled board with the released BOM and assembly instructions. Review values, tolerances, package variants, orientation, populated options and substitutions. A part with a similar name or footprint is not necessarily electrically interchangeable.

Separate design evidence from assembly evidence. A correctly reconstructed circuit can be assembled incorrectly; a clean assembly cannot compensate for a missing connection in the source data. Keep inspection results and approved substitutions tied to the specific prototype revision.

Check firmware, configuration and calibration

A bare PCB file does not contain the program stored in an MCU. Programmable logic and external memory may also contribute to the board’s behavior. Establish which devices need data and whether that data was supplied, recovered, programmed and tested.

Configuration and calibration deserve their own entries in the project scope. Clock settings, boot selections and stored operating parameters can affect behavior even when the application image appears correct. Device-specific information may need an approved provisioning or calibration process rather than indiscriminate copying between units.

Read BIN versus HEX firmware files to understand why addresses and image coverage matter. A successful file conversion or checksum comparison does not establish a complete, compatible replacement. For unavailable program data, request an IC unlock assessment using the exact chip marking and sample condition.

Do not erase the only working device in an attempt to remove read protection. Preserve the sample and let the recovery scope establish the permitted handling and device-specific limits.

Close the gap with a written test plan

Use a test plan that connects each requirement to evidence. Include the reference sample, equipment or fixture, operating conditions, expected result, observed result and the person responsible for acceptance. Record limitations instead of allowing an untested function to look like a passing one.

1. Review the released package. Confirm the layout, BOM, firmware and assembly revision being evaluated.
2. Review the prototype. Document inspection and the agreed electrical checks before equipment testing.
3. Compare the required functions. Exercise startup, communications, I/O and other relevant operating modes in the agreed setup.
4. Resolve differences systematically. Change one controlled variable, retain the before-and-after record and repeat affected tests.
5. Release the accepted revision. Archive the final files, configuration, test evidence and any manufacturing instructions.

Acceptance needs to reflect the application. A board intended for continuous industrial operation may need evidence beyond a short bench demonstration. System-level approval and any required compliance work remain separate from recovering the PCB design.

Prepare a useful failure-review package

Use this browser-only checklist to organize the enquiry. Include facts and photos; an initial message does not require a guessed diagnosis.

Send the project details for review. State whether PCB-Copy is being asked to assess a new copy project, recover missing documentation or evaluate unavailable firmware. The agreed scope should identify deliverables, sample handling and acceptance tests before work begins. A review request is not a promise that every failed clone can be repaired.