Skip to content

Latest commit

 

History

History
110 lines (75 loc) · 3.1 KB

README.md

File metadata and controls

110 lines (75 loc) · 3.1 KB

ISP-55e0 - An ISP flashing tool for the WCH CH55x, CH57x and CH32Fx

This tool is meant to flash the WinChipHead CH55x / CH57x / CH32Fx series, such as the CH551, CH552, CH554, CH559 or CH579, through USB on Linux.

When set in ISP mode, the chip creates a 4348:55e0 USB device, hence the name for that project.

A few similar tools exist for the CH55x series, but all appear unmaintained and / or are without a proper license:

So the wheel has to be re-invented.

Tested on:

  • a CH551 with a bootloader version 2.3.1
  • a CH552 with a bootloader version 2.4.0
  • a CH554 with a bootloader version 2.4.0
  • a CH559 with a bootloader version 2.4.0
  • a CH579 with a bootloader version 2.8.0
  • a CH32F103C8T6 with a bootloader version 2.3.1

Build

It needs the libusb development package. On Debian / Ubuntu, install the "libusb-1.0-0-dev" package. In rpm world, it is usually called "libusb1-devel".

Type:

make

Usage

Help:

./isp55e0 --help

ISP programmer for some WinChipHead MCUs Options: --code-flash, -f firmware to flash --code-verify, -c verify existing firwmare --data-flash, -k data to flash --data-verify, -l verify existing data --data-dump, -m dump the data flash to a file --debug, -d turn debug traces on --help, -h this help

Query the device:

./isp55e0

Flash some firmware:

./isp55e0 -f fw.bin

Verify an existing firmware against a flashed firmware:

./isp55e0 -c fw.bin

Note that if the verification fails, all subsequent verifications will fail. The chip has to be power cycled to fix the issue.

Note on the CH32F103C8T6 BluePill clone

That chip has 2 USB ports, and only one is exposed. The USB port used by the bootloader connects to PB6 (D-) and PB7 (D+), while the breakout board only show the other USB port, which connects to PA11 (D-) and PA12 (D+).

There are some breakout boards with 2 USB ports, so soldering may not be needed on these.

Note on the firmware encryption

A drawback of these devices is that the firmware has to be sent encrypted to the device. The host creates the key, which is sent garbled and hidden amongst garbage bytes to the bootloader. The bootloader extracts the key from predetermined offsets in the packet and will use it later to decrypt the data before flashing or comparing. As it's a simple fixed size xor key, it's rather easy to figure it out, but this is just plain stupid. Since the last byte of the key is the sum of the first byte plus the chip type, it is not possible to create a fake key full of zeroes.

There are plenty of other manufacturers who don't do that stupid shit.

For some reason, the data flash is different. Writing to it has to be encrypted, but reading from it is in clear.

Caveats

Setting options is not implemented. The program will make no attempt to recover from an error and will just exit.