Ender Updated
Mar 29, 2026
3d printing
ender
marlin
updates
firmware
bigtreetech
When I got a 3D printer I swore I would not be one of those people who spent all their time printing upgrades for their 3D printer. I’m not doing too badly, but printing with the Ender 3 is nonetheless a bit of a self-referential hobby.
Mine has recently been failing to print cleanly and I’ve been putting off the investigation - this weekend was time to dig in and fix it.
TL;DR New hot end needed and solved the problem, but other incidental failures required workarounds.
The problem and the solution
There are clear signs of under-extrusion in the prints. They start out ok, but then I end up with whispy barely-present material and the telltale clicking sound as the extruder fails to push any PLA into the head. A bit of poking around and I could see the print head was clogging. Various attempts to fix that directly didn’t really work. I’d clear it and it would clog again. Slap on a new brass nozzle and again, it would work briefly and then clog again. A few other attempts and I decided to slap on a completely new hot end. Suspecting something along these lines I’d ordered and received a spare, so a bit of dismantling and reassembly and things were looking good.
Not so fast
While the first few layers proceeded perfectly with no under-extrusion, I suddenly got a thermal runaway error (very loud beep). Naturally I assumed the new hot end was the problem somehow. I spent a bunch of time verifying that the thermistor in the new hot end was in good shape. Eventually I realised that the bed wasn’t heating - and the thermal runaway warning was caused by the failure to see a temperature rise.
I presume the logic here is that if the bed thermistor fails and the firmware keeps on heating the bed waiting to see a temperature rise, then you could accidentally bring the real bed temperature up to something that’s a fire hazard. Reasonable. Whereas the “real” problem is a completely lack of any thermal change whatsoever. Slightly confusing when diagnosing this one.
Anyway, poking around with the multimeter I realised that the output for the heated bed was completely dead. More poking with the multimeter and it looked like everything was dead powering that pin (PC9) on my “BIGTREETECH SKR Mini E3 V2” board. On the plain Jane version of the Ender 3 that pin is actually hooked up to a MOSFET and delivers a higher voltage and power directly to the bed. On my extended Ender 3 however, it just drives a relay that in turn delivers AC power to the (much larger) heated bed. If I was still on the old device I’d either have to diagnose and fix whatever component had died on the board, or replace the board. I’m too lazy (and probably not competent) for the board fix, so I was intending to replace the board, but then I realised I had another option.
Because the heated bed is powered via the relay, the pin driving the relay doesn’t need to deliver a lot of power to it directly. In fact the relay accepts anything from 3V to 24V as its input. This meant that I could use another pin on my mainboard - and there are a bunch of them that I’m not using.
- Pro: I don’t need to wait for a new mainboard to arrive or spend money on it
- Con: I’ll need to rebuild Marlin (the firmware) with the necessary changes
That’s not a bad con - I already know how to rebuild and install Marlin so this should be easy.
Nothing is ever easy
Cutting to the chase, yes, this worked. Eventually.
Issues at hand though:
- I had to change the configuration
- The firmware wouldn’t build
- The firmware, when built, wouldn’t install
Hey ho.
Changing the configuration
This was actually the easy bit. I don’t think I made this change the “right way” but it was effective, and I’m not planning on pushing my idiosyncratic changes anywhere else.
I changed the Marlin/src/pins/stm32f1/pins_BTT_SKR_MINI_E3_common.h file so that it defined HEATER_BED_PIN
as PC13 instead of PC9. On the E3 V2.0 pin PC13 is normally a line that can be used to drive a relay that will
shut down power to the printer when a print job is complete (i.e. turn it off!) I wasn’t using it at all, so
this is perfect for my purposes.
In the unlikely event that someone else is in the same circumstances as me, my branch base is commit 7e700c13948506ab0fc57719c7c1bd35f0cb33c4
and this is my patch against that branch. The usual caveats apply there, my offsets
for the print head (at least) will be different to yours, but if you have an Ender 3 with a BLTouch and you have
it all wired up to the E3 V2.0 in the same way then this might be a useful starting point.
I wired my relay into the pins labelled PS-ON (“Power Supply On”) instead of the one labelled HB (“Heated Bed”),
which requires a little plug instead of the screw-down connector. Happily I have spares of those plugs, but I know
a du-pont connector will work at a pinch. Polarity didn’t really matter here as I was driving a relay.
It worked just fine after a couple of stumbling blocks.
New firmware
At some point since I last documented it I seem to have upgraded my mainboard and also
upgraded the version of Marlin I was running against. I’m now on the Bigtreetech SKR E3 V2.0 hardware where I was at
some point on the E3 V1.2, and in Marlin the 2.1.x branch instead of 2.0.x and with my own patches applied.
There were two issues here - one is that something about the platformio build had got out of date or out of sync. When I ran the command I jotted down last time, I got an error telling me that the platformio module didn’t exist. The fix for this was to re-install platformio:
curl -fsSL -o get-platformio.py https://raw.githubusercontent.com/platformio/platformio-core-installer/master/get-platformio.py
python3 get-platformio.py
That got me a working build tool. Then the command I’d documented before the board ugprade failed. The build tool was smart enough to know that the configured board type (in my 2.1.x config file) wasn’t a match for the target I’d given it. Happily the error message did list the valid targets, and so I could see that the correct command (and this built a firmware happily) was:
platformio run -e STM32F103RE_btt
The resulting binary is dropped under .pio/build/STM32F103RE_btt/firmware.bin and then needs to be copied to
an SD Card for installation. Simple, right?
Old SD Card
Copying the new firmware onto the old SD card failed, and the SD Card was kind of dead. I could do a directory listing, but I couldn’t copy files to or from it. Probably leaving it in the printer for a few hundred power cycles wasn’t so smart. I always drive everything from Octoprint, so I don’t actually need an SD Card in the printer except when I’m doing a firmware upgrade like this. I dug out a replacement SD Card.
Then I got stuck with being unable to get the printer to install its firmware from the replacement SD card. I figured initially that I had the wrong filesystem, but after trying exFAT, FAT32, and FAT16, with various partitions of various sizes, I realised it was actually the (working, known good) card that was the problem. This card is labelled “Micro SD XC I” and when I swapped it for yet another card labelled “Micro SD HC I” it worked fine. I’m guessing the Marlin firmware (at least at the point in 2.1.x that I’m working with) doesn’t support some of the newer Micro SD card formats. If that is a newer format. I have no idea.
Anyway, with a card that works the firmware should be copied as firmware.bin to the root of the card, inserted into
the unpowered printer, and then the printer will install the firmware on boot. It flashes an LED on the board while
doing so, the boot process will take about twice as long as usual, and once booted it should say “Updated Settings” in
the info line at the bottom of the display. I also have a custom default message in the firmware that goes there
on subsequent boots which I change every time I crate a new firmware - this makes it easy to double check that the
install has actually worked. After a successful installation the file will have been renamed on the card to
firmware.cur as well.
This finally ran ok, and my next attempt to heat the bed worked absolutely fine. Success! I can print again!
Afterthoughts
I do wonder if effectively shorting the HB pins (albeit through a relay) is what caused the death of those pins on
the board, as this is not how they’re intended to be used. I’m optimistic that using PC13 will be ok if so,
because those pins are intended to drive a relay! Although it looks like Bigtreetech have a dedicated daughterboard
for that, so perhaps not? Oh well, the PC9 pins lasted quite a while, I expect it will be fine.
I might order a spare board in case it isn’t though.