Updated Arduino as ISP setting

[NicoHood]

With the new avrdude there is a special arduino option that does not trigger DTR and won't reset the Arduino.

[matthijskooijman]

Are you sure? The "arduino" protocol in avrdude is also used for uploads to the Arduino Uno, so I doubt that leaves DTR untouched? It would be a good feature in avrdude, though, preventing problems with arduino-as-isp, but i'm not sure if not touching DTR is possible in a cross-platform way (I think some linux drivers have the DTR assertion on open hardcoded).

[NicoHood]

That is what I always used before and was recommended in a lot of internet sites.

Extract from avrdude config:

programmer
  id    = "arduino";
  desc  = "Arduino";
  type  = "arduino";
  connection_type = serial;
;

programmer
  id    = "stk500v1";
  desc  = "Atmel STK500 Version 1.x firmware";
  type  = "stk500";
  connection_type = serial;
;

It uses the arduino.h/cpp files. I remember that this fix was needed to use a 32u4 as ISP. It seems that it now works without for some reason!?

[cmaglie]

AFAICS the "arduino" uploader is the same as "stk500", but with DTR/RTS toggle to allow Arduino Board's reset.

quoting:
http://svn.savannah.nongnu.org/viewvc/trunk/avrdude/arduino.c?root=avrdude&view=markup

you can clearly see a 250ms pulse on DTR and RTS.

static int arduino_open(PROGRAMMER * pgm, char * port)
{
  union pinfo pinfo;
  strcpy(pgm->port, port);
  pinfo.baud = pgm->baudrate? pgm->baudrate: 115200;
  if (serial_open(port, pinfo, &pgm->fd)==-1) {
    return -1;
  }

  /* Clear DTR and RTS to unload the RESET capacitor 
   * (for example in Arduino) */
  serial_set_dtr_rts(&pgm->fd, 0);
  usleep(250*1000);
  /* Set DTR and RTS back to high */
  serial_set_dtr_rts(&pgm->fd, 1);
  usleep(50*1000);

  /*
   * drain any extraneous input
   */
  stk500_drain(pgm, 0);

  if (stk500_getsync(pgm) < 0)
    return -1;

  return 0;
}

at this point I think that the ArduinoISP programmer should use "stk500v1" as programmer type to not reset the Arduino Board that is acting as ISP programmer.

[matthijskooijman]

Note that I am not sure this will work on Linux, where I think DTR is automatically asserted by the kernel driver.

Looking through the kernel sources, I believed that this bit of code is responsible for that but it might seem that during serial port open, init_hw is set to 0, which would prevent DTR from being set.

So I guess this just needs a bit of testing, then?

[NicoHood]

No its a windows only problem. And thatswhy its gone for me (dont use it anymore, but used to).
Step 7: https://petervanhoyweghen.wordpress.com/2012/09/16/arduinoisp-on-the-leonardo/
So someone should test if the 32u4 now works with the current(unpatched) IDE ISP sketch under windows (I cant).

[NicoHood]

#1182

[matthijskooijman]

Right, that report explains the problem better. The thing is that changing to use the arduino protocol actually causes DTR to be set (so the @NicoHood has things reversed in the original post in this issue). On an Arduino Uno etc., asserting DTR causes the programming Arduino to reset, which is problematic. On a 32u4 on the other hand, not asserting DTR causes the CDC serial code to drop any packets instead of sending them to the USB host, under the assumption that nobody is listening. I don't think that changing the protocol to arduino will help here, since that will break ArduinoISP for non-32u4 boards AFAIU.

I'll close this as a duplicate of #1182 and continue discussion there.

[NicoHood]

Meh.

The 328 needs a capacitor anyways so it wont reset. So the DTR is not problem here, but for the leonardo it is. And why shouldnt the ISP sketch be used with a leonardo? there are PRs were people want to add due, zero etc support and you cancel this PR because its not made for 32u4 boards?

I see two options here:
Add a 2nd entry for Leonardo as ISP
Keep it like this because the tutorial sais use a capacitor anyways. And I had problem without a cap sometimes, so its better anyways.

Changing the 32u4 code (refering to your edit) could also help. Also it would make sense, because some serial port monitors dont set DTR by default and you wonder why you dont receive anything. Not sure how this affects the IDE.

Its also no duplicate, its a PR for an issue, a solution, not a duplicate.

[matthijskooijman]

Oh, didn't realize that this was as PR, sorry.

The 328 needs a capacitor anyways so it wont reset. So the DTR is not problem here, but for the leonardo it is.

Ok, so that means that using the stk500v1 protocol is not sufficient to prevent DTR from being asserted (perhaps it is still asserted briefly?) on the Uno, which would indicate that using arduino instead of stk500v1 would fix things on the Leo while not breaking them on the Uno (though I guess this needs some thorough cross-platform testing)?

[NicoHood]

Exactly. And thatswhy you can use the arduino protocol for all MCUs.

[NicoHood]

I just tried with an Uno board under linux. The arduino protocol does not work and the stk500 protocol did. The arduino setting might fix the 32u4 boards, but we really should solve the cdc write bug there.

With a capacitor both protocols work though. RTFM and you can use both protocols. Its easier to not use a cap though if you dont have one laying around and want to fix another arduino.

[agdl]

@NicoHood I tried to program an UNO using a Leonardo as ISP with these combinations:

Ubuntu 14.04

arduino with cap works;
arduino without cap works;
stk500v1 with cap works;
stk500v1 without cap works;

Windows 10

arduino with cap works;
arduino without cap works;
stk500v1 with cap doesn't work;
stk500v1 without cap doesn't work;

El Capitan

arduino with cap works;
arduino without cap works;
stk500v1 with cap works;
stk500v1 without cap works;

[NicoHood]

Thx for the tests!

So to conclude:
For an arduino UNO board the patch only improves stuff. A capacitor is not even needed, but from my tests I'd always use one anyways.

However I am wondering why windows 10 did not work with a cap. I tested so many combinations, i might be wrong, but this should work?

Also we have a broken 32u4 as ISP still with this patch, because the write() code of the serial was not patched yet.

[atkenny15]

@agdl I found similar results using a Micro as an ISP to program another Micro. I was only interested in getting Windows to work so I didn't do the whole matrix of testing.

Ubuntu 14.04

stk500v1 without cap works;

Windows 10

arduino without cap works;
stk500v1 without cap doesn't work;

I spent a while struggling to understand why reprogramming wasn't working (not sure if it was a wiring issue, Micro is unsupported as an ISP, etc.) before discovering that it worked fine in Linux. It would be nice to get this change incorporated, or maybe something like the change below that I am using (as suggested here):

arduinomicroasisp.name=Arduino as ISP (micro)
arduinomicroasisp.communication=serial
arduinomicroasisp.protocol=arduino
arduinomicroasisp.speed=19200
arduinomicroasisp.program.protocol=arduino
arduinomicroasisp.program.speed=19200
arduinomicroasisp.program.tool=avrdude
arduinomicroasisp.program.extra_params=-P{serial.port} -b{program.speed}

[per1234]

Since this was already merged in arduino/ArduinoCore-avr@b084848, shouldn't this PR be closed along with #1182?