# IMSProg: an EEPROM and flash chip programmer built on cheap USB adapters

> IMSProg is a Qt desktop program that reads and writes I2C, SPI and MicroWire EEPROM and flash chips through the CH341A programmer, which is a USB adapter sold for a couple of dollars and originally intended for LED boards. The interesting part is the chip database, which is a shared format that several other programmers also use, and the adapter system that makes one cheap board work across incompatible chip packages.

**bigbigmdm/IMSProg** — IMSProg - software for CH341A-based programmers to work with I2C, SPI and MicroWire EEPROM/Flash chips

- Repository: https://github.com/bigbigmdm/IMSProg
- Website: https://antenna-dvb-t2.ru/IMSProg.php
- Stars: 708 · Forks: 123
- Language: C++
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/bigbigmdm-imsprog

## The name, the hardware, and what the tool actually covers

IMSProg expands to I2C, MicroWire and SPI EEPROM and Flash chip Programmer, and the README is explicit that it is a program to read and write EEPROM chips using the CH341A programmer device, the CH347T programmer device and the FT232H v1.2 programmer device.

That hardware list is the key to understanding the project. Version 1.9.1 of IMSProg added support for the FT232H v1.2, which the README lists alongside the CH341A and CH347T devices. The supported boards are CH341A/B v1.2, CH341A v1.7, CH347T v1.0, CH347T v1.1 and FT232H v1.2.

The chips covered are the small serial memory parts that turn up in firmware: I2C EEPROM in the 24xxx series, SPI NOR flash in the 25xxx series, SPI NAND flash, DataFlash in the AT45DBxxx series, and MicroWire EEPROM in the 93xxx series.

The tool has an explicit respect for other software. It makes respect to QHexEdit2, a hex editor, and SNANDer, another programmer, and the format of the chip database is based on the format used in EZP2019, EZP2020, EZP2023, Minpro I and XP866+ programmers, with a warning that the format is not the same.

That warning is worth reading carefully. Sharing a format with other tools means you can move a database between them, and it does not mean the databases are interchangeable. Anyone planning to bring an existing EZP2023 database over needs to check the differences rather than assume they are the same.

The licence is GPL-3.0, and the project ships an rpm/ directory, so it is packaged for RPM-based distributions.

## Three programs in one repository, and a shared chip database

IMSProg is a collection of tools rather than a single application, and the three parts are separated into their own directories at the repository root.

IMSProg_programmer/ is the chip programmer, described as the main part. IMSProg_editor/ is the chip database editor. IMSProg_database_update/ updates the chip database using an external web server.

That third one is the interesting design decision. Rather than every user adding chips by hand, there is a mechanism to push database updates from a server, which is how a chip library stays current across a user base that has no package manager story for a desktop app.

There is also a small amount of C at the top level, a spi_controller.c, which suggests the SPI bit-banging or low-level handling lives outside the C++ code, and a CMakeLists.txt at the root driving the whole build. The supporting scripts are build_all.sh for the Linux build, create_macos_appbundles.sh for macOS packaging, plus update.sh and uninstall.sh. There is a .clang-format file and a .circleci/ directory for continuous integration.

The documented build for Linux is short:

```
git clone https://github.com/bigbigmdm/IMSProg.git && cd IMSProg
sudo ./build_all.sh
```

Running the build as root with sudo is worth noting, because it is not the usual advice for a build script, and it is the difference between a build that works and one that cannot write to its own output directory in a system location.

The chip database format has its own documentation section in the README, which tells you that the format is a designed artefact rather than an internal detail, and that several other tools read and write it.

## The adapter system, and why 1.8 volt chips need a different slot

The physical part of the tool is the adapter system, and the README is unusually precise about it because getting it wrong means destroying a chip.

The 24xxx and 25xxx series chips must be inserted directly, according to the markings on the PCB of the CH341A programmer. The 93xxx series chips must be inserted into the 93xxx adapter, and the adapter into the marking 25xxx programmer slot. The DataFlash AT45DBxxx series chips must be mounted in a SOP-8 DIP-8 adapter, which is then inserted into the 45xxx adapter, and the 45xxx adapter must be installed in the programmer slot marked 25xxx. The SPI NAND Flash chips must be mounted in a WSON-8 DIP-8 adapter, which must be installed in the programmer slot marked 25xxx.

And then there is the voltage case. If the chip supply voltage is 1.8 volt it must be inserted in the 1.8 volt adapter, and the adapter into the needed programmer slot.

So the rule that emerges is that a chip in a package the programmer cannot accept gets an adapter, and the adapter goes into a slot whose marking names the protocol family of the target chip, and the 1.8 volt parts get a different adapter again. The three-level socket arrangement is what makes one cheap board universal.

The programmer itself plugs into the USB socket of your computer, and you can plug and unplug the programmer device at any time when basic operations, meaning reading, checking and programming, are not in progress. That last point is a real convenience: the tool does not hold the device open permanently, so you can reseat a chip without quitting.

There is a note that the MicroWire 93Cxx protocol is not supported by the CH347 programming device, and that the CH347T V1.1 is a device with a lower speed than the CH347T V1.0. Both are limitations of particular hardware rather than of the software.

A separate repository, Tools_for_CH341A_programmer, holds the designs for the homemade adapters, and the README links to it for more about adapters.

## Chip selection, and the difference between a NOR flash and an EEPROM

Selecting the right chip type is the step that determines whether detection works, and the README is precise about which types support automatic detection and which do not.

The Type pop-up menu offers SPI_FLASH for SPI NOR flash chips of the 25xxx series, SPI_NAND for SPI NAND flash chips, 24_EEPROM for I2C EEPROM of the 24xxx series, 93_EEPROM for MicroWire EEPROM of the 93xxx series, and 45_EEPROM for DataFlash chips of the AT45DBxxx series.

The Detect button, or the keyboard shortcut Ctrl+D, is available for 25xxx series SPI NOR flash, SPI NAND flash, and AT45DBxx series SPI flash. When it is pressed, the JEDEC information is read from the chip and all parameters of that chip are loaded from the chip database. Any parameter, and the list given is size, page size, block size, VCC voltage and 4-bit address length, can be changed manually, and you can manually enter the Manufacture and Name pop-up menu data, with all other parameters loaded automatically from the database.

The catch is that the Detect button is not available for 24xxx, 93xxx, 95xxx or 25xxx SPI EEPROM series chips, that is the non-NOR-FLASH parts. For those it is necessary to manually enter the Manufacture and Name data, and everything else still comes from the database.

The reason is in the technology. NOR flash and NAND flash carry a JEDEC identification block that the programmer can read back over the same bus, so the chip can describe itself. A plain I2C EEPROM has no such block, so there is nothing to read and the user has to say what the part is. That is why one of the two families gives you a one-click setup and the other does not.

The file operations are the ordinary ones, with a Save button or Ctrl+S to write the buffer to a file, an Open button or Ctrl+O to load a file into the buffer, and a SavePart button or Ctrl+Shift+S to save part of the buffer, where the start address and length of the part must be entered.

## Building it on Linux, macOS and the RPM distributions

The build requirements are the same everywhere, because the hardware access is the same everywhere. You need a C++ compiler, g++ or clang, CMake, libusb 1.0, libftdi, Qt5 or Qt6, the Linguist tools, pkgconf or pkg-config, and udev.

The udev piece is the interesting dependency for a desktop application, because it is what lets the program talk to a USB device without running as root. And the version of udev you need depends on your distribution: on Debian 13 and later and Ubuntu 24.04 and later you install systemd-dev, while on older systems you install udev.

The Debian instructions come in two flavours depending on the Qt version. For Qt5:

```
sudo apt-get install cmake g++ libusb-1.0-0-dev qtbase5-dev qttools5-dev pkgconf libftdi1-dev
```

And there is a minimum: Debian older than 11 and Ubuntu older than 20.04 are not supported, and you may be unable to have it working on them.

The Fedora, OpenSUSE and macOS instructions follow the same shape, with dnf and zypper package lists for Qt5 and Qt6 respectively. On macOS, when using Homebrew, install the required packages with brew:

```
brew install qt@6 libusb cmake pkgconf libftdi
```

And there is a specific warning for anyone not using the build_all.sh script. Make sure libusb is in your C_INCLUDE_PATH:

```
export C_INCLUDE_PATH=/usr/local/opt/libusb/include
```

So the practical difference between the build script and doing it yourself is that the script sets that include path for you.

The Linux build is a single command that clones and runs the script as root, and the macOS side has its own script for producing application bundles, create_macos_appbundles.sh. The rpm/ directory is there for distribution packaging, and there is a CHANGELOG file at the root that the README links as ChangeLog.

One small operational note that saves confusion: for macOS use the command key instead of control for keyboard shortcuts, which is the usual cross-platform annoyance in a Qt application.

## Conclusion

Adopt IMSProg if you have a CH341A or CH347T adapter and need to read or write small EEPROM and flash chips, whether for firmware reverse engineering, BIOS chip work or general repair, and the software covers a wide chip range. Do not adopt it if your chip is a large SPI NAND or a part the database does not describe, since the tool is built around small serial EEPROMs and serial NOR flash. Before you write a chip, confirm the part is in the database and check the supply voltage, because 1.8 volt parts need a different adapter slot and the program warns about it.

## FAQ

### What hardware does IMSProg need?

It works with CH341A and CH347T programmers and the FT232H v1.2, with supported boards CH341A/B v1.2, CH341A v1.7, CH347T v1.0, CH347T v1.1 and FT232H v1.2. The README also notes that the MicroWire 93Cxx protocol is not supported by the CH347 device and that the CH347T v1.1 is slower than the v1.0.

### How do I build IMSProg on Linux?

Clone the repository and run sudo ./build_all.sh. You need g++ or clang, CMake, libusb 1.0, libftdi, Qt5 or Qt6 with the Linguist tools, pkgconf or pkg-config, and udev, which is packaged as systemd-dev on Debian 13 and later and Ubuntu 24.04 and later.

### Why can the Detect button not be used for I2C EEPROM chips?

The Detect button and Ctrl+D read the JEDEC information from the chip, which is only available for 25xxx series SPI NOR flash, SPI NAND flash and the AT45DBxx series. For 24xxx, 93xxx, 95xxx and 25xxx non-NOR-FLASH parts you must enter the Manufacture and Name data manually, with the remaining parameters still loaded from the chip database.

### Can I share a chip database with other programmers?

The database format is based on the one used in EZP2019, EZP2020, EZP2023, Minpro I and XP866+ programmers, and the README warns that the format is not the same. The project also ships IMSProg_editor for editing the database and IMSProg_database_update for pulling updates from an external web server.

## Sources

- [bigbigmdm/IMSProg on GitHub](https://github.com/bigbigmdm/IMSProg)
- [License: GPL-3.0](https://github.com/bigbigmdm/IMSProg/blob/main/LICENSE)
- [Project website](https://antenna-dvb-t2.ru/IMSProg.php)
- [README](https://github.com/bigbigmdm/IMSProg/blob/main/README.md)
- [Releases](https://github.com/bigbigmdm/IMSProg/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bigbigmdm-imsprog