If your product carries firmware, the quotation you receive from a PCBA manufacturer usually shows IC programming as a single line, which makes it easy to treat as an incidental step.
That line governs three things: how quickly you can ship after a firmware revision, who absorbs the cost of chips that fail programming, and how your firmware is controlled once it leaves your hands. Changing any of them after a project has started tends to mean revalidating programming yield or building new fixtures, which costs more than settling the question up front.
The first decision is the programming method itself, because it determines the other two.
How Offline and In-Circuit Programming Differ
Offline programming loads the firmware into the chip before placement, using dedicated programming equipment. It runs quickly and suits volume production. The trade-off is that it needs separate handling and mix-prevention controls, and any programmed chips that go unused become dead stock.
In-circuit programming writes the firmware after placement, through a JTAG, SWD or ISP interface on the assembled board. It handles revisions easily, creates no dead stock and removes the risk of mixed lots. The trade-off is line time, which becomes a constraint at higher volumes.
| Offline programming | In-circuit programming | |
| Point in the process | Before placement | After placement |
| Throughput | High, suited to volume | Limited by line takt time |
| Revision handling | Programmed stock becomes obsolete | New file loaded on the next build |
| Dead stock risk | Present | None |
| Mix-up risk | Requires separate controls | None |
| Design prerequisite | None | Reliable test points or a debug connector |
In-circuit programming carries one design prerequisite worth raising early: the debug interface needs reliable test points or a connector. Confirming this during prototyping is straightforward, whereas discovering unstable probe contact during volume production usually means a board revision.
Which Method Suits Which Stage
Prototype and small batch work almost always runs in-circuit. Revisions are frequent at this stage, and the dead stock exposure of offline programming is difficult to justify against modest quantities.
Once volumes rise and the firmware settles, offline programming becomes worth evaluating. The switch is not automatic, since programming yield needs revalidating on the new method before the first production batch.
The IC programming service at Venture Electronics runs both methods and covers BGA, QFN, QFP, SOP and PLCC packages. Offline programming runs in parallel with PCB fabrication, so chips are programmed while bare boards are still in production and the step adds nothing to the overall turnkey schedule.
Who Should Handle the Programming
Method settles when programming happens. The separate question is who performs it.
| Party | Suited to | Main cost |
| Programmed by you | Firmware under strict confidentiality, or a product still in active debug | Chips or assembled boards travel between you and the factory, extending both logistics and scheduling |
| Pre-programmed by the distributor | Fixed part numbers, high volume, frozen firmware | Typically 3 to 4 weeks to ship after first article approval, and every firmware update restarts the cycle |
| Programmed by the manufacturer | Multiple variants, low to medium volume, ongoing revisions | Firmware is released to the manufacturer, whose version control and confidentiality arrangements need checking |
Revision frequency is the deciding factor. A project whose firmware is still iterating loses time queueing for distributor programming on every update. A frozen design running at high volume genuinely benefits from distributor pricing.
Multi-variant work at low to medium volume usually sits with the manufacturer, because programming shares a flow with placement and test. When you release an updated file, the line can switch to it the same day.
Firmware Version Control and IP Protection
This is the part buyers ask about least and pay for most heavily when it goes wrong.
Version control. Release firmware with a version number and a checksum, and require the manufacturer to verify each unit against it and record the result with the test data. A programming flow without verification cannot demonstrate which version went into a given batch. Where a product requires certification, version traceability forms part of the evidence package.
Venture Electronics performs 100 percent data verification after programming to confirm code integrity, with results retained by batch.
Revision handover. When firmware is updated, the previous version needs formal withdrawal, and two versions must never sit on the line at once. A direct question covers this: once a new version is released, how is the old file handled, and who confirms the change in writing.
Intellectual property. Three points can be confirmed individually:
- Whether firmware files stay on designated equipment inside the factory, and how access is limited
- Whether files are deleted on project completion, and what records are kept
- Whether a confidentiality agreement can be signed before the project starts
Venture Electronics signs a formal non-disclosure agreement before a project begins, stores firmware files on restricted servers accessible only to authorised engineers, and securely deletes the data on completion at your request.
Read protection. Most MCUs support a read protection setting written after programming, which prevents the code being extracted and copied. This belongs in the programming work instruction rather than in operator memory.
What to Verify in a Manufacturer's Programming Capability
| Check area | What to confirm | Warning sign |
| Device and package support | Supported MCU and memory families, package types | Claims broad support without naming specific families or packages |
| Programming method | Whether both offline and in-circuit are available | Only one method, leaving no room to adjust with volume |
| Verification and records | Per-unit verification, data available with the batch | First article only, no verification through the run |
| Fixtures and sockets | Capability and lead time for new socket or adapter development | Outsourced, with no controllable schedule |
| Version management | Version register and withdrawal process for superseded files | Files exchanged by email with no register |
| Confidentiality | NDA, file storage rules, access permissions, deletion terms | No written arrangement |
Venture Electronics supports devices from more than 190 semiconductor brands, produces programming consumables and fixtures in house, develops sockets and adapters for new part numbers on site, and works with an engineering team holding over a decade of MCU and memory programming experience.
How Failed Chips Are Handled and Charged
Settle this at the quotation stage, because practice varies between suppliers and the difference shows up directly in cost.
Three points need confirming: how failed devices are identified and segregated, who absorbs the loss, and whether reprogramming is permitted. Some suppliers charge against quantity issued and leave failures with the customer; others charge against verified good units.
The process at Venture Electronics marks and separates any device that fails programming or verification automatically, and charges only for units programmed and verified successfully.
Programming price otherwise depends on quantity, device complexity, whether a new socket or adapter has to be developed, and the method used.
What to Provide to Start a Programming Project
A complete package shortens both quotation and first article confirmation. Four items are the minimum:
- Firmware file, commonly in.hex,.bin or.elf format
- Full IC part number, used to confirm device support and socket requirements
- Programming specification, covering voltage requirements, configuration settings and checksum
- Quantity for this order, used to determine method and fixture approach
Functional verification and unit-level testing after programming run within the same flow, configured as described under PCBA testing services.
Send the package above to the Venture Electronics engineering team for a recommended programming method, a fixture approach and pricing.
FAQ About IC Programming
Q1: How long does a firmware revision take to reach production? In-circuit programming allows a switch on the same day the new file is confirmed, with no effect on scheduling. Distributor pre-programming requires first article approval and shipment again, which normally runs beyond three weeks.
Q2: Does programming add to the lead time?
Running offline programming alongside PCB fabrication keeps it off the critical path entirely. The exception is a new part number, where socket or adapter development typically takes several working days.
Q3: Can uncommon device types be programmed?
Support depends on the device library in the programming equipment and on socket availability. Supplying the full part number allows engineering to confirm library coverage and, where it is absent, to assess the development time for a socket or adapter.
Q4: Can the customer supply pre-programmed chips?
Yes, though incoming sampling terms are worth agreeing in advance. Programming status cannot be judged visually, and a version error discovered during volume production means removing and reprogramming parts.
Q5: Does read protection interfere with later firmware updates?
It depends on the protection level selected. Some levels block reading while leaving reprogramming available, others lock the device permanently, so the level should be chosen against whether field updates are planned.
