next topic »

[on:]

Hi,
I'm trying to burn a bootloader onto a factory-new Atmega644PA using 'ArduinoISP' running on a Duemilanove with an Atmega168. Using the 'Burn Bootloader' option from the GUI, I get:

avrdude: Expected signature for ATMEGA644P is 1E 96 0A

I got avrdude talking to ArduinoISP from the commandline to see what signature it *is* receiving: it is 1E 94 06 (the valid signature of the '168 on the host Duemilanove!!)

Just for fun, I disconnected the MISO line from the target '644P and re-ran avrdude... it still reports 1E 94 06.

Output of avrdude:

Code:

J:\arduino-0018\hardware\Sanguino\bootloaders\atmega644p>avrdude -b 19200 -p atm
ega644p -C J:\arduino-0018\hardware\tools\avr\etc\avrdude.conf -c stk500v1 -P CO
M4 -n

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9406
avrdude: Expected signature for ATMEGA644P is 1E 96 0A
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

I had a quick look at the ArduinoISP code, but didn't see anything that would support reading from its own self. The only explanation I can think of is if a) the Arduino bootloader itself follows the identical stk500 protocol and b) 'burn bootloader' / avrdude is somehow resetting the host Arduino as it starts, and erroneously talking to the host's bootloader.

Has anyone seen this before? Is there a good way to rule in/out this hypothesis without a scope handy, or otherwise get to the bottom of it?

(PS. Will the avrdude output line showing the signature it DID read ever be added to the GUI error message, pretty please?)

[Reply #1 on:]

Let's see....

You have loaded the ArduinoISP sketch into the Arduino, right?  You have made the connections to your other chips, right?

Then in the avrdude command line, shouldn't it have "-c arduino" instead of "-c stk500v1"  ???

I mean, that's how it works on my system. (But on my system it requires "-b 57600" not "-b 19200" so maybe my experience doesn't help you.   I'm new at this Arduino stuff.  Oh, well...)


Regards,

Dave

[Reply #2 on:]

UPDATE: That was it! The Arduino bootloader DOES exactly follow the stk500 protocol, right down to hard-coding (#define...) the appropriate chip's signature to fake the signature response. Don't know why, but both the GUI and avrdude were forcing a reset during opening the COM port (this is a Windows XP machine and Duemilanove's builtin USB->serial converter, this may be platform-specific).

To solve: For Duemilanove, use an X-Acto to cut the trace between the RESET-EN solder pads. NOTE: You will need a soldering iron to undo this. For boards that provide a jumper to enable/disable this reset behavior, remove it.

I am curious now, is it possible to control this behavior in software? (e.g. add a setting to the GUI config to disable this reset for ArduinoISP / Burn Bootloader).

[Reply #3 on:]

WARNING! EXPECT YOUR BOARD TO BE NON-FUNCTIONAL AFTER THIS OPERATION!

After screwing around for 8+ hours trying to get a chip programmed, I broke down and tried what this post suggests. I registered to warn you not to do the same thing. I'm waiting for my iron to heat up so I can fix this.

1) This did not fix the problem of avrdude seeing the chip in the duemilanove (atmega168/328p) instead of the chip i'm trying to program (attiny25/45/85).

2) The board stopped functioning normally. I had to get the timing just right pressing reset in order to get it to be read with avrdude at all and keeps going out of sync.

[Reply #4 on:]

So to follow up with my "don't cut the traces" post, I found the following solution to be better as it:

1) Requires no pcb modifications.
2) Is easily reversable.
3) Addresses the same issue the OP noticed.

Reference:

http://www.arduino.cc/playground/Main/DisablingAutoResetOnSerialConnection

1) Without disabling the reset, upload the ArduinoISP sketch to your board.
2) Put 110-124 ohms of resistance between 5v and Reset. (I did so by using a 100ohm and a 10ohm resistor in series)
3) Use avrdude to interact with your target chip.