Flashing the Octopus

The Raspberry Pi is not the only computer in the G1. Three microcontrollers sit underneath it, each with its own firmware in its own flash memory, and none of them is touched by the Raspberry Pi’s SD card.

Only one of the three is yours to flash: the Octopus. It is written from its own microSD slot, and only when, after a software update, the dashboard reports it out of date. The other two are flashed at the factory and stay that way — what they are is further down.

Flash after an update, not to chase a fault

Reflashing is not a troubleshooting step, and doing it to make a symptom go away is how a working machine stops working.

Nearly every symptom that looks like bad board firmware — a board missing from STATUS, Lost communication with MCU, a dead heating zone — is a USB cable or a wrong serial: path, not the firmware. Go through Klipper MCU communication lost first, all of it.

---

When the Octopus needs flashing

Situation	Why
After a software update, the dashboard says mcu should be updated	The update moved the Raspberry Pi and left the board behind. No message, no flash. Usually the printer still prints in the meantime — see Updating the printer
Klipper will not start and reports the MCU protocol / version does not match the host	The host moved; the board did not
The board has been physically replaced with a blank one	New silicon, no firmware
Ginger support asks you to	—

Everything else — a board that disappears from STATUS, intermittent dropouts, a zone that stops heating — is a wiring, USB or configuration problem. Reflashing will not fix it and costs you a working board if it goes wrong.

---

Flashing the Octopus

The Octopus is not written over its USB link. It is flashed from its own microSD slot: you put firmware.bin on a card, power the board, and the bootloader takes it. Nothing is sent from the Raspberry Pi.

The slot is behind the cable loom

The microSD slot sits on the top edge of the board, next to the Type-C port, and on the G1 it is obstructed by the cable bundle running over it. Easing those cables aside is the awkward part of this job.

Machine unplugged at the wall while you work in there.

1. Get the firmware. Download Ginger’s build — this is the binary used in production, so you do not have to compile anything:

   firmware.bin — Ginger’s build of 9 September 2026, 44,660 bytes

   SHA-256 faef9001c45bc68969589a7145114a4925ef534d43eae46708add4ec7fed88c0, if you want to check what you downloaded is what was published. It is built from klipper4pellet commit c5a092b; the board reports its version after flashing

   Keep the name exactly as it downloads. The bootloader looks for firmware.bin and ignores anything else

2. Put it on the card. Format a microSD FAT32 and copy firmware.bin across on its own — one file, nothing else

   A spare card, not the Raspberry Pi’s: formatting that one erases G1OS

3. Insert and power. Ease the cable loom aside, put the card in the slot, and power the printer for a few seconds. The bootloader reads the card and writes the firmware

4. Check the card. Power off, remove it and look at it on your computer. firmware.bin should be gone — renamed, typically to FIRMWARE.CUR. That is the confirmation it was flashed; if the file is still sitting there untouched, nothing happened

5. Verify on the machine. Power up and run STATUS in the console: mcu should be connected and the version mismatch error gone

The card is a tool, not a consumable

Ginger flashes machines in production from one dedicated SD card reused from printer to printer. Once it is formatted, it stays the flashing card.

Klipper lists this board as “should be updated”

The dashboard may show

MCU(s) which should be updated:
  mcu: Current version v0.12.0-141-g6f16e111

That line is only a comparison between the board’s version and the host’s. It is printed as context alongside whatever the real error was — it is not itself a fault. It means the board’s firmware does not match the Klipper version on the Raspberry Pi: flash the current firmware.bin to bring them in line, and the line goes away. Usually the printer still prints in the meantime.

The actual problem is always the last line of the message. If that line names extruder_board, the cause is the USB cable from the Raspberry Pi or its serial: line in printer.cfg — see Klipper MCU communication lost.

If the file does not disappear

The card was never read. In order of likelihood: not FAT32, more than one file on it, the card is too large or too new for the bootloader, or the board has no bootloader.

For that last case — a new or bricked board — contact Ginger Additive support.

The three boards

The panel box holds two Ginger boards and one BigTreeTech board. The two Ginger ones are named on the assembly drawings as Ginger.Extruder and Ginger.Feeding — and the answer to the obvious question is yes:

Both Ginger boards carry the same Arduino

The extruder board and the feeder board are both an Arduino Nano-compatible board (ATmega328P). Same part, same footprint.

What differs is everything above the hardware — the firmware, and whether the Raspberry Pi can see it at all. Neither Nano is ever reflashed.

	Octopus	Ginger.Extruder	Ginger.Feeding
Klipper calls it	[mcu] — the main one	[mcu extruder_board]	nothing — Klipper does not know it exists
Board	BigTreeTech Octopus Pro v1.1	Ginger PCB + Arduino Nano-compatible	Ginger PCB + Arduino Nano-compatible
MCU	STM32H723	ATmega328P	ATmega328P
Firmware	klipper4pellet	klipper4pellet, AVR build	G1-AutoFeeding — not Klipper
Drives	Motion, all four NTC thermistors, bed heater output	3 zone heater relays (and the 220 V through them), probe servo, part fan, feeder switch, buzzer	Vacuum relay, hopper level probe, buzzer, LED
Where	Panel box	Panel box	Panel box
Link to the Pi	USB (USB_2)	USB (USB_1)	None
Flashed	From its own microSD slot — the procedure above	At the factory — never reflashed	At the factory — never reflashed

The feeder board has no cable to the Raspberry Pi

This is not an oversight, it is the design. The panel box cable list runs USB from the Octopus and from Ginger.Extruder to the Pi, and nothing at all from Ginger.Feeding. The two Ginger boards instead talk to each other directly, over a short JST-HX link labelled GCOM — which is how the FEEDER toggle in Klipper reaches a board Klipper cannot address.

So the feeder board keeps running the vacuum whether Klipper is up, updating, or dead, and nothing in Mainsail can see it, update it, or report on it.

How to tell the two Klipper MCUs apart in printer.cfg: the Octopus reports as usb-Klipper_stm32h723xx_…, the extruder_board as usb-1a86_… — 1a86 is the CH340 USB-serial chip on the Nano, not Klipper’s own identifier.

Why the Update Manager does not do this

This is the point that catches people out.

Machine → Update Manager updates the Raspberry Pi. It does not flash any board. Pressing UPDATE on the klipper row replaces the Klipper host software on the Pi. The Octopus keeps the firmware it already has, which is why, when the dashboard reports it out of date, it is flashed by hand.

Nor does flashing the SD card. A brand-new card boots and talks to boards still running whatever they were flashed with — see G1OS installation.

That separation is normally invisible, because Ginger’s Klipper version deliberately trails upstream and does not change often. It becomes visible in exactly one way: a host Klipper update that crosses a protocol change, after which Klipper refuses to start and says the MCU firmware is out of date.

Update everything, then come back here

Updating the host is not flashing a board, which is the whole point of this page. Take the software update first — Updating the printer — and come back here only if the dashboard then reports the Octopus out of date.

---

The other two boards

Both Ginger boards are flashed at the factory and are never reflashed. There is no procedure for either, and nothing in normal use or in a fault asks for one.

The panel box carries mains

The Ginger.Extruder board passes 220 V to the three heater bands. Unplug the machine at the wall before opening the box, and do not touch anything beyond the Octopus SD slot — see Heater band.

Extruder board (extruder_board)

An Arduino Nano-compatible board running Klipper, connected to the Raspberry Pi over USB. If Klipper loses it, the firmware is not the cause: it is the USB cable from the Raspberry Pi, or the board’s serial: line in printer.cfg — see Klipper MCU communication lost.

Feeder board (Ginger.Feeding)

An Arduino Nano-compatible board running G1-AutoFeeding, not Klipper, and not part of any Klipper update. It has no cable to the Raspberry Pi at all.

Its behaviour is five pins and a handful of constants compiled into the sketch: the vacuum relay, the run LED, the hopper level probe, the FEEDER enable arriving from Ginger.Extruder over GCOM, and the buzzer. That is why the feeding timings cannot be changed from Mainsail, the display or printer.cfg — they are in the firmware. The timings themselves are in the auto feeding firmware.

If the feeding cycle needs to behave differently, contact Ginger Additive support.

Related notes

• Klipper MCU communication lost — do this first, it is nearly always the answer
• Extruder board (extruder_board MCU)
• Automatic feeding system — what the feeder board does
• Updating the printer — the host updates, which are not this
• G1OS installation — flashing the SD card, which is also not this
• SSH access
• Panel Box wiring