Go Down

Topic: Turn Arduino into an ISP programmer (Read 25043 times) previous topic - next topic


I've never got it to work myself, so I'm not sure I can help.  It's possible that a "programmer not responding" message is a hardware problem; I think it could happen if the SPI between the board and the chip being programmed fails.  Maybe Massimo has more ideas what the problem is?  



the instructions are not super simple yet, i'm working on writing a better tutorial.

Any progress on this? :)

It's probably an obvious oversight on my part, but what should one change the port to in "load.command" for a PC COM port? Also, can one burn the regular Arduino firmware back to the chip after programming others?



May 07, 2008, 01:28 am Last Edit: May 07, 2008, 02:05 am by jm Reason: 1
hi all -

it would really be great if people could use their arduinos as avr isp programmers! it seems like it should be possible, so i'm very surprised that there doesn't seem to be a working method, since it would be a popular feature of the arduino.

i've tried a few different "how-to's" that claim to be able to do this, but it seems like none of them actually work, at least for what i want (program atmega168, along with fuse bits).

i tried this one out but couldn't get it to work either, same kind of errors as the others reported. it seems (although i'm not sure) that the avrusb500.hex file gets loaded into my arduino diecimila with:

cd /Applications/arduino-0011/hardware/tools/avr/bin
cp ~/Desktop/avrusb500-1.5-arduino/avrusb500.hex .
./avrdude -C ../etc/avrdude.conf -p m168 -c avrisp -b 19200 -P /dev/cu.usbserial-A4001lXM -U flash:w:avrusb500.hex

(need to press the reset button just before hitting enter on the last command).

[edit: does this even work though? i was just reading about the diecimila's reset behaviour, seems it goes to the sketch almost immediately after pressing reset - so maybe i'm not even actually uploading it, even though avrdude says so?]

but then i try to upload a compiled "blink" sketch to my target (atmega168 with internal 8MHz clock, sketch compiled with lillypad arduino settings) using this (without pressing reset):

cp /tmp/build*/Blink.hex .
./avrdude -C ../etc/avrdude.conf -p m168 -c avrisp2 -b 115200 -P /dev/tty.usbserial-A4001lXM -U flash:w:Blink.hex -U lfuse:w:0xE2:m -U hfuse:w:0xDF:m

...all i get is:

avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout

do i need to recompile the avrusb500.hex for the atmega168? i'm not quite sure of the magic spell needed to do that. or, should i stop wasting my time and buy a real programmer?

thanks... jm


the water runs the easiest way. i've stopped fooling with parallel programmers and turning arduino in isp programmers and bought a avrisp mkII. works on mac, albeit very slow. 10 minutes to completion! but it works. as soon as the deadline i'm in right going to is passed, i will investigate further in the arduino as programmer stuff. i've resoldered the 16Mhz xtal and stored the 3.6468 xtal for later retrieval.

lost a few days fiddling with pc on windows, braking working arduino's and searching the web for clues...
"We're all in this together..."


macsimski: if your AVRISP mkII takes 10 minutes to burn a bootloader, it's probably configured to have a very slow communication speed.  You can reconfigure it with with AVR Studio on Windows (and possibly some other way as well).  Apparently they come from the factory with a random default speed.


done that.
it works. in avrstudio is mentioned that isp speed should be less or equal than 1/4 of the clockspeed. atmega168's are set to 1Mhz clock so 250Khz is ok. i'm still on 125Khz, but will try 250 tomorrow.

anyway, programming is now in 6 secs. in the arduino ide.

keywords: AVRISP MKII speed slow
"We're all in this together..."


does someone know a method to change the speed with another (non-windows) tool? apparently avrdude has not the ability, or has it?
"We're all in this together..."


I think avrdude can do it, but that's about as much information as I have on the subject.  Search the avrdude documentation for the -B (bitclock) command line option.  Apparently this affects the ISP clock.

- Ben


Jun 02, 2009, 11:06 pm Last Edit: Jun 02, 2009, 11:39 pm by busstopArduino Reason: 1
Hi all
Is there any update on this?
I need a programmer and am going to try it from the OS X envrons

Would appreciate any feedback from you brave noble people out there who have had success



If you're looking to burn bootloaders, try Programmer2. I haven't had much luck getting my Mac to recognize it as a programmer because it seems to emulate an odd programmer and because avrdude won't recognize the FT232 interface unless you explicitly tell it where to look on the command line (so no burning from the IDE), but it can autonomously/semi-autonomously burn the 8/168 bootloaders stored in the program and set fuses and whatnot.

I've been playing with the code, and plan on releasing a version updated to add support for the atmega328, but it's taking some cajoling to fit all 3 bootloaders as well as the ISP emulation code in the 168's flash size. The original author seems to have made some strange programming decisions, and I'm having trouble figuring out what might break the ISP functions (which I can't really test) if I replace it with code that appears to do the same thing more efficiently.


I think it should be OK to buy the AVRIspMK2. I don't use MaxOS but here  
is an article about using this programmer on a Mac with libusb. All the problems about being slow seem to be related to the programmer being accessed through a serial-port.
This thing works fast on Linux and Windows, so I don't think it will fail on a Mac.


the avrispmkII works fine on OS X.  You can set up an entry in boards.txt and program directly from the arduino IDE via standard upload procedure.

I don't recall if I had to build avrdude, or if the avrdude binary that comes with arduino works out of the box.

There were some speed issues involving the factory default settings of some avrispmkIIs.  I think mine was one of those.



so, how long should a USB AVRISPmkII take to burn a bootloader, e.g. ATmegaBOOT_168_ng.hex or ADABOOT_168.hex, with the Arduino 16 IDE Burn Bootloader?  (the former is 5700 bytes, the latter is 4800.)

it's taking about 10 minutes on my G4 Mac 10.4.  if this is not normal, what is the best way (on a Mac) to increase the ISP comm speed?



so, how long should a USB AVRISPmkII take to burn a bootloader, e.g. ATmegaBOOT_168_ng.hex or ADABOOT_168.hex, with the Arduino 16 IDE Burn Bootloader?  (the former is 5700 bytes, the latter is 4800.)

I only use the AVRIspMK2 on Linux and Windows and it doesn't take much longer than 15-20 seconds.
I don't think this has anything to do with the speed on a serial-port.
As far as I know AVRDude talks to the device using the usb-protocol directly, there is no Serial-Data-Over-USB-Emulation-Software involved. The timing on Linux/Windows must be possible on a Mac, too.



i've been trying to figure out the -B option to fix speed of AVRISPmkII.  i used this command line and the speed did indeed improve dramatically, it only takes 10 seconds now, here it is in case it helps anyone else [assuming USB and atmega8]:

[font=Courier]avrdude -p m8 -c avrispmkII -B 1 -Pusb[/font]

seems you have to specify -p (part) even though you're not doing anything with the part, not sure what you do if you have nothing to connect the programmer to.  

i just chose 1 for -B value, not really sure what the proper value is, based on this:

-B bitclock

Specify the bit clock period for the JTAG interface or the ISP clock (JTAG ICE only). The value is a floating-point number in microseconds. The default value of the JTAG ICE results in about 1 microsecond bit clock period, suitable for target MCUs running at 4 MHz clock and above. Unlike certain parameters in the STK500, the JTAG ICE resets all its parameters to default values when the programming software signs off from the ICE, so for MCUs running at lower clock speeds, this parameter must be specified on the command-line.

Go Up