BIN vs HEX Firmware Files: What Your Replacement MCU Needs

What is the difference between BIN and HEX?

A raw BIN file contains a sequence of bytes. An Intel HEX file represents data in text records that include address information and record checksums. Both can carry program data, but the extension alone does not identify the correct device, prove that the image is complete or establish that the board will work.

This guide uses “HEX” to mean Intel HEX, not a generic hexadecimal display in a file viewer. Arm Keil’s Intel HEX reference explains the record structure and extended addressing. A programmer must interpret those records correctly; changing a filename from .bin to .hex does not perform that conversion.

For a replacement project, begin with the full MCU marking, board revision and the required outcome. Recovering an executable image, rebuilding source code and modifying a product are different tasks. Our IC unlock and firmware recovery service assesses device-specific recovery; it does not assume that every device or protected region can be read.

BIN and Intel HEX at a glance

These differences are about the container. They do not make one valid payload inherently more capable than the other. Choose the format the specified programmer or bootloader accepts, then verify that the delivered data and addresses match the project requirements.

Why the memory map matters

A BIN file needs a documented destination. A bootloader and an application may occupy different regions, while external memory may hold additional data. Programming the correct bytes at the wrong location can produce a device that verifies successfully over that region yet does not boot as intended.

Do not borrow a start address from an unrelated board or MCU family. Record the actual device, image purpose, memory region, load address and expected byte count. A generic example from a tutorial is not evidence for a particular production board.

Intel HEX addresses reduce ambiguity about where included data belongs, but they do not prove that all required regions are included. Review the image range with the programming tool and compare it with the agreed memory map. Configuration locations and device-specific address conventions also need attention.

Microchip’s explanation of unusually large XC32 BIN files shows how gaps between addressed regions can inflate a flat binary image. File size should be interpreted together with the memory layout, rather than treated as a direct measure of useful program code.

What should accompany a recovered firmware file?

Ask for a handover manifest that makes the result reproducible. A filename such as final.hex is difficult to manage after several board revisions. Use a controlled project identifier, version and a record of what was recovered or supplied by the customer.

• Device identity: complete manufacturer marking, relevant revision and the target board reference.
• Image identity: file name, format, size, file hash and which memory region it represents.
• Programming information: destination addresses for raw images, supported tool requirements and any required configuration records.
• Scope boundaries: regions included, unavailable data and items intentionally excluded from the handover.
• Validation record: which sample was programmed, the comparison performed and the board functions tested.

The record should distinguish common program code from device-specific data. Calibration, serial identifiers, configuration, external EEPROM contents or an existing bootloader may have separate roles. Their handling depends on the device and the authorized project. Do not assume that copying every byte between units is always appropriate.

When PCB layout recovery is also required, align the hardware revision with the firmware manifest. A correct image for another board revision can still be incompatible. See why a cloned PCB may not work for a broader verification framework.

Three different questions to verify

1. Is the file intact?

A recorded file hash helps identify whether the file received matches the file released. Intel HEX record checksums can detect certain record errors. Neither mechanism proves that the original extraction was complete or that the firmware is suitable for the intended hardware.

2. Was the intended data programmed?

Where supported and permitted by the device’s protection state, the programming workflow can check data against the supplied image. Document the tested regions and any limitations. Readback restrictions need a device-specific acceptance method; a blank “verify passed” statement does not describe the whole test scope.

3. Does the replacement board perform correctly?

Functional testing checks behavior in the agreed board and equipment setup. Establish startup, communication, I/O, stored settings and any relevant operating modes. Record the reference used, observed results and unresolved differences. The acceptance test should match the service the replacement board must perform.

Keep a preserved reference and an approved test sample. Avoid erasing or experimenting with your only working device when the stored information is what the project needs to recover.

Firmware enquiry checklist

Use this temporary checklist before requesting a review. No file is uploaded by ticking a box.

If files are missing, send chip and board photographs with the sample condition. If files already exist but a replacement fails, describe the programming result and observed behavior rather than requesting an automatic “unlock.” The issue may need file-package or hardware review. Ask for a feasibility review and arrange confidentiality requirements before transferring proprietary data.