Burning a Atmega 328 Bootloader with an Arduino Leonardo

Hi all

Managed to finally burn the bootloader. I changed the hex as i said above, but this time of the code relating to the p-pu and (with alot of luck XD) got it right! I assumed that the settings would be the same after a bit of reading up than the 2 chips and turns out it worked fine!

Thanks for all the help

Jared

bperrybap:
It is an avrdude bug/issue that I reported a while back. It never got any attention because it seemed
to be so narrow as it was an issue when primarily using an AVR dragon.

Hi bill,

The problem you describe is a bit different: I am not familiar with the dragon but from the avrdude code I understand these devices need an (usb) reset for things to work next time (at least on some os'es). Avrdude has code to deliberately perform this reset.

With ArduinoISP it is the other way round: it really wants no reset. ArduinoISP uses avrdude with avrisp as programmer and there is no code to deliberately reset the programmer (i.e. pull DTR low). The reset is a side effect of restoring the serial port in its original state. So on classic arduino's the DTR line has to be cut from the reset pin or a big cap is to be installed. The leonardo has a mechanism (the magic 1200 baud rate) to avoid/filterout these resets but that does not work right after burning the ArduinoISP sketch itself. And this is what I like to fix or have fixed.

About the two separate steps to flash the booter: I am curious about the rationale for this too.
-> Can someone explain this?

But flashing the booter in one step is no adequate solution for ArduinoISP. After this single step, the programmer would still reset which is not what you want: If you are burning something else than a bootloader, say a program for an attiny, after flashing an hex file you want the programmer to just get the target out of reset and wait for the next hex file to burn.

jared1990:
Hi all

Managed to finally burn the bootloader. I changed the hex as i said above, but this time of the code relating to the p-pu and (with alot of luck XD) got it right! I assumed that the settings would be the same after a bit of reading up than the 2 chips and turns out it worked fine!

Thanks for all the help

Jared

Hi, I'm trying to accomplish the same thing that you have done. Could you explain all of the steps you took, hardware and software-wise to get this working? I would greatly greatly appreciate it.

By now, the issues found in this thread were fixed in the Arduino repository in gitub.
I have placed a wrap up of how to use ArduinoISP with arduino 1.0.1 on the Leonardo over here: ArduinoISP on the Leonardo | PeterVH.

Hi everyone,

I still haven't managed to make this work. I'm trying to program an ATTiny85 on Arduino 1.0.2 with a Leonardo, but I'm still stuck at the initial "avrdude: stk500_getsync(): not in sync: resp=0x00" problem.

I have quadruple-checked everything, I am doing everything exactly like the wrap-up that Peter posted (thank you for this BTW), but as this works for some of you, clearly there is something I have not understood yet. My ATTiny is hooked up to the Leonardo ICSP headers (MOSI, MISO, SCLK) and changed the ArduinoISP code to use pin 10 instead of SS, and VCC/GND from the Leonardo.

The symptom is still the same as before, it seems as if the serial connection simply isn't working.

I have built the circuit described in the ArduinoISP code, so I get the heartbeat/programming/error LEDs that the sketch uses. Only the heartbeat is fading in/out. I can trigger other LEDs (usually the error LED!) when writing "stuff" to the Serial Monitor, which is always set to 19200, never to the "magic" 1200 bauds that Peter describes on his page.

Here's exactly what I'm doing on the Arduino IDE (and I suspect somewhere here is where I do it wrong):

  • Load the ArduinoISP code (previously modified with #define RESET 10).
  • Make sure the 1.0.2 IDE is set to use "Arduino Leonardo" as a current board.
  • Upload the ArduinoISP sketch via the Upload button.
  • Watch the Arduino Leonardo reboot, wait for the heartbeat LED to pulse.
  • Load the Blink code, set the blink pin to 0.
  • Make sure the IDE is set to use "ATTiny85 @ 1MHz"
  • Upload the Blink sketch via the Upload button.
  • After several seconds, I get the avrdude error.

I have also tried "Upload using programmer" with no change in behavior, and the IDE "Programmer" menu is set to "Arduino as ISP".

In the boards.txt for the ATTiny, the upload method is set like this (the default):

attiny85at1.upload.using=arduino:arduinoisp

(I am using the ATTiny support from Google Code Archive - Long-term storage for Google Code Project Hosting.)

I have pretty much exhausted all options, can anyone point me in the right direction? Since it works for some people I am sure I'm doing something stupid, but for the life of me I can figure out what!

Thanks,
Ben.

It looks indeed you checked almost everything.

  • Is the tiny new (if not, its fuses could be programmed to disable reset...)?
  • Did you try, without the led (should not matter, but you never know)?
  • In the preferences dialog, can you select verbose mode for uploading and post the output here?

Hello Peter,

The ATTiny85 is new. I have access to an USBTinyISP adapter that I can use to check the chip elsewhere, but the behavior is unchanged even if I completely remove the ATTiny85 from the ArduinoISP programmer (i.e. none of the ICSP pins nor pin 10 connected).

Here is the output of the verbose mode when I attempt to upload using ArduinoISP:

Binary sketch size: 754 bytes (of a 8,192 byte maximum)
C:\Users\Fulg\Downloads\Arduino\arduino-1.0.2\hardware/tools/avr/bin/avrdude -CC:\Users\Fulg\Downloads\Arduino\arduino-1.0.2\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny85 -cstk500v1 -P\\.\COM8 -b19200 -Uflash:w:C:\Users\Fulg\AppData\Local\Temp\build5575126063617730654.tmp\Blink.cpp.hex:i 

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Users\Fulg\Downloads\Arduino\arduino-1.0.2\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM8
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: 
avrdude: stk500_getsync(): not in sync: resp=0x00

avrdude done.  Thank you.

I can see the RX light on the Leonardo blink three times as it runs (once per "Send: 0" line), so I know the COM port is correct. If I go in the Serial Monitor, the baud rate is already set to 19200. If I send "0" manually (no quotes) via the Serial Monitor, the Heartbeat LED stops pulsing. I don't know the ISP protocol (I suppose I could look it up) so if I enter anything else, the Error LED lights up (as expected) and the Heartbeat resumes pulsing. I have never seen any output on the Serial Monitor, I suppose the next step would be to have the Leonardo print some debug output with no chip connected to validate the protocol (as seen from the Leonardo).

I can reproduce the same behavior if I disconnect everything (except the USB cable of course) from the Leonardo and move the Heartbeat LED to pin 13 in the ArduinoISP sketch so I can see it pulse without anything hooked up. At no point do I ever see the TX LED light up, except after I sent "stuff" via the Serial Monitor (as previously mentionned) and obviously break the communication protocol by trying to do it by hand.

Thanks,
Ben.

It looks like a serial communication problem indeed.
avrdude sends 0x30, 0x20 ("0 "). If ArduinoISP receves this correctly, it answers with 0x14, 0x10
otherwise it sends 0x15. At this point there is no spi communication with the target yet. ArduinoISP should reply even with the target disconnected. This is what I get with the target disconnected:

Binaire sketch-grootte: 756 bytes (van een 8.192-byte maximum)
/opt/arduino-1.0.2/hardware/tools/avrdude -C/opt/arduino-1.0.2/hardware/tools/avrdude.conf -v -v -v -v -pattiny85 -cstk500v1 -P/dev/ttyACM0 -b19200 -Uflash:w:/tmp/build5158917964470092706.tmp/Blink.cpp.hex:i 

avrdude: Version 5.11, compiled on Sep  7 2011 at 19:34:16
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/opt/arduino-1.0.2/hardware/tools/avrdude.conf"
         User configuration file is "/home/peter/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyACM0
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [14]       <------------- a reply must be received
avrdude: Recv: . [10] 
         AVR Part                      : ATtiny85
 ... lines omitted ...
         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
avrdude: Send: A [41] . [80]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [02] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [81]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [01] 
avrdude: Recv: . [10] 
 ... lines omitted ...

You don't see the tx led when uploading but you do see the rx led. This make me think the data from avrdude makes it into the core, but not into ArduinoISP, so it does not send out a reply.

You do see the tx led when you enter "stuff" manually. That is weird, but it could be because this happens slower.

-Could you try with an (unmodified) 1.0.1 ide and compare? It will not work because you will have serial buffer overruns, but I would like to see whether it gets further.

-Comment out the delay(40) in the heartbeat() function, it slows things down.

-Another idea: does your serial line work with another sketch. I usually test with the asciiTable sample which I modify such that it continously outputs the table with a second of sleep in between.

-Also inspect port settings in device manager, put it to 8N1 no flow control.

-Do you have an ftdi cable or similar available? (if yes we could do printf debugging over the second port (Serial1) or even use that to upload hex files.)

  • Ensure auto-reset is disabled.

A lack of response from the "programmer" is often caused by auto-reset firing.

Ok, but this is a leonardo, it should not autoreset. The only reason for autoreset I can see here is if the baudrate is set to 1200 in device manager > comm ports.

I can repeat the problem over here on a windows pc.
Sigh.
Will look at it tomorrow or so.

Just so Fulg doesn't think he's alone, I can let you guys know that I'm getting exactly the same output and behaviour as Fulg. (I'm trying to program a 328, but I get the same problems even without a target device connected.) I can see the RX light flashing to indicate reception of the bytes from avrdude, but TX never lights and nothing is ever received by avrdude.

I've even tried replacing the ArduinoISP sketch on the Leonardo with a simple sketch that just writes bytes out to the Serial line constantly. If I open Serial Monitor, I can see all that output just fine. But avrdude doesn't see any of it: its verbose output never shows any 'Recv' data.

I've tried with ArduinoISP built with both 1.0.1 and 1.0.2. Neither seem able to transmit anything back to avrdude successfully. It's as if avrdude can transmit to the device, but not receive from it.

(Of course, all of this is made extra interesting by the fact that I can use the exact same IDE + avrdude to program the Leonardo itself...)

I've tried tweaking ArduinoISP so that it lights up an LED when the initial '0 ' responses are received, and the receipt is fine, so I don't think there's a baudrate issue. My COM port (COM17, as it turns out) is defaulting to 9600/8/N/1, but ArduinoISP and avrdude are overriding that to 19200, without problems on the transmit side at least.

I've managed to get a bit further. It's not working, but I've definitely triggered something.

If I use the standard stk500v1 programmer directive with avrdude, I get this situation where the TX light never fires, and nothing ever comes out of the Leonardo and back into avrdude.

If I change to command line to specify the 'arduino' programmer (whatever that is: I'm just tweaking knobs here), I get a huge flurry of activity, and I actually get bidirectional comms with the ArduinoISP. I've not yet tried it with a target device attached, but I will:

bin\avrdude.exe -v -v -v -v -v -v -P\\.\COM17 -C etc\avrdude.conf  -patmega328p -cstk500v1

avrdude.exe: Version 5.11, compiled on Sep  2 2011 at 19:38:36
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2009 Joerg Wunsch

             System wide configuration file is "etc\avrdude.conf"

             Using Port                    : \\.\COM17
             Using Programmer              : stk500v1
avrdude.exe: Send: 0 [30]   [20]
avrdude.exe: Send: 0 [30]   [20]
avrdude.exe: Send: 0 [30]   [20]
avrdude.exe: Recv:
avrdude.exe: stk500_getsync(): not in sync: resp=0x00

avrdude.exe done.  Thank you.
bin\avrdude.exe -v -v -v -v -v -v -P\\.\COM17 -C etc\avrdude.conf  -patmega328p -carduino

avrdude.exe: Version 5.11, compiled on Sep  2 2011 at 19:38:36
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2009 Joerg Wunsch

             System wide configuration file is "etc\avrdude.conf"

             Using Port                    : \\.\COM17
             Using Programmer              : arduino
avrdude.exe: Send: 0 [30]   [20]
avrdude.exe: Send: 0 [30]   [20]
avrdude.exe: Send: 0 [30]   [20]
avrdude.exe: Recv: . [14]
avrdude.exe: Recv: . [10]

... and so on. Loads of output...

Does this provide any enlightenment?

Ok, it works: I've managed to burn both a bootloader and a simple working Blink sketch to a 328P, on a breadboard, using a Leonardo.

(This is with IDE 1.0.2, MISO/MOSI/SCLK connected from the Leonardo ICSP header to the corresponding 328P pins, pin 10 of the Leonardo connected to RESET on the 328P and the ArduinoISP code modified to use '10' instead of 'RESET'.)

Basically - and this is just through trial and error rather than any understanding - switching to tell avrdude to use the 'arduino' programmer type instead of stk500v1 makes it work. I'm not sure whether that's the correct thing to do, or whether that's a recent change, but it does seem to make it work, at least for programming a bootloader and a simple sketch on the 328P.

Unfortunately I don't know how to do that in the IDE: if I copy and paste the command line that the IDE attempts, and change 'stk500v1' to 'arduino' and then run that myself, it does seem to program correctly.

I'll shut up now...

Unfortunately I don't know how to do that in the IDE: if I copy and paste the command line that the IDE attempts, and change 'stk500v1' to 'arduino' and then run that myself, it does seem to program correctly.

Sense version 1 of the IDE there is under the file menu a upload using programmer option that allows one to burn the sketch via your selected ISP programmer. Works fine, but be aware that burning a sketch this way to a target chip erases all of flash memory and does not replace the bootloader on the target chip, if it had one prior. Not a big deal if that is the way you will always be loading sketches to the target chip.

Lefty

Yeah, I'd tried "File->Upload using Programmer", with Programmer set to 'Arduino as ISP', but it still tried to upload using 'stk500v1' rather than 'arduino'.

But, it seems that you can tell the IDE to add another programmer to its list, to get it to use 'arduino' rather than 'stk500v1'. That then allows direct bootloader and sketch upload from the IDE.

Create a new directory 'hardware/leofix' (or whatever name you like) in your Arduino directory. Put a file in that, called programmers.txt, with contents like this:

arduinoispleo.name=Arduino as ISP (Leonardo)
arduinoispleo.communication=serial
arduinoispleo.protocol=arduino
arduinoispleo.speed=19200

(That's basically the same as 'arduinoisp' but with protocol set to arduino instead of stk500v1.)

Restart the IDE, then you'll get an extra option in your Tools->Programmer dropdown. That can then be used to burn the bootloader or upload sketches. Works for me, anyway!

Thanks RoystonS, I do feel a bit better knowing I'm not the only one with this problem :slight_smile:

FWIW, stock Arduino 1.0.2 IDE works fine on OSX using the same steps I used before (verbose upload yields a similar avrdude output as PeterVH posted). Avrdude complains about a mismatched device signature but this is normal since I have nothing connected to my Leonardo, at least until I sorted this out.

I have exactly the same problem with a stock Arduino 1.0.1 IDE on Windows 7 x64, it sends three "0 " commands and times out waiting for a response.

If I put a "programmers.txt" file like RoystonS describes in my hardware\tiny directory and use that new option as the programmer, communication also works fine (on an otherwise stock Arduino 1.0.2 IDE), in that I get the same answer as I do on OSX (mismatched device signature), at least I can use that to resume Arduino experiments with an ATTiny until the real source of the problem is found. Thanks a bunch for posting that! Progress.

Interestingly, OSX successfully uses 'stk500v1' as a programmer on the very same Leonardo:

Binary sketch size: 754 bytes (of a 8,192 byte maximum)
/Users/fulg/Downloads/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Users/fulg/Downloads/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny85 -cstk500v1 -P/dev/cu.usbmodem1d121 -b19200 -Uflash:w:/var/folders/kc/z8xlwzlx0bnfy9rgk0g563340000gn/T/build2374746136947025915.tmp/Blink.cpp.hex:i 

avrdude: Version 5.11, compiled on Sep  2 2011 at 18:52:52
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/Users/fulg/Downloads/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/fulg/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodem1d121
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
         AVR Part                      : ATtiny85
         Chip Erase delay              : 4500 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     6     4    0 no        512    4      0  4000  4500 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65     6    32    0 yes      8192   64    128  4500  4500 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          2    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
avrdude: Send: A [41] . [80]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [02] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [81]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [01] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [82]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [12] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [98]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
avrdude: Send: A [41] . [84]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [85]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [86]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [87]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [89]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: Send: A [41] . [81]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [01] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [82]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [12] 
avrdude: Recv: . [10] 
avrdude: Send: B [42] . [14] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] @ [40] . [02] . [00] . [00] . [00]   [20] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny85
avrdude: Send: P [50]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: V [56] 0 [30] . [00] . [00] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: V [56] 0 [30] . [00] . [01] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
################avrdude: Send: V [56] 0 [30] . [00] . [02] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
################################## | 100% 0.01s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

avrdude: Send: Q [51]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 

avrdude done.  Thank you.

Thanks,
Ben.

Thanks a lot RoystonS!

Now we know that -c arduino works and -c stk500v1 it is easy to figure out what goes wrong. The answer is in CDC.cpp:

size_t Serial_::write(uint8_t c)
{
        /* only try to send bytes if the high-level CDC connection itself 
         is open (not just the pipe) - the OS should set lineState when the port
         is opened and clear lineState when the port is closed.
         bytes sent before the user opens the connection or after
         the connection is closed are lost - just like with a UART. */

        // TODO - ZE - check behavior on different OSes and test what happens if an
        // open connection isn't broken cleanly (cable is yanked out, host dies
        // or locks up, or host virtual serial port hangs)
        [b]if (_usbLineInfo.lineState > 0) {
                int r = USB_Send(CDC_TX,&c,1);[/b]
                ...

(The TODO says it all...)
The two lsb bits of lineState correspond to DTR and RTS. Apparently on windows, DTR and RTS are not set, and the Leonardo will refuse to send out anything under these conditions.

I checked in avrdude, the code on linux and mac is the same, it does not do anything special to set RTS/DTR, so apparently the os does that. The windows code uses the win32 api, does nothing special either, but windows does not seem to set the signals.

Why does -c arduino work? Because for this protocol, avrdude explictly drops the signals for 250 ms to discharge the autoreset capacitor! Then it explicitly sets them back high! As a consequence this works also on windows with the Leonardo.

I don't know if we miss functionality when using arduino instead of stk500v1: to check...

I updated my writeup with this info. I am afraid Fulg is not the only one at all. Lots of people must have tried this and have been disappointed it did not work :-(.

I think the issue might have a legacy angle. If my memory serves me correctly earlier versions of the IDE, it was the IDE itself that somehow performed the DTR/RTS auto reset pulse to the serial channel before calling AVRDUDE and using stk500v1. At some later version that was dropped as AVRDUDE could perform that task itself if told to use arduino protocol.

Lefty