Burning Bootloader to 168 avrisp mk2 and OSX

I went to the playground and also did some searching on the forum and assembled what I thought was all the info I needed to burn bootloader to bare ATmega168s with Mac OSX and an AVRISP MKII. I followed the instructions, downloaded and built usblib (0.1.2) and avrdude (5.4). I took the script offered and followed some other web links and got the fuses set up right ... my script is below:


#!/bin/sh
IPATH=echo $0 | sed s/[^\/]*$//;
CMD="$IPATH/bin/avrdude"
OPTS="-p m168 -b 115200 -P usb -c avrispmkII"

Erase chip write lock and fuses

$CMD $OPTS -e -U lock:w:0x3f:m -U hfuse:w:0xdf:m -U lfuse:w:0xff:m -U efuse:w:0x00:m

Upload bootloader code

$CMD $OPTS -D -U flash:w:ATmegaBOOT_168.hex:i

Lock boot section

$CMD $OPTS -U lock:w:0x0f:m

The result below ... Now I never set the port, I left the generic term "usb" ... the reason for this nothing ever shows up in /dev/tty ... I look ("ls /dev/tty*" shows nothing added, I rebooted as one suggested) but nothing. I go to "About This Mac" and "More Info" and Apple System Profiler says it has "AVRISP mkii" on its USB bus. The AVRISP MKII has the small green light on indicating it is happy with the NG board and its power and connection. As soon as I start the script the larger green light near the USB becomes active and various blinks and a couple of minutes later I get the results below ....


Golem:/Applications/arduino-0008/bootloader-usb brian$ ./burn.command
avrdude: stk500v2_getsync(): error communicating with programmer: (0)

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.10s

avrdude: Device signature = 0x1e9406
avrdude: erasing chip
avrdude: reading input file "0x3f"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3f:
avrdude: load data lock data from input file 0x3f:
avrdude: input file 0x3f contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xdf"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xdf:
avrdude: load data hfuse data from input file 0xdf:
avrdude: input file 0xdf contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.04s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0x00"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x00:
avrdude: load data efuse data from input file 0x00:
avrdude: input file 0x00 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

I am lost at this point! Any one tell me where I have gone wrong.

cheers ... BBR

Well, it looks like the fuses got written successfully. Does it do anything after that?

If not, you could try running the next command manually:

bin/avrdude -p m168 -b 115200 -P usb -c avrispmkII -D -U flash:w:ATmegaBOOT_168.hex:i

If you are looking for the avrispmkII in /dev/tty.whatever, you're mistaken - it does not show up there.

If you are looking for the Arduino at /dev/tty.whatever, you must first load the FTDI drivers and plug the Arduino into a USB port.

-j

Well, it looks like the fuses got written successfully. Does it do anything after that?

If not, you could try running the next command manually:

bin/avrdude -p m168 -b 115200 -P usb -c avrispmkII -D -U flash:w:ATmegaBOOT_168.hex:i

well that is the point ... it just stops there, but you got me thinking and I went ahead and created and ran "burn2.command"


#!/bin/sh
IPATH=echo $0 | sed s/[^\/]*$//;
CMD="$IPATH/bin/avrdude"
OPTS="-p m168 -b 115200 -P usb -c avrispmkII"

Erase chip write lock and fuses

#$CMD $OPTS -e -U lock:w:0x3f:m -U hfuse:w:0xdf:m -U lfuse:w:0xff:m -U efuse:w:0x00:m

Upload bootloader code

$CMD $OPTS -D -U flash:w:ATmegaBOOT_168.hex:i

Lock boot section

$CMD $OPTS -U lock:w:0x0f:m

It ran, and it worked, I have a working bootloader, even loaded a program to it, thanks Dave ... bbbuuuttttttt ....I noticed the time it took to verify 512 seconds ... is that right?????????? Add to that the "communications error", each time avrdude had to be invoked there was about 2-3 minutes of floundering around before it started writing. The whole process took over 20 minutes, why did it abort the script the first time and not the second time?

OK, I just added all the calls onto one line in yet another version of "burn.command" so that avrdude has to "find" the avrisp mkii only once, and it worked. The total time was significantly less. After 6 minutes it started displaying output coming in near the end of the writing flash ... verifying still took 512 seconds ... total time was under 16 minutes

$CMD $OPTS -e -U lock:w:0x3f:m -U hfuse:w:0xdf:m -U lfuse:w:0xff:m -U efuse:w:0x00:m -D -U flash:w:ATmegaBOOT_168.hex:i -U lock:w:0x0f:m

Again ... what am I doing wrong ... p.s. kg4wsv, if AVRISP MKII doesn't show up at /dev/tty where does it show up?

cheers ... BBR (aka n1bq)


Golem:/Applications/arduino-0008/bootloader-usb brian$ ./burn4.command
avrdude: stk500v2_getsync(): error communicating with programmer: (0)

avrdude: AVR device initialized and ready to accept instructions

Reading | ##### | 100% 0.10s

avrdude: Device signature = 0x1e9406
avrdude: erasing chip
avrdude: reading input file "0x3f"
avrdude: writing lock (1 bytes):

Writing | ##### | 100% 0.04s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3f:
avrdude: load data lock data from input file 0x3f:
avrdude: input file 0x3f contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ##### | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xdf"
avrdude: writing hfuse (1 bytes):

Writing | ##### | 100% 0.03s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xdf:
avrdude: load data hfuse data from input file 0xdf:
avrdude: input file 0xdf contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ##### | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ##### | 100% 0.10s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ##### | 100% 0.04s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0x00"
avrdude: writing efuse (1 bytes):

Writing | ##### | 100% 0.11s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x00:
avrdude: load data efuse data from input file 0x00:
avrdude: input file 0x00 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ##### | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "ATmegaBOOT_168.hex"
avrdude: writing flash (15916 bytes):

Writing | ##### | 100% 51.71s

avrdude: 15916 bytes of flash written
avrdude: verifying flash memory against ATmegaBOOT_168.hex:
avrdude: load data flash data from input file ATmegaBOOT_168.hex:
avrdude: input file ATmegaBOOT_168.hex contains 15916 bytes
avrdude: reading on-chip flash data:

Reading | ##### | 100% 512.78s

avrdude: verifying ...
avrdude: 15916 bytes of flash verified
avrdude: reading input file "0x0f"
avrdude: writing lock (1 bytes):

Writing | ##### | 100% 0.11s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0f:
avrdude: load data lock data from input file 0x0f:
avrdude: input file 0x0f contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ###### | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

Golem:/Applications/arduino-0008/bootloader-usb brian$


I cleaned up my files and tarred the results if anyone wants to give it a try ... I guaranty nothing. I can say that it runs on m MacBookPro 2 GHz Core Duo under OSX 10.4.10 with all updates. It has avrdude 5.4 with usblib support and was compiled under Xcode 2.4.1. It will burn an ATmega168 using an AVRISP MKii

http://www.wulfden.org/Arduino/bootloader-intel-usb.tar.gz

The tar.gz file is 275K and will unpack to 1.4 MB. It has the hexfile for the 168, the script, the executables, usblib support and man pages for avrdude. Unpack it into /Applications/arduino-0008, it will come out as a folder called "bootloader-usb". Go to a terminal window and cd to the directory and excecute the script by typing

./burn.command

I hope this helps someone

cheers ... BBR

I had a similar problem: a very long delay when I first ran avrdude before it started to do anything. I had to actually patch avrdude to fix it. Arduino 0009 (which should come out tomorrow) will include the patched version and a "Burn Bootloader" command.

I submitted a bug to avrdude: AVR Downloader/UploaDEr - Bugs: bug #19882, Many "error in USB... [Savannah] but haven't heard anything. You might want to add a comment explaining your experience (with the long delay on startup). These things sometimes get fixed faster if multiple people report them.

I had a similar problem: a very long delay when I first ran avrdude before it started to do anything. I had to actually patch avrdude to fix it. Arduino 0009 (which should come out tomorrow) will include the patched version and a "Burn Bootloader" command.

I submitted a bug to avrdude: AVR Downloader/UploaDEr - Bugs: bug #19882, Many "error in USB... [Savannah] but haven't heard anything. You might want to add a comment explaining your experience (with the long delay on startup). These things sometimes get fixed faster if multiple people report them.

OK, will do ... but back to my question about the time it took to burn and to verify the flash, 51 seconds and 512 seconds .... is that right? 512 seems awfully long!

cheers ... BBR

I added a call to date at the start and finish of the script and burnt several 168s with the bootloader. It is quite consistent at 15 minutes plus 4-8 secs second total time to run, the flash write is 51.7 seconds and verify is 512 seconds ... I hope your patched avrdude in 0009 works better.

cheers ... BBR

I seem to recall an issue where some avrispmkII programmers have their clock period unusually long, which leads to long programming times. Maybe this link could shed some light, or at least get you started in the right direction.

-j

51 seconds to burn and 512 seconds to verify the flash does seem very long. That sounds like it might be a result of what kg4wsv suggested: that the avrispmkii is configured with a slow clock period. The delay at startup though, is because (assuming it's the same as it was in my case) avrdude tries to sync with the avrispmkii 33 times, and each one has a long timeout.

51 seconds to burn and 512 seconds to verify the flash does seem very long. That sounds like it might be a result of what kg4wsv suggested: that the avrispmkii is configured with a slow clock period. The delay at startup though, is because (assuming it's the same as it was in my case) avrdude tries to sync with the avrispmkii 33 times, and each one has a long timeout.

OK, but is there any way to put the "sck 10" into a command line option for a script?

aaaannnddddd .... to add some more fuel for pondering ... I just strated up to burn some chips and did ONE THING different ... instead of plugging the USB cable into the side of he MacBookPro I plugged it into a spare port on my Belkin 7 port USB hub ... and, voila, no 5 minute wait, it immediately started doing its thing. Total time start to finish was just under 10 minutes (essentially just under 1 min for burn, just over 8 min for verify, and the rest for locks and fuses) and quite repeatable I am on my fifth chip .... how does this fit in with your theories?

... wheee ... are we having fun yet? -grin- this is making me sweat, but I am an old dog learning new tricks!

cheers ... BBR

OK, but is there any way to put the "sck 10" into a command line option for a script?

If I understand correctly, issuing that command causes it to be written to EEPROM in the avrispmkII, so it should be a one shot deal.

FYI, on a recent project I flashed and verified a 7k program in a few seconds from a PPC powerbook, so what you are seeing isn't normal (but I think you already knew that :slight_smile: ). I was burning directly from the powerbook's USB port, while on battery even.

You may also want to check the firmware on your avrispmkII.

-j

OK, but is there any way to put the "sck 10" into a command line option for a script?

If I understand correctly, issuing that command causes it to be written to EEPROM in the avrispmkII, so it should be a one shot deal.

FYI, on a recent project I flashed and verified a 7k program in a few seconds from a PPC powerbook, so what you are seeing isn't normal (but I think you already knew that :slight_smile: ). I was burning directly from the powerbook's USB port, while on battery even.

You may also want to check the firmware on your avrispmkII.

-j

ALL RIGHT!!!!!! Now we have it ..... under 1 sec burn, under 8 seconds verify .... 22 seconds ... start to finish .... the "sck 10" did the trick. Dave, should I write this up for the Playground???????


Golem:/Applications/arduino-0008/bootloader-usb brian$ ./bin/avrdude -p m168 -b 115200 -P usb -c avrispmkII -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.10s

avrdude: Device signature = 0x1e9406
avrdude> sck

sck
Usage: sck
avrdude> sck 10
sck 10
avrdude> q
q

avrdude: safemode: Fuses OK

avrdude done. Thank you.

Golem:/Applications/arduino-0008/bootloader-usb brian$ ./burn.command
Sun Aug 5 16:55:52 EDT 2007

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406
avrdude: erasing chip
avrdude: reading input file "0x3f"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3f:
avrdude: load data lock data from input file 0x3f:
avrdude: input file 0x3f contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xdf"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xdf:
avrdude: load data hfuse data from input file 0xdf:
avrdude: input file 0xdf contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0x00"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x00:
avrdude: load data efuse data from input file 0x00:
avrdude: input file 0x00 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "ATmegaBOOT_168.hex"
avrdude: writing flash (15916 bytes):

Writing | ################################################## | 100% 0.73s

avrdude: 15916 bytes of flash written
avrdude: verifying flash memory against ATmegaBOOT_168.hex:
avrdude: load data flash data from input file ATmegaBOOT_168.hex:
avrdude: input file ATmegaBOOT_168.hex contains 15916 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 7.16s

avrdude: verifying ...
avrdude: 15916 bytes of flash verified
avrdude: reading input file "0x0f"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0f:
avrdude: load data lock data from input file 0x0f:
avrdude: input file 0x0f contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

Sun Aug 5 16:56:14 EDT 2007
Golem:/Applications/arduino-0008/bootloader-usb brian$


Go for it, I think it would be useful for anyone else with an AVRISPmkII (especially so they don't need Windows and AVR Studio just to change that one setting).