My leonardo works perfectly under ubuntu/linux 3.0.0-12. I wanted to test whether some stuff I built works with a windows pc. So I hooked up the leonardo to a pc running Windows 7 Home Premium SP1, 64bit. I had a lot of trouble (=understatement) installing a driver for the leonardo. It could install a driver for the booter mode, but not for the sketch mode.

If I watch device manager and plug in the leo, I see that a comm port is added. But as soon as the sketch starts running, the arduino is listed as an unknown device. I tried the "Update Driver" procedure as described in the "leonardo getting started guide": I pointed windows to the arduino-1.0.2/drivers directory. This operation fails: windows reports that a driver could not be found. (Btw, I also have the "RunOnce" registry key).

To rule out my sketch (or my core hacks) as a cause of trouble, I used the ide (on linux) to burn a bootloader to the leonardo. This also burns a fresh standard blink sketch.

Same result, windows cannot install the driver.

I decided to try without the HID (mouse,keyboard) stuff: in  USBDesc.h I commented out this line:

Code:

//#define HID_ENABLED

, recompiled the sketch and uploaded it to the leonardo again using my linux box.
I verified in linux that now the sketch enumerates correctly as a device with only cdc/acm, no HID.

After that,  windows installs the driver correctly, and serial port support works correctly too.

Can someone shed some light on this?
Did someone else observe this problem?
The .inf file for leonardo adds no driver for HID, isn't that a problem?

I am affraid it is caused by a fix I submitted for the problem described here: http://code.google.com/p/arduino/issues/detail?id=995&can=1&q=leonardo.

Sorry for that.

When starting an upload the ide sets the baurate to 1200. When the leonardo observes a DTR drop when the baudrate is 1200, it resets.
In order to avoid unintentional autoresets, the fix sets above sets the baudrate back to the value from the preferences, once the upload completed. For some reason this sometimes fails on your system (different locking scheme on the mac: lock still held by avrdude? the reason should be investigated...). On my system (kubuntu/linux 3.0.0-12) it always works correctly. I'll help think about a proper solution (don't have a mac though) :

• Maybe just catch the exception and ignore it (after all, it can also happen the sketches serial port never comes back, this is of coarse ignored too...)
  
• Retry touching a number of times?
• ...

Fortunately, when the problem occurs, the sketch is already uploaded and works correctly, like you indicated.

Could you submit a bug report?

We'll get there, I found back a pic18f4550 with which I built the same thing. It works on windows too, I just need to find out what it does differently.

I am affraid this is an os dependent thing. I am using kubuntu. I just tried in win xp, it does't work for me either. I don't understand why, I see no difference between the leo setting a DTR_PIN in function of the line status, and the ftdi chip doing so for its own dtr pin. I must think about this...

What os are you on?

avrdude kept reporting the device signature to be 1E--0B when it says it expects the signature to be 1E--06

Ok, so you have an atmega168p instead of an atmega168. To avoid mistakes, it is better to invoke avrdude with -pm168p instead of using -F.
Not all avrdude installations have an entry for atmega168p in their avrdude.conf; if not, use the avrdude from the arduino IDE.

To be able to test ArduinoISP/Leonardo/Arduino1.0.2/arduino-tiny, I made a small board with an attiny85, and hooked it up to my Leonardo.

Never used arduino-tiny before, I followed Coding Badly's instructions http://arduino.cc/forum/index.php/topic,132007.0.html and it all worked out of the box. Many thanks to the creators, nice job!

@kopfkopfkopfaffe: the plot of RESET makes me think you did not put the series cap of 100nF. (see the ascii art schematics in my post).

Well, I just tried it. It worked, but there is one small thing: open the serial monitor right after flashing ArduinoISP into the leo (step 5 in my writeup). This is only needed right after uploading the ArduinoISP sketch. This should have been fixed, I'll need to debug this...
 

Arduino 1.0.2 is out now. Can you try with that, it excludes possible errors in the modifs to the core...
You still have to modify ArduinoISP: #define RESET 10 and of coarse use the pins on the ICSP header.
If it does not work, can you post the exact output of avrdude (use option -v).

Good to hear, but I find it very suspicious you had to use -F. What signature did avrdude report? Was it 0 (then you still have a problem in your wiring or setup) or just not the signature for your target.

However, it looks like ArduinoISP was not intended to work together with Leonardo.

I believe this is not true.  All what is needed for ArduinoISP is an spi interface to the target and a communication link to the pc and the Leo has both. It did not work in 1.0.1 because of a driver bug, but the Leonardo is still new, so this is normal.

Sure, the Leonardo's behavior (resetting, serial line,...) is different and confuses us sometimes. But for ArduinoISP I see no negative effects. I even see advantages:
- The leonardo is immune to autoresets (well, since 1.0.2) triggered by avrdude, on the classic arduino's you need to disable autoreset with a cut in the dtr line or a capacitor...
- The Leonardo has a second serial port (Serial1, the real uart). This is a great feature! I learned a lot about ArduinoISP by printf debugging on the second serial port. (The Leonardo was not yet out at that time, but I used a Sanguino which also has a Serial1). You can't do that on a classic arduino! The Leo is a great little board.

But even without the automatic reset, if I try it manually, it only shows me a bunch of sdk-failed errors.

My guess is that you have serial buffer overruns. Follow the link above and have look at the fixes proposed in "ArduinoISP on the Leonardo"

@kopfkopfkopfaffe: I am glad you ask. I just finished a write up of an experiment that exactly does that.

It is an improved version of sketch posted earlier in this thread.
It now handles autoreset and sets the baud rate of the uart.
It can be used to download sketches via the ide, but also to communicate with the sketch itself.
A minor hack in the core is needed though.

Here it is:
http://petervanhoyweghen.wordpress.com/2012/11/08/using-the-leonardo-as-usb-to-serial-converter

The description of the cable on the e-bay store is really weird.

It is a non standard cable, but you reported it works well with some of your phones, when connected to the due's native port. From this I deduce the ID pin inside the micro B plug is connected to ground making it actually a working micro A plug but with the wrong B (trapezium) shape.

Because of the wrong shape you can also insert it into the programming port. But the latter ignores completely the ID pin. So this makes you connected two usb devices. Nothing should happen in this case, it should cause no harm, but you are right that neither of the devices should source power.

...the programming port is powered; I can charge my phone over it! It's not supposed to power the programming port, right?

It should not even be possible to make such a connection: the usb spec only defines these cables for this use:
1. micro B plug to standard A plug (the regular pc to phone cable).
2. micro A plug to standard A receptacle (what massimo referred to)
3. micro A plug to micro B plug (never seen this for sale)

You can plug cable 1 into cable 2, then you end up with the same thing as cable 3. So you always end up with an A plug on one end and a B plug on the other. The B plug goes in the phone. The A plug has  a rectangular section and should only fit in the native usb port (micro AB connector) of the due. It should not fit in the programming port (micro B connector, trapezium shaped section)

So how did you make the connection?
- did you put the A end in the (otg capable?) phone?
- do you have a non std cable? (on ebay I saw cables that look like standard A receptacle to micro B shaped plug, but it is difficult to tell from the pictures)
- does the due have a micro AB connector (rectangular shape) for the programming port? (I am still waiting for my due, so I can't see for myself)