Unbricking A 3D Printer The Hard Way: By Writing a Bootloader

There’s a sinking feeling when a firmware upgrade to a piece of equipment goes wrong. We’ve all likely had this happen and  bricked a device or two. If we are lucky we can simply reapply the upgrade or revert to a previous version, and if we’re unlucky we have to dive into a serial debug port to save the device from the junk pile. But what happens when both those routes fail? If you are [Arko], you reverse-engineer the device and write your own bootloader for it.

The offending bricked object was a Monoprice MP Mini Delta 3D printer to which he was foolhardy enough to apply new firmware after seeing a friend’s machine taking it without issue. Finding the relevant debug interface on its main PCB he applied the firmware upgrade again, only to realise that in doing so he had overwritten its bootloader. The machine seemed doomed, but he wasn’t ready to give up.

What follows in his write-up is a detailed examination of the boot mechanism and memory map of an ARM Cortex M0 processor as found in the Monoprice’s STM32F070CB. We learn about vector tables for mapping important addresses of interrupts and execution points, and the mechanics of a bootloader in setting up the application it launches. This section is well worth a read on its own, even for those with no interest in bricked 3D printers.

In the end he had a working bootloader to which he appended the application firmware, but sadly when he powered up the printer there was still no joy. The problem was traced to the serial connection between the ARM doing the printer’s business and the ESP8266 running its display. After a brainstorm suggestion with a friend, a piece of code was found which would set the relevant registers to allow it to run at the correct speed.

So after a lot of work that resulted in this fascinating write-up, there was a working 3D printer. He suggests that mere mortals try asking Monoprice for a replacement model if it happens to their printers, but we’re extremely glad he persevered. Without it we would never have had this fascinating write-up, and would be the poorer without the learning experience.

This isn’t the first time we’ve brought you 3D printer bootloader trickery.

33 thoughts on “Unbricking A 3D Printer The Hard Way: By Writing a Bootloader

        1. Indeed.

          A good example is the various ‘Home Hubs’ supplied by BT Broadband as part of their ‘Infinity’ packages.

          Models 3-5 are physically identical with just a tiny line of text placed in the corner on the bottom label indicating the type, e.g. Home Hub 5 – Type A

          Internally, the hardware is about as different as you can get and the firmware is NOT compatible between types.

    1. He went so far as to buy a second printer to try and read the bootloader off, but the chip was write protected. Rookie mistake. The article is really worth reading, it starts out slow but gets much more interesting at the end. What is the magic word? 0xDEAD_BEEF

    2. “hey man I bricked my machine and then overwrote the bootloader. can I mess with yours for a bit to try to dump the boot loader?”

      I mean, I’d say “yes”, but I can’t imagine the situation would inspire confidence in most.

    3. There is also the question, how accessible that would have been. I know about CPUs which have so much code protection, that they are really bricked if you mess up the bootloader. Even the CPU manufacturer can not help you if you are a professional/commercial user of this CPU (use it in a series product).
      Obviously this was not the case here, but still the question if that would have been physically possible.

  1. Lolling at the comments so far, you guys just don’t “get it”, do you? I miss the days when HAD was nothing but articles like this. This guy’s got a wedding ring on his finger FFS and he’s still doing this shit for the fun of it. :D

    Respect, Arko. ;)

      1. True. But sometimes it’s just about the journey.

        I’ve just finished building a 3d printer and it’s got all sorts of problems that I need to sort out. I’ve already ripped the firmware and eeprom because I’m pretty sure I’ll be replacing it. My z-axis isn’t perfectly vertical, my print bed is a bit warped and I’ve got a horrible under-extrusion problem that I need to sort out. Sure, I could just fork out a few hundred bucks for a new kit and it’ll be all solved next week, but where’s the fun in that? Arko now knows a lot more about his machine than most of us ever will, and for me that’s well worth the extra effort.

        1. Sounds like an incentive for makers to not do their best work, and hide all the faults under, “learning experience”. Kind of like open-source and poor documentation, hiding under, “learning experience”.

          1. [quote]Poor documentation is more to do with the ‘Me Developer, Me Write Code’ attitude than any specific field.[/quote]

            I disagree. It’s more like a “Me Developer, Me Wants To Get Some Result, Me Don’t Know How I’ll Get There, But Me Know Me Will. Me Will Write Up Documentation When Me There.”.

            But there is never a ‘being there’, because the code can be improved almost indefinitely. And so there will never be documentation.

          2. There is a variant of the perfectionist:
            At first you want to get it running -> write documentation later
            Then you want to improve/perfect it -> write documentation later
            Then it is OK – and (almost) nobody likes writing documentation -> write documentation later or sometimes or perhaps never, e.g. because of a new interesting project
            I think that is the way it runs most times.

    1. Oh, it can be done. It’s rare nowadays, but it can be done.

      The reason is probably cost. A few pennies for a bigger flash chip, etc. might not seem much but it’s impossible to judge out of context.

  2. Kind of hard to believe that the printer is using a proprietary controller. Most 3D printers I have seen have a common RAMPS or other controller that should not require writing a custom boot loader. I am impressed by the tenacity of this fix though. I’m not sure I would have gone through all of that.

    1. Sadly, cheap Chinese-made printers often have closed-source proprietary controllers, as the manufacturers rightly fear any innovative or commercially successful designs being undercut/ripped off by other Chinese manufacturers of cheap printers.

      Although the cheapest controller boards available still run 8-bit AVR microcontrollers, that architecture is woefully inadequate for controlling delta printers like Arko has, and only manages to be barely adequate for cartesian printers like the Prusa I3 when the capabilities of the architecture are stretched to their limit and the feature set of the firmware is pared down to fit the limits of the electronics.

      8-bit AVR microcontrollers were never intended to be powerful enough to control something as involved as an entire 3d printer. They were designed to deal with small amounts of data, process it, ferry it on its way, and (mostly) forget about it as they fetch the next data. That’s what Klipper does: (https://hackaday.com/2017/12/26/fast-3d-printing-with-raspberry-pi-but-not-how-you-think/)

      … I won’t try to paraphrase David Crocker any further. He explained it well enough here: http://forums.reprap.org/read.php?13,791191,791271#msg-791271

      1. My experience with Chinese-made printers is that since they do what is easiest. It’s not that they were trying to protect themselves from others, it’s just that in the olden days this meant ripping schematics and firmware from other manufacturers, who DID do proprietary things. But these days it’s much easier to just duplicate open hardware and open-source software, which is what most of them do.

  3. Woo, STM32 chips!

    The F0 line is pretty modern and easy to get into – I highly recommend it if you’re looking into microcontrollers and are underwhelmed by what an 8-bit AVR chip can do.

  4. after seeing this same issue via another device of similar chipset I can offer some advice, use the manufacturers update tool and not write direct to the device, the tool will talk to the bootloader and then update the flash without erasing itself, writing direct to the flash like he did (0x800_000) and not (0x800_000)+bootloader which he did admit his folly. However in some cases even the OEM tool fails, I have a Samsung cpu based fingerprint reader that when updated via factory tool it will brick, same reason , it forgets to do FLASH+bootloader=start address of f/w, after getting 0% support from oem on this issue other than ‘send it back to china’ I rewrote the entire system, it was a great RE exercise from sourcing the CPU+docs to even speaking direct to the original Board OEM, end result is a custom uboot for the s3c44b0x sammy cpu and custom fingerprint software that works with generic software and hardware. for the curious , take a look https://github.com/darkspr1te/uboot-s3c44b0x-AST62XX , also even big oem’s fall to this issue(either the single Model with different internals issue or bad update strategy) which i documented over on xda, when the Samsung Note was release there was over 5 versions, some Qualcomm cpu’s some not, but all said they were Note 1’s in reality as mentioned above there were different Note 1 models, SGH-I717 against SHV-E160L. While this is not a issue if the oem tools always worked right but back when the note 1 was release the Samsung update had a major issue, when it checked a device it would download local firmware and not model specific, that ment that if you took a Korean Model note 1 to USA and ran the update it would use the SGH-I717 firmware and not the SHV-E160L firmware. Now technically the two devices are identical, both are qcom 8660 cpu’s with same flash layout etc, the difference was the SGH-I717 firmware did a security check which was not present on the korean model’s emmc with the SGH-I717 modle being a branded oem model , you can read here how I RE the bootloaders of both to figure this out then come up with a way of bypassing the emmc to boot elsewhere https://forum.xda-developers.com/showthread.php?t=1914359 . If the OEM really does their job right then updates are simple, if not then we have issues and bricks and much larger landfills. This is where open source wins, As one poster above mentions about his 3d-printer, out of the box it was not right but being open source he can alter it to work or suit his needs, I too have gone through this with a geeetech 3d prusa clone, sure i could have bought a closed source do it all device but one bad firmware or the OEM looses steam and does not keep up and we quickly have more e-waste.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.