AvalonMiner Aftermarket Service: Upgrade Tool (Beta) Instruction for A3202, A3201, and A3200 Models

The AvalonMiner Upgrade Tool (Beta) is a Windows batch flasher for Canaan’s Gen 2 miners — the ones built around the Kendryte K210 control board. It does two things on the wire: it discovers miners by knocking on the CGMiner API (TCP 4028), and it pushes an .aup package into the K210’s SPI boot flash, ten units at a time. That batch behaviour is why it deserves a real procedure: a wrong file or a blinking network drops ten machines at once, not one, and a Gen 2 K210 unit has no SSH, no shell and no documented user-level recovery path if the write is interrupted mid-flight.

"A3202, A3201, A3200" are chips, not miner models

Canaan’s own compatibility string is written in ASIC part numbers, which is why operators can’t find their model in it. Decode it against the hardware:

• A3200 (and its A3200CFA / A3200C-Plus / SK / SV2 die revisions) is the ASIC in the A1166 (68 TH/s), A1246 (90 TH/s), A1346 (110 TH/s) and A1366 (130 TH/s).
• A3201 / A3201F appear across Gen 2 hashboards alongside the A3200.
• A3202 sits in the Avalon A3xxx replacement-chip family (A3200–A3210) but is not tied to a named production miner in our records — treat it as a chip-catalog entry, not a target list.

The practical rule: if the miner is a Gen 2 K210 unit — the A1047/A1066 through A15xx integrated-MM line — this is the tool. Gen 1 (external Raspberry Pi + AUC3 bridge, OpenWrt) upgrades by OpenWrt sysupgrade. Gen 3 (Kendryte K230 — Nano 3/3S, Mini 3, Avalon Q) upgrades through SWUpdate on port 9090 with .swu packages and RSA signature verification. Neither answers this tool.

What the tool is actually doing

• Scan: sweeps your IP range on the port you give it (default 4028) and reads the CGMiner API version response — firmware version, HWTYPE, DNA and MAC. That is how it fills the serial/IP table. If 4028 is unreachable, the miner is invisible to the scan even when its web UI on port 80 loads fine.
• Upgrade: transfers the .aup and hands it to the on-device updater. On Gen 2 there is no PIC microcontroller and no separate hashboard firmware — the K210 drives frequency and voltage directly over the hashboard SPI link (1 MHz, 40-byte MM-protocol frames terminated by a CRC16). The .aup is the whole application; nothing else gets flashed.
• Export: writes the upgrade log. It is off by default and drops the log in the working directory if you don’t choose a path.

Environment: Windows 10 64-bit, no installer. Ten machines per batch.

Inside the .aup — and why the wrong one fails

The Avalon Update Package is a flat container: header, then payload. Mind the generation gap. The packages we have dissected in depth are the later A13xx–A15xx builds — fmt_ver 2, 200-byte header. Older A1166/A1246-era packages use the earlier layouts (fmt_ver 0, 92-byte header; fmt_ver 1, 224-byte header) with their own hardware-tag vocabulary. A tag or header size you read in one generation’s file proves nothing about another’s.

What holds across versions: the magic AUP format at offset 0x00; a firmware_ver string of the form <YYMMDDxx>_<mm-sha7>_<product-sha7> (e.g. 24041001_08b0955_0196aba); a header_crc32 and a payload_crc32, both plain zlib CRC-32; and a payload that is an AES-CBC encrypted K210 boot image terminated by a SHA-256 over the AES flag ‖ size ‖ ciphertext.

In the fmt_ver 2 files the header carries an hw_list of 32-byte hardware-target strings (MM3v2_X3, MM4v1_X3, MM4v2_X3, plus _LC liquid-cooled variants) and an sw_list (MM317, MM318_X2, MM319 …, each paired with an _OOW twin), over a payload of roughly 1.07–1.09 MB. The package declares its hardware target, so an air-cooled build (MM4v1_X3) is not the liquid-cooled build (MM4v1_X3_LC). _OOW means Out Of Warranty: identical payload, it only changes whether the updater prints a warranty-void warning.

Canaan’s FMS tooling validates both CRCs before it flashes; do not assume the Beta tool does the same. Check the size and SHA-256 of the .aup yourself before you point it at ten machines. Filenames encode the target: A1346-A3200C-Plus-Temp75_….aup names the miner, the ASIC revision and the temperature target. Match all three to the unit in front of you, and pull the file from Canaan’s official support channel for your model. Unlike the K230’s SWUpdate, the K210 path has no RSA signature gate — CRC32 and SHA-256 are integrity checks, not authenticity checks. Provenance is entirely on you.

Preflight — before you press Scan

1. Wire the laptop in. No Wi-Fi. A drop mid-transfer takes out every unit in the batch at once. Use a cable.
2. Confirm the API is reachable on one unit first. PowerShell: Test-NetConnection <ip> -Port 4028. From a Linux/macOS box on the same VLAN: echo -n '{"command":"version"}' | nc <ip> 4028. If the web UI loads but this times out, a VLAN ACL is blocking 4028 and the scan will find nothing.
3. Take the units off DHCP churn. A fresh or factory-reset Avalon comes up in config mode on 192.168.168.168 (web creds root/root) — outside whatever range you’re about to sweep.
4. Stabilise power. A brownout inside the flash window is what bricks the K210. Don’t upgrade a row while someone is switching breakers on it.
5. Note the current firmware version from the version response so you have something to compare against afterwards.

Run it

1. Enter the start and end IP of a range containing ten or fewer miners, and port 4028. Wider ranges just make the table noisy.
2. Scan. Every row should show a serial, an IP and a status. Missing rows are network problems, not upgrade problems — fix them before proceeding.
3. Turn the export switch on and choose a log destination. This is your only record when a bar stops at 60%.
4. Select the miners, load the matching .aup, upgrade. Watch the per-machine progress bars; Stop aborts and marks the row cancel.
5. Wait out the reboot before touching anything. Do not power-cycle a unit showing an in-progress bar.

When the scan finds nothing

• Port 4028 filtered. Most likely by far in a managed hashcenter network. Test it as above.
• Wrong range. Units still in config mode sit at 192.168.168.168.
• API busy. The CGMiner API is single-threaded with short-lived TCP connections. A unit mid-restart, or one being hammered by a monitoring poller, will silently drop the scan probe. Re-scan.
• Wrong generation. A K230 box in the range will not answer this tool’s upgrade path.

When a bar stops and the row says "failed"

• Package/board mismatch — an air-cooled build on a liquid-cooled controller, or a file built for a different MM hardware target than the board reports.
• Corrupt download — CRC-32 rejection. Re-download and check the size and hash against what Canaan published; a 4 KB error page renamed .aup is the classic.
• Link drop — re-run the single unit alone, wired.

Verify the upgrade

1. {"command":"version"} — the reported firmware string should now match the firmware_ver field of the .aup you pushed.
2. {"command":"estats"} — extended stats: per-board temperatures, voltages, fan speeds, frequencies. All hashboards must appear. Board voltage is regulated per domain (Vcore variable, VTOP 0.75 V, VDDIO 1.8 V), and each board carries two 10K NTC thermistors — a board that comes back with one sensor missing has a hardware problem, not a firmware one.
3. {"command":"summary"} — give it 30+ minutes and check the 15-minute average, not the 30-second figure.
4. Chasing a specific unit in a rack? ascset|0,led,1-1 lights its LED; ascset|0,reboot,0 restarts it.

The bar completed but the hashrate is still down. The .aup only rewrites the K210 boot flash; it never touches the hashboards. On A11/A12 boards the 120 chips are arranged as 40 groups of 3 parallel chips, chained CKin→CKout for clock and data. A chip that stops answering shows up as a reduced ASIC count; a broken link in the chain silences everything after it. Firmware does not repair silicon — a board that was short a chain before the upgrade will be short a chain after it. That is a job for the ASIC Fault Finder, not the flasher.

Common mistakes

• Leaving 4028 reachable from outside the management network. The API answers version, summary and stats, plus the ascset control verbs (reboot, hashpower, setpool) — keep it on an isolated management VLAN, never on a WAN-facing interface.
• Expecting SSH. Gen 2 runs FreeRTOS on 8 MB of on-chip SRAM with no external DDR. There is no Linux, no shell, no rescue login.
• Flashing to chase a hashrate loss that is really a chip-chain break, a dead fan, or a failing PSU.
• Upgrading the whole rack in one sitting. Do one unit, confirm it hashes for an hour, then run batches of ten.

Related

• Step-by-Step Guide to Upgrading AvalonMiner Firmware — the single-unit, web-UI route.
• Mastering FMS for Optimal AvalonMiner Management — Canaan’s fleet-scale alternative to this tool.
• AvalonMiner Miner Log Technical Guidance Explained — reading what the unit says after it reboots.
• Avalon A11 & A12 Series Miner Disassembly Guide — when the fault turns out to be a hashboard.
• Start a Repair — when firmware is not the problem.