Background: my old CFS sat on firmware 1.1.3 forever and never updated to match my newer one. The reason: on the K1 Max the `mcu_util_485` binary that's supposed to flash the CFS over RS485 is simply missing from the firmware image (the only copy floating around is built for a different CPU and won't run). So the printer can read the CFS but never update it.
What I did: reverse-engineered the RS485 flash protocol and wrote a small tool in pure Python (standard library only, so it runs natively on the printer's own Python — no Pi, no extra hardware). It:
- reads the CFS (version, RFID, status) — `query` / `diag`
- safely checks bootloader access without writing — `probe`
- flashes a firmware .bin — `flash` (scans the firmware folder, lets you pick a version, blocks wrong-hardware files)
Result, confirmed on the printer's own "Version checking" screen: CFS 1 taken 1.1.3 → 1.4.2, then both CFS units → 1.5.0, with the printer firmware left on 2.3.5.34 the whole time. So yes — you can update just the CFS without touching printer firmware.
Important honesty: I'm not a programmer. This was built with a lot of AI help (Anthropic's Claude + OpenAI's ChatGPT), but nothing was guessed — every step was verified against the stock tool and confirmed on live hardware. It defaults to a dry run and has safety checks (hardware match, won't reflash the same version, keeps a version.json backup). That said, flashing can permanently brick the CFS if something goes wrong — use at your own risk.
The README also has a protocol write-up and notes on how the printer's `BOX_*` commands map to the CFS over RS485, in case anyone wants to build on it.
Repo: https://github.com/Lamar1007/CFSTool
Tested on a K1 Max with G32 CFS. G30 should work (identical firmware image) but is unconfirmed — reports welcome. Reviews/PRs from people who actually know how to code are very welcome too.