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.
I wonder couldn’t he have just copied the bootloader from the friends machine?
If it was different enough that the firmware images weren’t compatible, then I’d say the bootloaders weren’t either.
Ah, yeah, makes perfect sense.
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.
The STM32 will have read protection enabled.
you know it. pita
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
“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.
“Sure, if you place some cash on the table upfront to buy me a new one, if you brick mine.” :-)
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.
hmmm or you could just buy / build open devices… ?
He could even have just replaced the controller board with a chinesium one, for about $35.
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. ;)
Indeed… the time spent here would have been much less than the time needed to ship a new printer.
For sure there might be better options out there; but sometimes it’s the devil you know vs the devil you don’t.
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.
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”.
But without Open Source, we’d live in a world where we couldn’t see the bad code!
heh.
Poor documentation is more to do with the ‘Me Developer, Me Write Code’ attitude than any specific field.
[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.
Ah yes. The Perfectionist ™.
Unfortunately nothing’s ever perfect, so nothing ever gets finished…
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.
A POS printer that a ton of people own. He can now service a niche market of people who cannot or are not willing to do this kind of thing on their own.
One would think printer makers would borrow a page from MB makers. Been awhile since a bad upgrade bricked a MB.
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.
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.
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
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.
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.
Nice work with the reverse engineering. It never fails to amaze me what happens when a good question is asked on IRC.
What a great read! I just shake my head at that HackadayHaters. These are the best articles on Hackday.
I agree, this was a great read.
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.
This hack or something similar should also apply to the Monoprice Select Mini 3D printer. It uses a STM32 control board that is very similar. Hopefully, tackling the closed bootloader allows custom firmware for these printers to be written now.
Hello, can anyone have a some success with firmware like this but for MP Select Mini because the motion board is with different STM32 chip with smaller size. Can anybody help with this issue?