AVR Bootloader and new MCU for the Huxley

posted 13 Jul 2013, 15:09 by Colin Bell   [ updated 13 Jul 2013, 15:09 ]

In preparation for the LCD control panel I'm about to build for the Huxley, I knew I needed to upgrade the printers microcontroller (MCU) brain from the venerable ATMega644P to the ATMega1284P. The 1284P offers several advantages and enhancements over the 644p, the main one being 128k of flash memory vs the 644P's 64k. This is essential as the Sprinter firmware used on the Huxley uses pretty much the entire store of memory, and upgrading to the more modern Marlin firmware which allows goodies like LCD control are simply too big for the 644p. 

The 1284p is available in the same 40 pin DIP package making it physically drop in compatible on the  Sanguinololu control board.
So, as I said above, the chip is drop in pin compatible, however offers several challenges to get it working properly. The first issue you'll hit is that unless you specifically bought a 1284p with a bootloader pre-installed, you'll likely get a virgin blank chip. 
A bootloader is a concept which will be familiar to anybody who's got any previous experience with either MCU control systems (including PCs). For those of you that are not, I'll try to explain a bit about it here.

Basically, the MCU's memory is split into two separate areas (vast over simplification!) which consist of a small protected bootloader area, and the remainder left free for the application area (where the firmware for the printer lives). The function of the bootloader is to allow the user to program the application area of the available memory via ISP (in-system-programming). There are many standards for this process including SPI/ISP and JTAG which are the most common for 8-bit MCUs such as these. The bootloader only needs to be loaded once on the chip, and then it will allow the user to upload the application specific code into it using one of the aforementioned in system programming interfaces. 

The standard way to get a bootloader on a virgin MCU is to use something like the USBTiny ISP programmer that I built earlier this year. While this does the job admirably on the 644p and other MCUs with 64k or less flash on it, that is it's limit, so the 128k of the 1284p is outside of it's capabilities. Bummer.
Now the Sanguinololu board has an SPI/ISP programming port on it already - normally this is hidden under the SD daughter card reader. This provides a nice ready made host for programming the 1284p bootloader, however one still requires a proper AVR programmer in order to write it. Seeing as the USBTiny was out for this one, I turned to the breadboard and my supply of Arduino's to do the job.

The board I selected was the Arduino Mega 2560, which seemed beefy enough to do the job. One of the example sketches I'd noticed on the Arduino IDE was called ArduinoISP, which sounded like it would do the job.

The sketch talked about a hooking up LEDs and resistors etc, so I broke out the breadboard and a quick Google search led me to an excellent reference on Instructables. Using this, and also referencing information from the RepRapWiki I built up the simple circuit and connected it up to the Sanginololu hosting the 1284p. The Sanguinololu board uses a standard 6-pin dual row header for SPI/ISP so I just used the one from the USBTiny and plugged patch leads straight into it.

Amazingly, the bootloader installed first time - no issues. Once the process completed, I disconnected and hooked up the Sanguino by USB as normal and flashed Marlin onto it without any problems.

There are a few gotcha's in this process if you are attempting it for yourself, for one, fuses (crap name for variables as far as I can tell...). I found some good explanations from a guy who was basically doing the same job as me in this example, however we had slightly different configurations so I didn't get the pain he did - he did an excellent job explaining though, and so as not to lose the references for later, here's a link to his blog if you get problems. I wish I'd found his blog entry before I started though, as it probably would have saved me an hour or so's head scratching over configuring the boards.txt file for Arduino IDE, which needed to be updated to allow the 1284p to work.


Sanguinololu/1284p Arduino IDE files:            https://github.com/jmgiacalone/sanguino1284p
Arduino IDE (I used 1.0.4 here):                        http://arduino.cc/en/Main/Software
DCG Tek:                                                          http://dcgtek.blogspot.ru/2013/05/installing-bootloader-on-sanguinololu.html

Now Marlin is installed, I also grabbed the latest version of Pronterface from Reprappro which works with Slic3r instead of Skeinforge for it's slicing engine - I've had limited success with this in the past, but hopefully with the new Marlin firmware, I'll see better results. Other than a printer control test, I haven't really printed anything seriously yet with it, as the immediate aim is to get the new LCD and controller fitted so that the Huxley can be used independently of the PC. Once that's done, I'll go back into fine tuning mode and try and get the print quality up to at least that of Sprinter and Skeinforge. 

I saw two issues with the control test - both configuration issues with Marlin. The first was that the motors were running in reverse on the X/Y axis, which I remember is a peculiarity of the Huxley design - this is a simple change in the Configuration.h file:

//#define AXES_MAX_LENGTHS {155, 150, 90}
#define AXES_MAX_LENGTHS {140, 140, 85}
#define INVERT_X_DIR true    // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false    // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR false     // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR true   // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR true    // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR true   // for direct drive extruder v9 set to true, for geared extruder set to false

You can also see there that I tailored the axis maximum lengths there for the Huxley.

The second issue was that the heated bed wasn't responding. The configuration entry for this lives in Pins.h, and for my machine simply needed to be changed to pin 12. There are several mentions of the heated bed pin setting in the file, so I actually ended up doing a find/replace for all of them in Pins.h as I didn't get any luck with my first try. Clearly one of them did the trick though as it now heats up normally.

  #define HEATER_BED_PIN     12 // bed (change to 10 for gate pin of MOSFET on heated bed)
  #define HEATER_BED_PIN     12

In the end, I setup my original Sprinter config and the new Marlin one side by side, and did comparisons for all the major control parameters - just to be sure, and also to familiarise myself with the code - it's quite different in Marlin and consists of several additional .h pages for additional functionality. In particular I wanted to ensure that my e-steps per mm settings transferred across. Although I'll probably end up re calibrating before any serious printing, at least it gives me a starting point.

Just in case you're interested, my e-steps per mm settings are:

#define DEFAULT_AXIS_STEPS_PER_UNIT   {91.4286, 91.4286,4000,875}

...but please bear in mind that these are very machine specific, and likely won't help you configure your machine!

Next step is assembling the Panelolu LCD control unit, supplied from my friends at Think3DPrint3D.