BMCU 370C firmware and the Bambu Lab firmware lock it cannot outrun

What the BMCU 370C board adds to a Bambu Lab printer

BMCU-C-PJARCZAK is the firmware for the BMCU 370C, a board built around Hall effect sensors that sits between a Bambu Lab printer and its filament supply. The repository description states the scope plainly: BMCU 370C Hall firmware for Bambu Lab A1, A1 mini and P1S, with buffer calibration, all known issues fixed, and behaviour that is compatible with the AMS multi-spool unit.

In practice the board is a filament buffer. The printer still does the printing, but the buffering hardware decouples the extruder from the spool feeding it, and the AMS is what turns that into a multi-material machine. The value proposition for someone already owning an A1 or A1 mini is being able to run more than four spools, and the firmware is what makes the board behave predictably enough to be trusted with that.

The implementation is C++ and the build is PlatformIO based, with platformio.ini at the top level, a src/ directory holding the code, and a build_all_firmwares.sh script for producing the various firmware images. The repository also carries a version file and four short text files whose names describe their purpose, which_to_choose_autoload.txt, which_to_choose_filament_rgb.txt, which_to_choose_mode.txt and which_to_choose_slots.txt. Those names suggest the firmware ships in different variants for auto loading, filament channel colour, operating mode and number of slots, and a buyer who wants a specific configuration needs to pick the matching build rather than the newest one.

The compatibility table is the real documentation

Most of what a buyer needs to know is in a single table listing each printer model, the printer firmware range and whether the BMCU works. The ranges are given as exact firmware version numbers, which makes the table usable as a lookup rather than as a general statement.

For the A1 and A1 mini, firmware from 01.05.00.00 to 01.07.02.00 works normally, with a visible HMS warning that does not affect printer operation in any way. From 01.08.00.00 the printer still works but sends a device compatibility error that blocks the project in the slicer. The documentation points to OrcaStudio as the remedy, and describes its behaviour precisely: it ignores the compatibility error, keeps the project usable and retries sending the interrupted print.

The P1P and P1S row is different in kind. Firmware up to and including 01.08.01.00 works normally, and the documentation names that version as the last before a new authorization mechanism arrived. The same boundary exists for the X1 and X1C, where 01.08.02.00 is the last working version.

Reading across those rows, the pattern is that Bambu Lab is adding a certification and authorization check to the printer, and the check applies to the buffer board, not just to the AMS. The repository links a separate document, bmcu-vs-firmware-locks.md, for the certification and authorization restrictions and for how printer updates changed BMCU compatibility.

The A1 error is a slicer block, the P1S error is a rejected board

Two different failures are described and they need different responses.

On the A1 and A1 mini from 01.08.00.00, the board works and the printer works, but the printer sends a device compatibility error that blocks the project in the slicer. The tip in the documentation is to use OrcaStudio, which ignores the error, does not block the project and retries sending the interrupted print. The printer must also be configured as AMS rather than AMS Lite, which the table repeats in bold for both A1 rows. This is a workflow fix: the hardware works, the printer refuses at the start of the job, and a different slicer path gets the job through.

On the P1P and P1S from 01.08.02.00, and on the X1 and X1C from 01.08.03.00, the failure is at the device level. The documentation says the first print works and can run for any length of time, and that on the next print the BMCU is rejected because it does not pass device certification or authorization. Before another print, the instruction is to reconnect or reset the BMCU, or restart the printer.

That second behaviour is worth dwelling on, because it is the kind of thing that reads as a broken board rather than a locked one. The buffer works once, and then has to be re-established by hand before the next job. A user who does not know the mechanism will assume the hardware has failed and start replacing parts.

Newer models where the buffer no longer prints at all

The P2S, H2D, X2D, H2S and A2L rows are where the project becomes a warning rather than a recommendation.

For the P2S at 01.01.03.00 and below, and the H2D at 01.02.00.00 and below, the first print works and can run for any length of time, but it is best to start the print shortly after the printer starts or the BMCU is reconnected, and before another print the board has to be reconnected or the printer restarted. From P2S firmware 01.02.00.00 and H2D firmware 01.03.00.00 upward, printing with the BMCU does not work at all. The description in the table is consistent: the board is detected, manual filament load and unload work normally, and then the printer stops at Preparing AMS because the required certification and authorization is not satisfied.

The X2D row is the sharpest warning in the document. At 01.00.01.00 the first print works and a restart or reconnect is needed before another. From 01.01.00.00 printing does not work, and the note is unambiguous: if you want to use the BMCU, do not update the printer, because there is currently no normal way to downgrade back to that firmware. That is a one-way door, and it is the single most important sentence for anyone deciding whether to buy the board.

The H2S row lists newer firmware as not working, with BMCU detected but printing not starting, and states that the exact last compatible printer firmware has not yet been confirmed. The A2L row is simply recorded as not working on all versions.

There is one workaround offered for the P2S and H2D rows: a simple switch that disconnects SigA and SigB at the same time, since switching both signal lines off and back on lets the BMCU reconnect to the bus without unplugging the printer from power.

Where the firmware comes from and how it is built

The download section of the documentation points to ready-to-use firmware hosted in the repository's release area, and the recent tags show a project that ships regularly: v11 from 2026-10-04, V10.5 from 2026-04-22 and V10.4 from 2026-03-31. The last push to the repository was on 2026-10-04, and the repository is not archived.

For anyone who wants to build rather than download, the pieces are in the repository root. The platformio.ini file carries the PlatformIO environment configuration, the src/ directory holds the firmware sources, and build_all_firmwares.sh is the script for producing the firmware images, which is what the name suggests it does. The version file records the version string.

The four which_to_choose files are the guide to which build to flash. They are named for the decision each one informs, so a user reads the file for their decision, picks a matching firmware variant, and flashes it. This is a sensible pattern for a board that has to be configured for a specific number of slots, a specific operating mode and a specific filament channel colour, and it is worth noting that the documentation is thin here: the files themselves carry the guidance, and the repository does not describe the flashing procedure, the wiring or the hardware inside the board.

The project also asks for support through Ko-fi and Revolut, and the top level of the repository carries only a .gitignore besides the sources, so the support links are the visible sign that this is a one-person hardware and firmware effort rather than a company project.

The wrong tool for a new printer, and the wrong trade for some buyers

The clearest case against this firmware is that it is a compatibility workaround for a moving target. Every printer firmware update can narrow the range in the table, and the project cannot control when Bambu Lab ships those updates. A buyer who reads only the repository description, which promises support for the A1, A1 mini and P1S, would not learn that the A1 range stops at 01.07.02.00 for normal operation, that the P1S stops at 01.08.01.00, or that a P1S on current firmware will reject the board on the second print.

There is also a licensing and support reality. The repository lists no licence, so the default copyright position applies and there is no stated grant for reuse or redistribution of the firmware, which is unusual for a project of this kind and worth settling before building anything commercial on it. Support is a personal request through a donation link rather than a support contract, and there is no issue tracker, documentation site or published changelog beyond the tags.

The alternative is the honest one. Anyone who needs multi-spool printing today and wants a guarantee should buy the vendor's own multi-material unit or a printer that ships with it, because the AMS compatibility that the buffer provides depends on the printer accepting a third party board, and that acceptance is now being withdrawn model by model. The BMCU is worth it for someone who already owns the printer, already has the board or plans to build it, and is prepared to track firmware versions. It is a poor purchase for someone starting out, and it is unusable on an A2L.

Editorial conclusion

Adopt BMCU-C-PJARCZAK if you have a BMCU 370C buffer and a printer whose firmware version is still in the working range for your model, and if you are willing to check the compatibility table before every printer firmware update. Do not adopt it for an A2L, an H2S on newer firmware, or any printer running a version in the blocked range, because the board is detected but the print never starts. Before you buy or flash anything, read the firmware version table for your exact model, note that an X2D update cannot be undone because there is no way to downgrade back, and decide whether the buffer's benefit is worth the risk that the next vendor firmware update removes interoperability entirely.

Frequently asked questions

Official sources

1. Issues
2. jarczakpawel/BMCU-C-PJARCZAK on GitHub
3. README
4. Releases