MakerGear Forum

I'm not sure how many people out there are Linux users and tend to want to do everything from a terminal command line. But I am, and since there seems to be extraordinarily little documentation to be found on it, I thought I'd make a quick how-to on this.

First off, it is absolutely true that you CAN do firmware changes through a command-line interface. I was dismayed at the Arduino IDE and the apparent modus operandi that everything must be done through this GUI. I have an intense distate for GUIs, generally. This one is no exception.

Now, you will need the source code for the firmware. There are several pointers on the forum threads to various versions of the firmware. I have a 2012-vintage M2, with the split 12V/19V power supplies, so I got my version of the firmware from Ketil. Instructions are here, where I asked Ketil to be specific because I didn't know how to pull a specific branch off of a repository on github:

viewtopic.php?f=3&t=106&start=10#p2304

Once checked out, this distribution has a subdirectory Marlin/. cd to that subdirectory. There you will find a Makefile. The Makefile is full of apparently untouched default values, which indicates that the GUI method just bypasses it altogether. But assuming you want to build from the command line, this is what you want.

I modified the following lines like so:
Note that while you may not use the Arduino IDE GUI, you still need the Arduino IDE (latest stable revision, 1.0.5) because it contains the gcc cross-compiler for the AVR processor. So just point the paths ARDUINO_INSTALL_DIR and AVR_TOOLS_PATH to the installed Arduino IDE. The upload port of /dev/ttyACM0 is typical for Linux systems connecting to the Rambo.

I added BUILD_DIR = "build" just because that's far more typical than their default value of "applet". Regardless, you will need to create this directory ("mkdir build") because the Makefile doesn't try to detect its existance, and will not create it if it doesn't exist.

Now you should be able to just do "make", and it will all compile (fingers crossed). If that works, you get an executable
and a hex file:
Theoretically, you now connect the printer and do "make upload" and it works, using the command-line tool "avrdude". At this point, though, being the paranoid person I am, I want to see if I can pull the existing firmware off of the M2 and into a hex file where I can save it locally, as a backup, to be restored should anything go wrong. I have no wish to overwrite a perfectly good existing firmware with one that claims to be the same, having no proof of that assertion.

By dissecting the Makefile, I can pull out the command-line invocation for "avrdude", and replace the flash write command with a flash read command. The result is the following command to download the existing firmware as a hex format file (using "ARDUINO_INSTALL_DIR" from the Makefile):
Run this and you should get a file "build/Marlin_orig.hex" which is the existing firmware. Now I have greater faith that I can restore my M2 to its original condition at any time by uploading it with the same command as above, but with "r" replaced by "w" in the "-U" argument.

But. . . I can't help but notice that "build/Marlin_orig.hex" is nearly three times the size of the newly-compiled "build/Marlin.hex" (623kB vs. 215kB). So maybe I'm paranoid with good reason. I will investigate this disparity before continuing. (to be continued)

Maybe the read pulled the entire memory? Is the end of the file stuffed with nulls?

Hello Jin,

Hmm, yes, I should have thought of that. I looked at the top and the bottom of the file, but yes, most of the middle of it is blank. I'm not sure what data is sitting at the bottom of the last memory page in the data dump. Maybe its not relevant. If I discount that last block of random-looking data, then the two files are roughly equivalent size, with Ketil's being slightly larger, which makes sense since it's a more recent version of Marlin, and has a few additions to the source code.

The code at the end is the bootloader.

So, what happens to the bootloader if I upload the new firmware file? Does it get erased? Is it even erasable? I guess I will need to dig deeper to figure out the paging in the hex files (hex file format is so obscure. . .). At least I have a copy of the data. I think I have a good enough understanding of it that there is nothing I can do to my RAMBo that I can't recover from (famous last words).

Tim wrote:So, what happens to the bootloader if I upload the new firmware file? Does it get erased?

The bootloader lives in a separate, protected section of Flash ROM; it handles the back-and-forth required to load the Marlin (or whatever) program into the rest of the Flash. In theory, you can't blow the bootloader away during ordinary program loading, but reports in the Sailfish group suggest you can (on some known-flaky Makerbot hardware versions, not a RAMBo), which requires restoring the bootloader using another Arduino as a programmer connected to the ICSP header directly adjacent to the 2560.

If you haven't found it already, you'll eventually need the Atmel MCU doc: http://www.atmel.com/devices/ATMEGA2560.aspx

I answered my own question with a quick look over the Atmel ATmega2560 data sheet

http://www.atmel.com/Images/Atmel-2549- ... asheet.pdf

The bootloader space is protected by several software bits that can be set to prevent the bootloader from being accidentally overwritten by a firmware update. I have not tracked down these bits to see if they have been set, but I assume so.

I ripped off all of the downloaded flash memory dump except for the application program, and now I have a hex file of what was originally in the M2 (sans bootloader).

I then used "avrdude" from the command line to write Ketil's updated firmware:
And after it finished, the M2 came back on, and I started S3D and connected to it and it all seems to be working. So I understand the firmware update process now.

By the way, "make update" obnoxiously runs the whole compile process again and then fails to run "avrdude" because it is called without any path prefix. With a bit of tweaking, it could be made to work properly. But it's easier just to run "avrdude" from the command line.

And. . . Ed responded while I was writing this, so some of it is redundant.

Oh, and a big THANK YOU to Curtis Menard and Ketil and all the firmware authors and hackers.

If you ever need to reload the bootloader (unlikely), I recommend the USBTinyISP, which can be had for under $10 to your door from EBay.

Also, the source to the MakerGear stock firmware is available from the MakerGear wiki, so you shouldn't need to worry about being able to recover.

Oh, and just to address some more of the questions/points you raised:

Technically, the bootloader doesn't live in a separate portion of the flash, it just lives at the end of it. A segment of it can be configured to be the bootloader, and protected. If the Makerbot guys neglected to set the appropriate lock bits, then that would allow an overlong firmware to overwrite a part of the bootloader.

And regarding your IDE distaste, I, once, was like you, and preferred to bathe in the pale glow of amber monospaced characters at the Linux console. But I have been seduced away by Ease of Use. The Arduino IDE isn't even a particularly awful example of its kind, anyway; it only has six buttons. What makes it particularly awful is the built in editor, which thankfully can be ignored through a "use external editor" preference, which will let you edit in the One True Editor, EMACS, and reload on save. I make no guarantees for any apostates who may be tempted to use a different editor.