Extruder Controller V2.2 Bootloader Issue

I'm trying to burn the Bootloader onto my Extruder Controller v2.2 board, using the USBtinyISP, using the Wiki Page as a guide. I have successfully tested my Motherboard and 2 of the stepper drivers/motors and this is the first problem I've hit which I can't find a solution for.

When I try to burn the Bootloader (with "Arduino Diecimila, Duemilanove, or Nano w/ ATmega168" selected under boards) , I get an error:

avrdude: Expected signature for ATMEGA168 is 1E 94 06
         Double check chip, or use -F to override this check.

It seems to imply that it can communicate with the chip, but doesn't want to continue because it doesn't recognize the chip's signature.

The chip on my board says:
ATMEGA168
20AU 0913

(I'm guessing that the 0913 is just a manufacturing batch number or a date-code or something.)

So I'm pretty sure I have the right chip.

I've tried it using Arduino 0021 and Arduino 0019 (hoping it was just a Arduino version issue).

I admit that I'm something of an electronics newbie, this is the 1st project I have worked on like this. However the board looks fairly good to me, no obvious solder bridges.

What do you reckon? Dead Chip? Bad Soldering? Configuration Issue? Schoolboy error?

Have you the correct drivers from here?

[www.ladyada.net]

---

Regards

Ian

I have the same problem, or at least a similar problem:


avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATMEGA168 is 1E 94 06

I don't know how to fix the "all zeros arduino device signature" problem, but passing -F will make avrdude continue past this problem.

There are some serious downsides to the -F parameter though. I wish there was a way to tel avrdude to ignore the device signature only, but that's apparently not an option.

I seem to recall someone else having a problem with that, and coming up with a way to fix the arduino so that it had the correct signature. Something involving re-flashing the bootloader though. Since I don't have a programmer of any sort, that won't work for me

So I've just been abusing the -F flag.

---

--
I'm building it with Baling Wire

emt Wrote:
-------------------------------------------------------
> Have you the correct drivers from here?
>
> [www.ladyada.net]
> ml


Thanks for the reply, I'm pretty sure I have the right drivers. I have Windows 7 64 bit, which has different drivers. I've tried both the separate Win7 drivers and the latest standard drivers (which if I remember correctly just don't work on my machine). Still the same problem.

I forced the bootloader on lastnight with this command (which i derived from the makerbot wiki, here):

avrdude -C avrdude.conf -v -p m168 -c usbtiny -U flash:r:ATmegaBOOT_168_diecimila.hex:i -F

(I added the avrdude directory to the system PATH variable to make it easier to call) I then added avrdude.conf and ATmegaBOOT_168_diecimila.hex to C:\ and called the command.

I'm pretty sure that "ATmegaBOOT_168_diecimila.hex" is the correct boot-loader file, however i'm not sure what the :r and :i flags are...

I then receive this error if I try and upload any firmware:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

(I have the right boards setting and I'm pretty sure I have the correct serial port selected, which is COM3 on my machine).

I'm not sure if this means that the bootloader worked and now I have another problem, or that the bootloader hasn't burned on properly.

Do you think I have made a step forwards or backwards?

EDIT: I might touch any remotely dodgy looking pads on the board with the Soldering Iron tonight to reset them. Maybe I have a dodgy connection somewhere?

Thanks for the help!

Edited 1 time(s). Last edit at 11/15/2010 10:04AM by Alpine.

Hi

You can upload firmware direct into the chip without using a bootloader using the USBtiny. I had to use this method with Sanguinos which I could never get to work with a boot loader.
Details here:-
[www.arduino.cc]


I added a line:-

sanguino.upload.using=usbtinyisp

to the sanguino section of boards.txt

Normal upload button then uses the USBtinyISP instead of the standard USB cable.

No other boards are affected.

To revert to normal programming using the boot loader just take the line out.

In your case I guess you add arduino.upload to the arduino section of boards.txt.

Be warned at some time the board.txt file location was changed and I had 2 copies. Took several hours of head scratching because I was changing the wrong one and there was no effect because Arduino was using the other copy. So check you only have one copy and if not delete any copies not used by Arduino.

---

Regards

Ian