Arch Linux User Repository

Upstream have identified some bugs with the latest release (v1.8.1), and a new version is coming soon. This package is ready to be updated once that happens.

Upstream have identified some bugs with the latest release (v1.8.1), and a new version is coming soon. This package is ready to be updated once that happens.

cb_out: error: LIBUSB_TRANSFER_TIMED_OUT ch341a_spi_send_command:

This error can be temporarily fixed by changing line 211 from “step = currentBlockSize;” to “step = currentPageSize;” and line 1235 from “step = currentBlockSize;” to “step = currentPageSize;”, but this fix significantly reduces the read operation speed.

Hm... I tested it on my laptop, and everything worked... Then I started looking again for the cause of the error on my work PC. I have four USB buses, and by some unfortunate coincidence, two ports on bus 1 are connected to the front panel of the system unit. I also extended the rear USB port to the desk via an extension cable, and it also ended up connected to bus 1. The programmer doesn't work on bus 1. Connecting to other USB ports on buses 2, 3, and 4 works, regardless of whether it's USB 2.0 or USB 3.0, or via a 1.5-meter USB 3.0 cable. I don't know why it doesn't work on bus 1, even though there are no errors in the same Windows virtual machine. In general, if IMSProg doesn't work for you, try using other USB ports. I apologize for the previous comments, but perhaps my experience will help someone.

I've just now checked this with a freshly updated Arch and the current version of this package. I generated a random 16MiB binary and flashed it to a Winbond 25Q128JVSQ. IMSProg erased, programmed, and verified the file without error, and after a subsequent dump and diff, the dumped binary is identical to the original file.

@tutralex It sucks you're having issues, but whatever the issue is, it appears to be at your end. Sometimes a device that works on Windows might not work on Linux due to subtle differences. Sometimes it's udev, sometimes it's your machine, often it's something else entirely. If someone else is able to reproduce, I'd recommend opening a new issue on the upstream GitHub repo.

@fermino I have Arch Linux installed with all the latest updates and IMSProg from the AUR, but only the chip search works, and it identified it correctly. Reading and writing don't work. How did you get it to work correctly?

@giovanni copy "/etc/udev/rules.d/71-CH341.rules" did not give a positive result. Note: the hardware works in a Windows 10 virtual machine when I pass through the USB device "QinHeng Electronics CH341 in EPP/MEM/I2C mode, EPP/I2C adapter" (lsusb), it is not broken!

@tutralex I noticed that this package installs the 71-CH341.rules file in /usr/lib/udev/rules.d/ instead of in /etc/udev/rules.d Could this be the cause of the issue?

My 2 cents: I have used this in 2025 without issues, so I don't think discussing whether the package should be in the AUR is much productive...

@tutralex I wrote to the author of the imsprog software and he said that this problem was in the last releases of UBUNTU, Linux Mint and other Linux systems. But now in UBUNTU and Linux Mint this problem has been successfully solved automatically. We need to understand how they solved it...

@giovanni I tried downgrading from the current (Arch Linux) libusb-1.0.29-1 to 1.0.27, 1.0.26, etc., but to no avail. Judging by the forum, the issue was encountered back in 2024 (https://bbs.archlinux.org/viewtopic.php?id=298664). If the program hasn't worked for a long time, why is it in the AUR? By the way, it doesn't work in Manjaro Linux either.