Merge ISP and USB bridge firmware into one flash image

A custom USB board camera usually carries two processors in the video path: an image co-processor (ISP) that turns raw sensor data into a finished image, and a USB 3.0 bridge that presents the assembly to the host as a video-class device. Each processor takes its code from a different SDK in a different file format, and neither file alone boots the camera — you flash one combined image instead. Below you will find how the merge works, how the camera boots from a single flash chip, how to size the flash and the USB link with worked arithmetic, which firmware layer you rebuild when the sensor changes, and the point at which a stock board camera removes the problem entirely.

Why does one USB camera need two firmware images?

A two-chip USB camera has two processors in the video path, so it needs two firmware images: the image co-processor runs its own image-processing code, and the USB 3.0 bridge runs the code that enumerates the device as a video-class device and streams frames at up to 5 Gbps.

Raw sensor output is not a picture a host can use. The ISP applies black-level and lens-shading correction, demosaics colour sensors, runs auto exposure and white balance, and often compresses the result. The bridge does none of that: it answers enumeration, serves the video-class descriptors, and moves finished frames across the USB link. Two dies, two instruction sets, two SDKs — hence two separate builds.

The bridge is also the manager of the pair. It holds the flash, and in the single-flash arrangement this article covers it loads the ISP at boot. The bridge-side hardware decisions around such cameras are the subject of Board-level camera and USB3 bridge board: match before you stream; this article picks up at the firmware the two chips run.

Why is the ISP firmware a .bin when the bridge firmware is a .img?

The two toolchains sign their outputs differently: the bridge SDK emits a bootable .img with the header and checksum its USB bootloader checks, while the ISP kit emits a raw .bin payload that the bridge delivers to the co-processor after reset, so the merge takes one of each.

The row that matters for project planning is the last one: bridge rebuilds are the exception, ISP rebuilds are routine. Hand-converting one format into the other defeats both checks, so the merge utility reads each file in its native form and writes one output .img.

What does the merge command look like?

The vendor merge utility takes three arguments — the bridge .img, the ISP .bin and an output filename — and writes one merged .img with each payload placed at the flash offset the camera stack's design fixes, so you never choose an offset yourself.

merge-tool -c bridge_fw.img -t isp_fw.bin -o camera_merged.img

The executable name and flags above are an example of the argument pattern, not vendor identifiers; the real merge application ships with the camera stack's SDK and its flashing guide. The pattern is stable: one flag takes the bridge image, one the ISP binary, one the output. Keep every input in the same folder as the tool — the utilities resolve relative paths and stop cleanly when a file is missing, which is the failure you want before flashing rather than after.

How does the camera boot the merged image?

Boot is a two-stage sequence at every power cycle: the bridge's bootloader validates and starts its own code, then the bridge — acting as the flash's SPI master — clocks the ISP payload out of flash into the image co-processor, which sits as SPI slave until it is running.

Flashing itself happens once per board. Set the board into programming mode, connect USB, and the bridge's bootloader accepts the merged .img from the host utility and writes both regions in a single pass. From the next power cycle the camera boots itself with no host tool involved.

The merge flow applies when one flash chip serves both processors, which is the common design in this class. Boards that give the ISP its own small flash, or that deliver ISP code over another link, are programmed chip by chip and have nothing to merge. Draw the layout before the first update — which offset holds the bridge image, which holds the ISP payload, which holds settings. The same discipline appears in the guide to a flash memory map for a firmware update.

How much flash does the merged image need?

Size the SPI NOR from the sum of both payloads plus a settings region: a merge of a 190 KB bridge .img and a 1,600 KB ISP .bin occupies 1,790 KB, which a 16 Mbit (2,048 KB) part holds with 258 KB to spare.

Re-measure after every build rather than at design time only. ISP payloads grow as you add compression tables and per-sensor tuning data, and the growth stays quiet until the merge outgrows the part. Reserve the settings region in the flash map and keep factory calibration — lens-shading and white-balance tables measured per board — outside both payload regions. A release build that overwrites calibration returns as shading rings or colour casts that no firmware update repairs.

How much USB bandwidth does the merged camera need?

Budget an uncompressed video stream as width × height × bytes per pixel × frame rate: 1,920 × 1,080 at 2 bytes per pixel and 30 fps is about 124 MB/s, roughly 995 Mbps — easy for USB 3.0, impossible for USB 2.0's 480 Mbps line.

Work an uncompressed 1080p30 stream in YUY2, which packs 2 bytes per pixel. One frame: 1,920 × 1,080 = 2,073,600 pixels, so 2,073,600 × 2 = 4,147,200 bytes. Per second: 4,147,200 × 30 = 124,416,000 bytes ≈ 124 MB/s, which is 124,416,000 × 8 ≈ 995 Mbps. USB 3.0 runs a 5 Gbps line rate; after 8b/10b encoding and protocol overhead roughly 400 MB/s remains usable, so this stream consumes 124 / 400 ≈ 31% of the budget. At 60 fps the share is about 62%, still comfortable.

The same arithmetic rejects USB 2.0 for this camera: the 480 Mbps line cannot carry 995 Mbps at any efficiency. A USB 2.0 build compresses or shrinks — MJPEG at a typical 5:1 to 10:1 puts this stream near 12-25 MB/s — or cuts resolution and frame rate. Check the ISP-to-bridge link too, because it carries the same bytes and its specification caps the frame rate before USB does: if that link is specified at 250 MB/s, the 124 MB/s stream fits, while a 4K counterpart — 3,840 × 2,160 × 2 × 30 × 8 ≈ 3.98 Gbps, about 497 MB/s — exceeds USB 3.0's usable budget and needs compression or a lower frame rate.

Sizing the sensor comes before any of this: the camera resolution calculator turns your field of view and smallest feature into the pixel count these stream formulas consume.

When you swap the image sensor, which firmware do you rebuild?

The sensor change lands in the ISP firmware, not the bridge firmware: the ISP owns the sensor's register tables, MIPI input timing and image-processing pipeline, so you rebuild and re-merge only the .bin while the bridge .img stays as it is.

The division follows what each chip knows about the hardware. The ISP project holds the sensor register init sequence, MIPI lane count and bit rate, Bayer order, embedded-data handling and the per-sensor tuning tables. The bridge project knows only that frames arrive and must stream. Two changes reach into the bridge image: a new output resolution or frame-rate list, because the video-class descriptors the bridge serves must advertise exactly what the camera can produce, and a new payload format between ISP and bridge.

Calibration needs a re-shoot as well. The lens-shading and white-balance tables were measured against the old imager, so image quality now rests on ISP tuning matched to the new sensor; re-shoot calibration after the mechanical swap, then cut the final .bin and merge again.

Treat the swap as a lifecycle decision rather than a feature. The guide on board level camera replacement when a sensor goes end of line lays out the options, and matching the sensor to the host before you buy prevents most forced swaps.

When should you not build a two-chip USB camera at all?

If a stock board camera already meets the resolution, frame rate and interface you need, buy it and skip both firmware layers: a 3.1 MP USB3 module with a global shutter streaming 120 fps covers most inspection work without a line of camera firmware.

The two-firmware architecture earns its complexity when you need a specific sensor with custom optics, an unusual form factor, or image processing that must run inside the camera. If a stock module meets the specification, the merge step, the vendor SDK agreements, the flash budget and the whole bring-up leave your project. Compare stock options in the board-level cameras category and the camera finder.

LS-BCM-0003 pairs a 3.1 MP global-shutter sensor with a C-mount board and streams 120 fps over USB3, which ends the firmware conversation for most conveyor-speed inspection.

For more pixels, MV-CB060-10UM-B carries a 6 MP mono sensor in 1/1.8" format with a rolling shutter on a bare board over USB3, and LS-BCM-0047 gives a 1.3 MP colour module with a global shutter in 1/2.7" format on a C-mount.

What should you check before you flash the merged image?

Before you flash, check five things: the merged file's size against the fitted flash, the build pairing of ISP .bin and bridge .img, the board's hardware revision, the fate of the calibration region, and a boot proof after a full power cycle.

1. Flash fit. Sum bridge .img + ISP .bin + settings region and compare against the fitted flash, as in the worked example above; re-check after every build.
2. Build pairing. Both payloads should come from the same camera-stack release; a new ISP .bin with an old bridge .img can break the hand-off between the chips.
3. Hardware revision. Flash size, flash map and the boot handshake can differ between board revisions, which is what board-level camera hardware revision compatibility before you reorder helps you match.
4. Calibration state. Confirm the settings region sits outside both payload regions so factory lens-shading and white-balance tables survive the flash.
5. Boot proof. After flashing, power-cycle rather than reset, confirm the device enumerates under the expected video-class name, and stream at target resolution and frame rate for a few minutes.

If the merged-image flow is larger than your roadmap needs, the stock route above ends it; if you are committed to the custom stack, work the checks in order and keep the build log current. The camera configurator narrows stock modules by sensor, mount and interface, and the systems topic page collects the rest of the firmware-side guides. When a question resists both routes, contact us with the flash map and the two payload sizes — that is the information a support engineer asks for first.