Arduino Forum

Using Arduino => Microcontrollers => Topic started by: Stevil on Jun 01, 2012, 09:04 pm

Title: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Stevil on Jun 01, 2012, 09:04 pm
Hi guys,
I am at the point where I can't figure out how to get it running =(
I bought myself an Arduino Leonardo and tried to burn a Atmega 328 on a breadboard-installation. I followed the instruction from http://arduino.cc/en/Tutorial/ArduinoToBreadboard but everytime I try to install the bootloader the commandline gives me a

Code: [Select]
avrdude: stk500_getsync(): not in sync: resp=0x00

I already measured all input voltages, changed the 16Mhz Oscillator, changed both 18pF C's to 22pF one's and rechecked all pin-connections.

What am I doing wrong? Thank you so much for your help!

Regards,
Stevil
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: johnwasser on Jun 01, 2012, 09:47 pm
Perhaps you need to disable auto-reset on the Leonardo. See: http://arduino.cc/en/Tutorial/ArduinoISP

"Note for Arduino 1.0: you need to make one small change to the ArduinoISP code. Find the line in the heartbeat() function that says "delay(40);" and change it to "delay(20);".

"An Arduino board serving as an ISP to program the ATmega on another Arduino board. On the Arduino Uno, you'll need to connect a 10 uF capacitor between reset and ground (after uploading the ArduinoISP sketch). Note that you need access to the reset pin on the target board, which isn't available on NG or older boards.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Stevil on Jun 01, 2012, 11:08 pm
Hi John,

thanks for your answer. You mean a 10µF between RST and GND on the Leonardo or on the breadboard?
Anyway I tried both ways - no solution. Same error :(
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Steph on Jun 02, 2012, 03:32 am
It looks like that is using SPI on both the source Arduino and the target Arduino / 328 chip.

If you're using pins 10, 11, 12 and 13 on the Leonardo, you are using the wrong pins. On the Leonardo, SPI only exists on its own ICSP port, not on any of the normal Arduino headers. A further possible problem is that the internal SPI function of pin '10' on the Uno (SPI SS) is not connected to anything on the Leonardo. (Well it's the RX Led but it's not anything you can use directly.)

Edited to add: Mapping the SPI pins from the regular headers to the ICSP, Uno pin 13 (SCK) is on pin 3 of the ICSP header, Uno pin 12 (MISO) is pin 1 of the header, and Uno pin 11 (MOSI) is pin 4 of the icsp header. For pin 10, you can probably leave that one where it is on the Leonardo, it's the other three that are more critical.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Stevil on Jun 02, 2012, 10:54 am
Hi Steph,

that are great thoughts and I already thought that that was the solution for my problem. I connected the MOSI, MISO and SCLK to the ICSP-header - but with no success =( Same error message

Could it be the missing /SS-Pin? I'm afraid of cutting the signal-line to try it.
Any other solution in mind?
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: johnwasser on Jun 02, 2012, 02:48 pm
Serial Programming doesn't use the Slave Select signal.  It uses the Reset pin.  The ArduinoISP sketch uses Pin 10 to control the Reset pin of the target.

The ICSP header on any Arduino (including the Leonardo) will be connected to MOSI, MISO, SCK, Vcc, Ground, and Reset.  You want to hook MOSI, MISO, SCK, Vcc, and Ground to the same pins on the target device.  Then connect Pin 10 on the Arduino running ArduinoISP to the Reset pin on the target device.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Steph on Jun 02, 2012, 02:55 pm
Looking at the ArduinoISP sketch I think I see how you can make it go - the first #define statement is "#define RESET SS" if you change that to "#define RESET 10" then use your Leonardo's pin 10 as the /SS pin that might just do it. Leave the other SPI pins connected to the ICSP on the leonardo, and everything ought to be ok.

Good luck!
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Stevil on Jun 03, 2012, 01:29 pm
Hi John, hi Steph,

tried everything - just won't work. Seems like I'll have to get a Arduino Uno for that kind of stuff =( Seems like no one has ever tried to flash a Atmega328 with an Arduino Leonardo :( - I spent hours on google and tried to get some information.

Maybe tomorrow at work I'll check the SPI signals with a Scope.

Thanks for your help anyway dudes
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Jun 19, 2012, 10:52 pm
The problem is similar to the auto-reset issues when running ArduinoISP on uno, duemilenove...
Whenever avrdude opens the serial port it toggles DTR (and RTS) signals. On these 'classic' arduino's, DTR pulls low the RESET of the programming arduino, causing it to reset. Avrdude then starts communicating with the arduino which may not yet have booted and you get these 'not in sync' errors.

The difference on the leonardo is that when avrdude toggles DTR, this just boils down to an usb control message being sent to the leonardo's usb driver.
I will try to find out what the driver does in response to this message. Anyway the behavior is very similar to what I observe (on my Sanguino) when I install the auto-reset enable jumper: the ide burns a bootloader by calling avrdude twice. The first command succeeds, but the second one fails with a 'not in sync' error.

In meantime I tested two alternative ways to burn a bootloader using a leonardo:

1. Use Nick Gammon's "Atmega_Board_Programmer" sketch. It works out of the box if your target is in the list of supported processors.
This method works because this sketch is stand alone (i.e. it does not download the images over the serial line, they are compiled in, in the sketch)

2. Use ArduinoISP via the leonardo's real uart: Serial1:
- In the ArduinoISP example change all occurrences of "Serial" into "Serial1".
- Also don't forget to change the RESET define into #define RESET 10, as reported by Steph.
- Download the sketch to the leonardo.
- Hookup an ftdi cable or similar to the leonardo's tx1, rx1 and gnd lines.
- In the ide, select the target processor as board type.
- In the ide, Select the port corresponding to the ftdi cable.
- In the ide, select "burn bootloader".
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: pito on Jun 20, 2012, 12:39 am
All atmega chips are set in factory to 1MHz internal clock, so a standard programming may not work. You have to set the programming speed to the lowest one possible, and reflash the fuses to the external crystal mode..
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Jun 20, 2012, 08:29 pm

All atmega chips are set in factory to 1MHz internal clock, so a standard programming may not work. You have to set the programming speed to the lowest one possible, and reflash the fuses to the external crystal mode..

I think this was meant for thread: http://arduino.cc/forum/index.php/topic,110321.30.html?
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: jared1990 on Jun 20, 2012, 09:57 pm
Hi there I'm also having the same problem! I'm new to micro controllers so any help would be appreciated. I have done everything that the previous posts have said and still no luck.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Jun 20, 2012, 11:10 pm
Jared, what microcontroller are you trying to burn a bootloader into?
Can you provide more detail about what goes wrong (output of avrdude(set verbose output for upload in the preferences panel...)). What schematic are you using?

Nick Gammon's board programmer should really work but I forgot to mention you should add
Code: [Select]

while(!Serial)
    ;

as the first line of the setup() routine, otherwise you don't see the messages in the serial console and this is confusing.

In meantime I succeeded to burn a bootloader using the leonardo an ArduinoISP, using the usb cable, not the real uart.

To do this, I increased SERIAL_BUFFER_SIZE  to 150 in CDC.cpp and provided a mechanism to disable autoreset in software (on the leonardo this is all software!). This requires more investigation, not sure the autoreset disable is needed. I will write about this later.





Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: jared1990 on Jun 21, 2012, 07:55 am
Hi Peter, thanks for the reply. I'm using the atmega 328 on a breadboard. I don't have access to a crystal as yet so i was attempting to burn it without the crystal present. When using the Arduino ISP (with all the recommended changes) i got the "avrdude: stk500_getsync(): not in sync: resp=0x00" message. When using Nick Gammon's i get the following:

Atmega chip programmer.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 0x1E 0x95 0x14
Unrecogized signature.
LFuse = 0x62
HFuse = 0xD9
EFuse = 0xFF
Lock byte = 0xFF
Clock calibration = 0xAA

With regards to the setup on the breadboard, Im using the icsp headers on the Leo. The reset pin I connected to pin 10 of the Leo.
Thanks so Much
Jared
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: jared1990 on Jun 21, 2012, 09:20 am
Hi all, think i found the problem... The chip Im using is the 328-pu, not the 328p-pu, so i think that's why the program was not recognizing it. I changed the hex code in Nick's program to the signature of the 328-pu but got this message:

Atmega chip programmer.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 0x1E 0x95 0x14
Processor = ATmega324P
Flash memory size = 32768 bytes.
LFuse = 0x62
HFuse = 0xD9
EFuse = 0xFF
Lock byte = 0xFF
Clock calibration = 0xBD
No bootloader support for this device.
Type 'C' when ready to continue with another chip ...
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Jun 21, 2012, 09:50 pm
Look carefully at the signatures array: it has entries that are completely initialized and there are ones for which the bootloader and subsequent fields are left uninitialized (in which case they are guaranteed to be all zero's).

You modified an entry of the second type: one without bootloader support.
More precisely the ATmega324P entry. But you have a 328PU. So I think you were lucky it did not write anything, if it had written incorrect fuses, the chip could become unrecoverable for ArduinoISP.

I would create a new entry in the table by copying the one for 328P. But consult the datasheet for the AT328PU and check wether the fuse settings are correct (for the crystal you wish to use).

Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Jun 21, 2012, 10:10 pm
@Jared: the optiload program has support for the 328-PU. It uses the same fuse settings for the 328P-PU and the 328-PU.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Jun 25, 2012, 10:45 pm
I have further investigated the problems when running ArduinoISP on leonardo. There are indeed two of them: first is an unintentional auto reset and a second one is a loss of serial data.

The unintentional autoreset is a funny one. The leonardo only autoresets when DTR gets set when the speed at that time is 1200 baud. So normally, avrdude can toggle DTR as much as it wants: as long as the speed is not 1200 baud the leonardo won't reboot.

But guess what happens if you first upload the ArduinoISP sketch to the leonardo:

1. The ide resets the leonardo by "touching" the serial port: it sets DTR when the speed is 1200 baud.
It does not use avrdude to do this.
2. Avrdude downloads the sketch at the baudrate specified in boards.txt. When it is done, avrdude nicely sets the speed back to what it was before: 1200 baud.
Then you decide to burn a bootloader to your target:
3.The ide makes its first call to avrdude. Again, when avrdude is done, just before it closes the port it sets the speed back to what it was: 1200 baud. Closing the port  toggles DTR and the leoardo reboots!
4. The ide makes its second call to avrdude, but the leonardo is not yet up and you get the 'not in sync' error.

Moreover the behavior is timing dependent: if there is little time between 3. and 4. (a fast pc) it may be that the autoreset is cancelled by the second call to avrdude. (See autoreset cancellation code in CDC.cpp).

I'll issue a change request. A possible solution is that the ide sets the baud rate back to what it was, when it is done resetting the leonardo (or at least sets it to another value than 1200). Otherwise this is a recipe for spurious autoresets.

In mean time there is a simple workaround: after uploading the sketch, briefly open the serial monitor and set the baudrate to a value different from 1200. Close the serial monitor again. Then burn the bootloader to your target.

Loss of serial data. When flashing, avrdude provides 128 bytes in one command. USB provides the data so fast  that the device cannot keep up. Changing SERIAL_BUFFER_SIZE to say 150 (in CDC.cpp!), allows you to burn a bootloader. But that is a poor work around. No bytes should be lost even with a buffer of 64 bytes: USB has built in handshaking: if a device cannot accept more data it should send NAK's to the host (the pc) and the host will retry later. The USB controller in the device (leonardo) should do this by itself. I modified the code in CDC.cpp such that it only takes data from the controller's fifo when there is room in its serial buffer. Apparently the USB device controller does the rest.

in CDC.cpp:
Code: [Select]

void Serial_::accept(void)
{
        ring_buffer *buffer = &cdc_rx_buffer;
       
        int i = (unsigned int)(buffer->head+1) % SERIAL_BUFFER_SIZE;

        // if we should be storing the received character into the location
        // just before the tail (meaning that the head would advance to the
        // current location of the tail), we're about to overflow the buffer
        // and so we don't write the character or advance the head.

        // while we have room to store a byte
        while (i != buffer->tail) {
                int c = USB_Recv(CDC_RX);
                if (c == -1)
                        break;  // no more data, we're done
                buffer->buffer[buffer->head] = c;
                buffer->head = i;

                i = (unsigned int)(buffer->head+1) % SERIAL_BUFFER_SIZE;
        }
}


And in USBCore.cpp:
Code: [Select]

...
#ifdef CDC_ENABLED
                USB_Flush(CDC_TX);                              // Send a tx frame if found
                if (USB_Available(CDC_RX))      // Handle received bytes (if any)
                        Serial.accept();
#endif
...


With these changes in place, ArduinoISP on the leonardo works nicely. Any sketch that reads serial data can benefit from this change (of coarse more testing is needed).

I tried this on kubuntu/linux, with avrdude 5.10 as well as 5.11.


Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: bperrybap on Jun 25, 2012, 11:27 pm

The difference on the leonardo is that when avrdude toggles DTR, this just boils down to an usb control message being sent to the leonardo's usb driver.
I will try to find out what the driver does in response to this message. Anyway the behavior is very similar to what I observe (on my Sanguino) when I install the auto-reset enable jumper: the ide burns a bootloader by calling avrdude twice. The first command succeeds, but the second one fails with a 'not in sync' error.


I think that this is actually good news. (in that it may escalate things to actually get fixed)
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.
Here is the link to the Arduino bug report
http://code.google.com/p/arduino/issues/detail?id=650 (http://code.google.com/p/arduino/issues/detail?id=650)
Here is the link to the Savannah bug report for Avrdude:
http://savannah.nongnu.org/bugs/?34339 (http://savannah.nongnu.org/bugs/?34339)

There are several small/easy work arounds that can be done in
the IDE or the Makefiles. The simplest is to do the full bootloader burn in a
single avrdude command vs 2 commands.
The real solution is a small patch for AVRdude.

Too bad the IDE update didn't get done for 1.0.1

--- bill
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: jared1990 on Jun 26, 2012, 02:10 pm
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
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Jun 28, 2012, 10:37 pm

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.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Hydromea on Jul 07, 2012, 10:49 pm

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.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Sep 16, 2012, 11:45 pm
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: http://petervanhoyweghen.wordpress.com/2012/09/16/arduinoisp-on-the-leonardo/ (http://petervanhoyweghen.wordpress.com/2012/09/16/arduinoisp-on-the-leonardo/).
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Fulg on Nov 23, 2012, 04:01 am
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):


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):
Code: [Select]
attiny85at1.upload.using=arduino:arduinoisp

(I am using the ATTiny support from http://code.google.com/p/arduino-tiny/)

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.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Nov 24, 2012, 05:22 pm
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?
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Fulg on Nov 27, 2012, 03:45 am
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:

Code: [Select]
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.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Nov 27, 2012, 10:49 pm
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:

Code: [Select]

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.)
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Coding Badly on Nov 27, 2012, 10:55 pm

- Ensure auto-reset is disabled.

A lack of response from the "programmer" is often caused by auto-reset firing.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Nov 27, 2012, 11:12 pm
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.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Nov 27, 2012, 11:20 pm
I can repeat the problem over here on a windows pc.
Sigh.
Will look at it tomorrow or so.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: RoystonS on Nov 28, 2012, 08:38 pm
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.

Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: RoystonS on Nov 28, 2012, 08:52 pm
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: [Select]

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

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?
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: RoystonS on Nov 28, 2012, 11:35 pm
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...
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: retrolefty on Nov 28, 2012, 11:40 pm
Quote
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
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: RoystonS on Nov 28, 2012, 11:52 pm
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: [Select]

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!
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: Fulg on Nov 29, 2012, 02:59 am
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: [Select]

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.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: PeterVH on Nov 29, 2012, 11:50 pm
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 :-(.
Title: Re: Burning a Atmega 328 Bootloader with an Arduino Leonardo
Post by: retrolefty on Nov 30, 2012, 12:00 am
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