Fixing a failed 3D printer controller board

The Problem

My son recently got a 3D printer from Printrbot and has been doing some interesting things with it; however, we started to see some odd behavior after adding an LCD display and so decided to update the firmware on the printer controller. Unfortunately, while following the steps for this, we got a screen from the Atmel Flip application, showing the message "Blank check fail at 0x00000":

We contacted Printrbot support and were told:

"The Blank Check Fail is, basically, the kiss of death for these boards and the only option is to buy a new Printrboard."

Before spending $100 for a new board, I decided it was worth some more investigation to see if I could fix the existing board myself.

What I Found

Several Google searches led to various postings I found helpful at:

• Lincomatic's Blog: http://blog.lincomatic.com/?p=502
• Printrbottalk: http://www.printrbottalk.com/forum/viewtopic.php?f=19&t=2928
• RepRap: http://reprap.org/wiki/Printrboard#Bootloaders

It seems that the "Blank check fail" message can be caused by corruption of the firmware on the Printrboard, specifically a section that provides read/write protection of the code (i.e., the "lock bits"). If these are enabled, it is not possible for the Flip firmware updater to erase the flash memory (causing blank check to fail) and re-write new code to the board (causing verify to fail). What leads to this corruption is not clear:

• I have had the code fail to reboot after initiating an "Emergency Stop" from Repetier or after killing power to abort operation during a head crash.
• Some users reported it happening during a firmware update with the printer's Y-stop switch activated. 
• Our most recent failure came after trying to use the LCD controller to initiate a print by reading a gcode file off an SD card and pulling the power cord when the display went haywire.

Unfortunately, clearing the lock bits is not something that can be done from Flip; instead, direct access using an AVR programmer is required.

Why do we need an AVR Programmer?

The Printrbot Simple Metal (Model 1403) that my son bought as a kit in April 2014 uses a Rev D Printrboard controller (images are from the Printrbot Store):

The board is a Teensylu derivative that uses an Atmel AVR MCU chip: AT90USB1286. 
This device features:

• 128 Kbytes flash program memory
• 8 Kbytes SRAM data memory
• 4 Kbytes EEPROM data memory

[Note: the AT90USB1287 chip has additional USB "OTG" functionality that allows it to function either as a host or a client.] 

The chip's flash program memory is divided into two sections:

• Application Program (the printer firmware, programmed by user)
• Boot Program (the USB bootloader, programmed at the factory, used to update the firmware)

The Printrboard has a jumper that determines which program section runs on power up or on board reset; on our Rev D board:

• Jumper removed: Printer application runs
• Jumper installed: Boot loader runs

Each section also has dedicated "lock bits" for write and read/write protection. These bits are *not* accessible from the Application or Boot programs, but *can* be updated via JTAG or through the board's 6-pin ISP (In-Service Programming) header, using the SPI (Serial Peripheral Interface) bus. 

An AVR programmer that interfaces to this ISP header should allow us to

• Check and change the state of the lock bits.
• Update the Boot loader program to a factory-fresh state so we can reload the printer firmware.
• Optionally install an alternate boot loader that provides different functionality.

In my next post, I'll write about building and configuring a low-cost programmer that we will use to try and fix the failed Printrboard.