Actually after the first failure, the bootloader seems to be in a loop starting itself back up over and over again. The 3 flashes keep happening at that point, so the 2nd upload always encounters the bootloader no matter when I start it. I did see some code in there that says something about temporarily reprogramming the reset vector to point to the bootloader, so perhaps it gets that far and no farther and it is just constantly hitting watchdog reset and calling bootloader over and over? Still have no idea why the first attempt fails though.
Hum. Try putting AVRdude into very verbose mode (avrdude -v -v -v -v ...) and look for the command which fails. It will also tell you if your fuses are set correctly (low=0xFF, high=0xDC, ext=0x05). You could also check that the memory is being unlocked properly before writing (lock=0x3f).
I tried ultra verbose mode, and it is still mysterious (to me anyway). The transcript of the session that failed followed by the one that worked is here:
http://home.comcast.net/~tomhorsley/hardware/arduino/files/transcript.txt
As near as I can tell the first run tells it to write the initial chunk and never gets back a response.
In the second run, everything looks identical to the first right through the first write which does get a response and then keeps going to a successful completion.
Very weird, but I guess I don't absolutely have to understand it. So far running avrdude twice in a row has always worked to do the upload, so I can upload over bluetooth now with no manual intervention.
I adjusted the boot size fuse bits for a 1K bootloader, is there something in lock bits or other fuse bits that needs tweaking?
Can you show your fuse/lock bytes? Just use avrdude in -v mode to read from it.
I suspect I don't understand something. Do I need it hooked up to the ISP to do this? If I just burn a sketch it tells me "safemode read" of all the fuse and lock bytes are zero.
Here's part of the board definition I used when I burned the new bootloader:
aardremote.bootloader.low_fuses=0xff
aardremote.bootloader.high_fuses=0xdc
aardremote.bootloader.extended_fuses=0x05
aardremote.bootloader.unlock_bits=0x3F
aardremote.bootloader.lock_bits=0x0F
aardremote.build.mcu=atmega328p
What's your programmer again? With USBtinyISP I see this:
$ avrdude -c usbtiny -p m328p -v
avrdude: Version 5.8cvs, compiled on Jan 15 2010 at 17:27:01
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
...
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 5
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK
avrdude done. Thank you.
I think the ArduinoISP one might not read the fuse bytes, so you don't know for sure what they are. And perhaps you can't change them.