Go Down

Topic: Building custom bootloader? (Read 4 times) previous topic - next topic


Check the bootloader version in your Uno (see instructions here http://arduino.cc/forum/index.php/topic,64105.msg468453.html#msg468453).  Thanks to Westfw's work on optiboot, recent versions >=4.3 don't require reset to be disabled when running ArduinoISP.

Another good thing to know. Thanks! (Someone should update the ArduinoISP wiki to mention this :-).


recent versions >=4.3 don't require reset to be disabled when running ArduinoISP.

FWIW, things still seem to work better for me with the cap between RESET and GND...


Seemed to work OK without the cap, but I did encounter the bug with 19200 baud causing problems. Had to figure out how to get everyone to agree on 9600 baud, then I was able to burn the new bootloader.


And now I've tried to use the watchdog reset gimmick to upload a new sketch and am utterly confused by the results :-). Avrdude appears to start talking to the bootloader OK (I don't get the kind of sync errors I get without the reset), but it gets to the point where it says "Writing" and would normally print # chars for progress, but it makes no progress and eventually says "not responding".

But wait! It gets weirder. At this point, it has apparently erased the old sketch, so now it really is sitting in the bootloader doing the 1-2-3 flashy thing on pin 13. If I try to upload the new sketch again, it works perfectly.

So I have a procedure that works for uploading microcode without physical access to the board, but I have no idea why it works :-).

Anyone know if there are things I need to reset manually that a watchdog reset doesn't reset? Should I be using different lock bits or something to make a watchdog reset "harder" in some way? I'm really mystified.

If anyone is actually curious enough to want to look at my bootloader hacks and the code that uses them, you
can always find the latest version of the source pointed at by:



Hmm, I'm not sure I follow.  Is this the sequence of events?

  • Sketch sets eeprom flag and executes watchdog reset

  • Bootloader starts running : detects and wipes eeprom flag, does three LED flashes, and starts communicating with AVRdude

  • Communication is lost for reasons unknown, and AVRdude hangs

  • Bootloader watchdog expires and bootloader resets itelf

  • On this pass the bootloader does not flash the LEDs but immediately tries to start the sketch

  • The sketch has been wiped, so nothing happens

How do you trigger the second sketch upload attempt?


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:


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?

Nick Gammon

Can you show your fuse/lock bytes? Just use avrdude in -v mode to read from it.


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:


Nick Gammon

What's your programmer again? With USBtinyISP I see this:

Code: [Select]
$ 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.

Go Up