Trouble updating firmware on Extruder Controller 2.2 on a Cupcake (2 yrs old, newly built)

[bob newman]

Hi,

I have a Cupcake, shipped in June 2010 but only just assembled. It
connects happily to ReplicatorG 0034, moves x,y, and z, identifies the
toolhead and it's driver version, extrudes plastic, etc. Motherboard
firmware updates nicely to v3.0. Extruder firmware does not. I write
now only after extensive work on this. Any guidance is appreciated.

Notable facts:
-- I'm running ReplicatorG 0034 on a Windows 7 system
-- Yes, when updating extruder firmware, I have indeed connected the
USB-Serial cable to the 6-pin header just below the thermistor screw
terminals
-- In ReplicatorG - Machine - Upload New Firmware - Select the board
to upgrade, I choose "Extruder Controller v.2.x (Gen 3)", and Version
3.0 w/o relays. (I've also tried several earlier firmware versions,
in hopes that the problem was only with 3.0 -- no success).
-- I select the same Com port (4) that Replicator G happily uses to
talk to the motherboard
-- When I press upload, the system thinks for about 25 seconds, as if
trying to convince me it is working at the job. Then an error box
appears, titled "Upload Failed", and saying "The firmware update did
not succeed. Check the console for details. You can click the
'upload' button to try again.
-- I have tried many combinations of actions, including pushing or not
pushing the reset button on the extruder controller board, with
various timings.

I noted in the Makerbot wiki various discussion of similar problems by
people a couple of years back (that is, those folks who built their
machines promptly, instead of letting them sit half-built and untested
like me). Among the information I came across was http://wiki.makerbot.com/ec22,
describing how to upload a new bootloader for the extruder
controller. So I bought and built a USBtinyISP programmer, got the
Arduino software, and burned the updated bootloader, no problems.
Arduino test programs, such as the little LED "Blink" program, upload
and run just fine. These uploads go well using the same cable,
attached to the same connectors, as ReplicatorG likes to use. Still,
ReplicatorG won't succeed with firmware updates.

I found a nice discussion in this group, "Extruder Firmware Woes" from
TeamTeamUSA, and lots of helpful replies. Based on that I tried
what's discussed in the following quoted text:

Begin quote:
"Zach made this page that describes how to burn the bootloader and
upload the firmware in one go via the USBtinyISP header:

http://wiki.makerbot.com/burn-custom-firmware-using-arduino

You can get all the files via svn:

svn co http://svn.makerbot.com/trunk/firmware/ makerbot-bootloader
+firmware-read-only"
End quote.

So I went to github and pulled out of the histories a couple of
different EC firmware files, with titles such as dist/ECv2.2/
PRODUCTION.hex (see, for example,
https://github.com/makerbot/G3Firmware/commit/abed5afbe83083f7757c7b0deb620d806edf9abe#diff-5)
These appear to be files containing combined bootloader and firmware,
each for a different version of the firmware as things changed over
time.

You have to trick Arduino 1.0 to convince it to burn these onto the
board, but it can be done by re-titling the file as
"ATmegaBOOT_168_diecimila.hex" and placing it in the Hardware\Arduino
\Bootloaders\Atmega directory, where Arduino 1.0 will look for the
bootloader to upload and burn via the USBtinyISP programmer. (The
extruder controller is basically a 168 Diecimila Arduino board, with
some other stuff added to it, so when you are using Arduino 1.0 to
talk to the board, that's the board type you select.)

All that works fine, and when Replicator0034 afterwards connects to
the motherboard, it finds the toolhead and reports the driver version
number. The control panel recognizes the extruder controller, and
reports extruder temperature. (This temperature is wildly and
variously wrong, seeming to vary depending on the driver version
(255C, 1024C) despite an extruder at room temperature. Maybe that
reflects thermocouple characteristics input at compile time. These
discrepancies have stopped me from running a full extruder test or a
print test.)

But still, with each of these nice combined bootloader/firmware
packages successfully loaded, when I then try to use ReplicatorG 0034
to upgrade the firmware the normal way, with the very same cable
configuration that allows Arduino 1.0 to successfully upload it's
little "Blink" example, I get no success, only the error discussed
above.

So in the end, I'm stuck. Can anyone tell me how to fix it so that
ReplicatorG will update the extruder controller firmware?

In theory, I could go to the source code for the extruder controller
software (which I think I see some of on Github, but I'm pretty
unfamiliar with the modern world of open source software, so I'm
easily confused about what I'm looking at). I'm reluctant to mess
with the source code anyway, because I don't know the languages
involved (I'm not really a programmer, and I'm very old school, with
only SCHEME, BASIC, PASCAL, 6809 and Z80 assembly language, and a few
words of broken Python).

I welcome any suggestions, and thank you for your time.

[Jetty]

If you set the log level in RepG preferences (of the top of my head I
think it was to "Debug"), then it will spit out the avrdude command
it's using to do the upload, and the error when it's failing. That
error should provide a good idea as to what's wrong, if you post it
here.

By default all it says is upload failed, and there are a number of
reasons it can fail.

[bob newman]

Thank you, Jetty.

I was sadly ignorant of the logging function. I'm trying it now.
I'll spend some time, maybe a couple of days, seeing what I can learn
from the results, then post again if I need to.

Regards,
Bob

[bob newman]

My failure to upload firmware to my extruder controller v2.2
continues.

I have now gone a number of rounds with the logging function turned on
(Preferences, Advanced, Debugging Level: ALL), but I am not much
wiser. What I did was to start RepG (which generates a bunch of log
data), then wait a couple of minutes without doing anything, so that
the time stamps would show clearly which log data resulted from my
attempt to upload the firmware. I did this with a successful firmware
upload to the motherboard, with a failed firmware upload to the
extruder controller v2.2 without pushing the reset button, and with a
failed firmware upload to the extruder controller WITH pushing the
reset button a moment before hitting the "upload" button in RepG.
Then I extracted the lines of the log with the relevant time stamps.
There is not a lot of difference between the different logs. Other
than the time stamp differences, the only difference between
succeeding with the motherboard and failing with the extruder
controller is that the motherboard log ends with the following
additional lines not found in the exruder controller log, whether the
reset button is pushed on the extruder controller or not:

May 2, 2012 11:27:08 PM replicatorg.uploader.AvrdudeUploader
setManualreset
FINE: Manual reset = true

The logs of the failed attempts to upload to the extruder controller
do not mention Avrdude at all, as far as I can see. So I have not
figured out how I might learn the Avrdude error that's occurring.

Any advice is welcome. I have included, below, the lines of log data
resulting from my upgrade attempts.

Regards,
Bob Newman




Successful upload of firmware to motherboard:

May 2, 2012 11:27:03 PM replicatorg.app.util.serial.Serial
scanSerialNames
FINE: RXTX VersionRXTX-2.1-7
May 2, 2012 11:27:08 PM replicatorg.machine.MachineThread run
FINE: MachineThread interrupted, terminating.
May 2, 2012 11:27:08 PM replicatorg.drivers.DriverBaseImplementation
dispose
FINE: Disposing of driver Sanguino3G
May 2, 2012 11:27:08 PM replicatorg.drivers.DriverBaseImplementation
dispose
FINE: Disposing of driver null
M ay 2, 2012 11:27:08 PM replicatorg.machine.MachineThread
$AssessStatusThread run
FINE: taking assess status thread down
May 2, 2012 11:27:08 PM replicatorg.uploader.AvrdudeUploader
setManualreset
FINE: Manual reset = true


Unsuccessful upload of firmware to Extruder Controller, without
pushing reset button:

May 2, 2012 11:38:07 PM replicatorg.app.util.serial.Serial
scanSerialNames
FINE: RXTX VersionRXTX-2.1-7
May 2, 2012 11:38:11 PM replicatorg.machine.MachineThread run
FINE: MachineThread interrupted, terminating.
May 2, 2012 11:38:11 PM replicatorg.drivers.DriverBaseImplementation
dispose
FINE: Disposing of driver Sanguino3G
May 2, 2012 11:38:11 PM replicatorg.drivers.DriverBaseImplementation
dispose
FINE: Disposing of driver null
May 2, 2012 11:38:11 PM replicatorg.machine.MachineThread
$AssessStatusThread run
FINE: taking assess status thread down


Unsuccessful upload of firmware to Extruder Controller, WITH pushing
reset button:

May 2, 2012 11:56:09 PM replicatorg.app.util.serial.Serial
scanSerialNames
FINE: RXTX VersionRXTX-2.1-7
May 2, 2012 11:56:13 PM replicatorg.machine.MachineThread run
FINE: MachineThread interrupted, terminating.
May 2, 2012 11:56:13 PM replicatorg.drivers.DriverBaseImplementation
dispose
FINE: Disposing of driver Sanguino3G
May 2, 2012 11:56:13 PM replicatorg.drivers.DriverBaseImplementation
dispose
FINE: Disposing of driver null
May 2, 2012 11:56:13 PM replicatorg.machine.MachineThread
$AssessStatusThread run
FINE: taking assess status thread down

[W. Craig Trader]

I know that when I tried to upgrade the firmware on my extruder controller (TOM 6165), I had lots of problems until I disconnected the cable between the extruder controller and the main motherboard AND disconnected the extruder controller from the power supply (leaving the extruder controller powered by the USB).  Once I did that, the firmware uploaded without problems.  Perhaps that will work for you as well.

- Craig -

On Thu, May 3, 2012 at 6:33 AM, Mark Cohen <markc...@gmail.com> wrote:

With that version of the extruder I used to hit reset twice very quickly at the same time as upload. Also you may need to have the non Ethernet connected or disconnected and try either way. You also need to select the correct new port number when you plug the USB wire directly into the extruder

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
> To post to this group, send email to make...@googlegroups.com.
> To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To post to this group, send email to make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

[MacGyver]

EVERYTIME I have to update the firmware on my TOM I have hit reset
several time very quickly before the firmware will update. I even had
MBI tech support send me a new motherboard once and had them on the
phone before I figured it out. I figured it out out of frustration I
just pressed reset several times in a row an BAM the RX light started
flashing like crazy and it updated. I think it is some sort of timing
issue with how windows 7 handles the USB speed but who knows.

Good luck.

On May 3, 5:32 am, "W. Craig Trader" <craig.tra...@gmail.com> wrote:
> I know that when I tried to upgrade the firmware on my extruder controller
> (TOM 6165), I had lots of problems until I disconnected the cable between
> the extruder controller and the main motherboard AND disconnected the
> extruder controller from the power supply (leaving the extruder controller
> powered by the USB).  Once I did that, the firmware uploaded without
> problems.  Perhaps that will work for you as well.
>
> - Craig -
>
>
>
>
>
>
>
> On Thu, May 3, 2012 at 6:33 AM, Mark Cohen <markcoh...@gmail.com> wrote:
> > With that version of the extruder I used to hit reset twice very quickly
> > at the same time as upload. Also you may need to have the non Ethernet
> > connected or disconnected and try either way. You also need to select the
> > correct new port number when you plug the USB wire directly into the
> > extruder
>
> > Sent from my iPhone
>

[MacGyver]

I forgot to mention I have to have the power turned off or unplugged
as well in order for the update to happen.

[Dan Newman]

On 3 May 2012 , at 9:22 AM, MacGyver wrote:

> I forgot to mention I have to have the power turned off or unplugged
> as well in order for the update to happen.

Which is not good as that sometimes leaves to losing EEPROM data making
you have to redo all the onboard preferences. For some USB masters &
their controlling software, there's just quite not the right oomph for
the EEPROM to be handled correctly in an ATmega 2560. Having the bot
powered on helps in that case.

Issue with Windows is that it can be a little too slow to get the serial port
all properly setup with the correct USB driver and what not when it sees
the device reset itself. But when the device resets itself, it only waits
so long for firmware to be squirted at it before it stops waiting and
steps into the firmware it runs after the boot loader is done waiting.
Doing the double reset is intended to deal with that: make the ATmega &
boot loader start waiting again while Windows is still doing its setup
tasks (and before it will notice that yet another reset happened).

Dan

[Owen M Collins]

Since it is a Cupcake…

After selecting the Firmware but before hitting upload, you have to connect the FTDI end of the cable into the extruder controller and not in the motherboard. That is a simple thing but sometimes overlooked.

Best,

O.

On Aug 18, 2012, at 4:37 PM, dwehrly wrote:

Hey Bob,
Did you ever find a solution?
I'm having the same problem. I got my cupcake a couple of years ago, used it for about 6 months and it set idle until this week. I remember updating the extruder controller once with some difficulty when I first got it. I've got ReplicatorG 0037 now with v3.0 firmware on the motherboard, but my extruder is stuck on v1.6 until I figure this out.

Doug

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.

To view this discussion on the web visit https://groups.google.com/d/msg/makerbot/-/FDhLKCJQ_WcJ.

[dwehrly]

SOLVED!!!
finally after several days of getting beat up by this problem, I found a solution. It may not be the only one, but it works for me.

Please note that I have tried everything else I have found on the internet and nothing works using replicatorg 0022, 0033, 0034 or 0037 (i tried them all). I'm not sure why, but I suspect it has something to do with the avrdude.exe command switches the replicatorg sends. Also note that I found my reset button doesn't work, so I shorted pins 1&3 to produce a successful reset, but still no upload capability. And I also found that if you short the pins for too long or repeatedly (not sure which), it clears the memory entirely.

I found I was able to upload firmware very reliably using the Arduino software, but it doesn't accept hex files that it doesn't create.
I am able to upload the firmware hex code using the command console and the command line that the Arduino software uses to communicate with the atmega128 chip.

Procedure for Windows 7 and a cupcake CNC with MK4 extruder & extruder controller board v2.2 (in excruciating detail):
1. Download and install Arduino 1.0.1
2. connect your usbtinyisp programmer cable to the board & pc
3. start Arduino, select "Tools", "Board" and then select the "Arduino Diecimila or Duemilanove w/ ATmega168
4. Select "Tools", "Programmer" and then select the "USBtinyISP"
5. Make sure your v2.2 board is ready to recieve and your USB port is ready to xmit (reset, or unplug and replug the usb cable in)
6. Select "Tools" and then Select "Burn Bootloader". This will take about a minute or less.
7. Unplug the usbtinyisp cable and now plug in your USB to ttl cable. No external power other than the usb is needed.
8. Select "Files", "Preferences" and then check the "upload" box next to the setting "Show verbose output during:"
9. upload a test program. I used the "File, Examples, 01.Basics, Blink" program since its quick and simple
10. Now you have an avrdude command string in the output window that works successfully with the v2.2 board.
11. open a new window and navigate to the .replicatorg folder (mine is C:\Users\Doug\.replicatorg).
12. while holding down the shift key, right click on the "firmware" folder and select "open a command window here"
13. Copy the avrdude command string from the Arduino output window, and paste into the command window by right clicking on the menu bar of the command window and selecting "Edit, Paste"
14. modify the command line for the file in the "firmware" folder you want to upload and hit return. You don't need to specify a path since you are in that directory.

The command window will return all of the serial actions and let you know if it finished successfully at the end.

I know its a bit of a "long winded" explanation, but I tried not to leave anything out. If you don't have a usbtinyisp cable, you can skip the bootloader burn steps if you are able to successfully  upload a test program with the USB to ttl cable.

Hope this helps somebody else.
Doug

[dwehrly]

FYI, here's the avrdude.exe command line that worked for me:

C:\Users\Doug\Documents\Arduino\arduino-1.0.1\hardware/tools/avr/bin/avrdude -CC:\Users\Doug\Documents\Arduino\arduino-1.0.1\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega168 -carduino -P\\.\COM4 -b19200 -D -Uflash:w:EC-ecv22-v2.5r0-mk4.hex:i

Note the switches: "-v -v -v -v -patmega168 -carduino" and the full path names for the executible and the files. This is where I think the problem with replicatorg (or my installation) may be.

Lots of reference stuff here:
http://www.ladyada.net/learn/avr/avrdude.html
http://arduino.cc/en/Main/Software
http://www.reprap.org/wiki/Extruder_Controller_2.2#Hardware
http://www.ngcoders.com/downloads/arduino-hex-uploader-and-programmer/
http://www.ladyada.net/make/usbtinyisp/index.html

Doug

[Graham MacDonald]

Guilty of thread necromancy here, but just to say thanks - this is the piece of the puzzle I was missing.  I wasn't aware (or had forgotten) to plug the FTDI cable directly to the extruder controller before uploading.  (Currently trying to resurrect a long forgotten cupcake).

So thanks, O!