next topic »

[Reply #30 on:]

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.

[Reply #31 on:]

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:

Code:

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.

Code:

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?

[Reply #32 on:]

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...

[Reply #33 on:]

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

[Reply #34 on:]

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:

Code:

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!

[Reply #35 on:]

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

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:

Code:

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.

[Reply #36 on:]

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)
        if (_usbLineInfo.lineState > 0) {
                int r = USB_Send(CDC_TX,&c,1);
                ...

(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 :-(.

[Reply #37 on:]

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