Go Down

Topic: ArduinoISP on Uno requires 10uF cap -- WHY? (Read 5309 times) previous topic - next topic

From http://arduino.cc/en/Tutorial/ArduinoISP:

Quote
5.Wire your Arduino board to the target as shown in the diagram below. (Note for the Arduino Uno: you'll need to add a 10 uF capacitor between reset and ground.)


Can anyone explain electronically WHY this is needed and why it works?  What is it about Uno in particular that causes this problem?  Why 10uF and not 0.1uF or something?

Yes, I tried searching, but couldn't find any good explanations.  Just, "Do this, it works."

tim7

When avrdude connects to the serial port the DTR signal is asserted, which has the side effect of triggering an auto reset.  So avrdude then finds itself talking to the bootloader rather than the ISP sketch.  The capacitor absorbs the auto-reset pulse and allows avrdude to establish proper communication with ArduinoISP.

More recent versions of the Uno bootloader detect corrupt serial communication (the bootloader and ISP sketch use different baud rates) and quit immediately.  This usually allows avrdude to start working properly without need for suppression of the auto-reset.

bperrybap

The sad part is that a very tiny code tweak to the 8u2 code could switch autoreset on the UNO from using DTR to RTS
which would mean that this autoreset on tty port open issue could be avoided altogether.
The original reason that DTR was used over RTS on the early boards was
because to use RTS required changes to Avrdude
to toggle RTS before the download started when using Arduino boards.
Whereas, DTR is asserted (it drops to gnd while the port is open) by the OS when the port is first opened
without the application having to do anything.
The cap turns the DTR drop into a pulse which is used for reseting the AVR.
This allowed auto reset to "work" without any modifications to Avrdude.

Now that Avrdude has been updated to include an "Arduino" protocol that toggles RTS to create the autoreset pulse,
there is no need to use DTR for autoreset anymore.
My view is that the USB to serial AVR chip code should be tweaked to use RTS rather than DTR.
It is a very small code change.

I prefer using RTS over DTR because it allows opening the serial port without resetting the AVR
but yet still allows autoreset to reset the AVR for uploading new code.

--- bill

Ok, fascinating, thanks.  But what is it about UNO in particular?  This is not needed on Duemilanove or the Arduino Pro.

bperrybap

Slightly different autoreset circuit.
Because of the different autoreset circuit on Uno, the hack to crater it into not functioning (disabling autoreset) is different.

If you look at the Uno Rev2 and Rev3 schematic there is now a pulldown on the signal
line from the 8/16u part going into the cap that goes to the reset line on the AVR.
The signal line from the FTDI chip (or the DTR connector pin on the pro) going to the cap does not have a pull down on it.
If I remember correctly, I believe this was added after it was shown that because of the simplistic circuit
that under certain conditions of using the RESET line, severe ringing with overshoot occurred
on the AVR reset line and bricked the AVR by tricking it into thinking it was going into high voltage programming mode.


I think the arduino 2009 had the best circuit.  If the RESET-EN jumper is desoldered or c13 is removed and then r2 is
in place then RTS can be used instead of DTR and all this mess goes away including the ringing issue.

On the pro you have the option to  simply re-wire your serial adapter to use RTS and feed that into the DTR pin on the connector
to avoid the need to disable auto reset.

--- bill

SirNickity

I'm really glad someone brought this up.  I hate doing things and not understanding why.  Thanks everyone for the thorough explanations.

Quote
My view is that the USB to serial AVR chip code should be tweaked to use RTS rather than DTR.


Six-pin FTDI cables don't have RTS pins.  Just DTR (and CTS).

bperrybap


I'm really glad someone brought this up.  I hate doing things and not understanding why.  Thanks everyone for the thorough explanations.

Quote
My view is that the USB to serial AVR chip code should be tweaked to use RTS rather than DTR.


Six-pin FTDI cables don't have RTS pins.  Just DTR (and CTS).



Ummm.... Go have a another look at the FTDI 6 pin connector pinout.
Here is a link to the data sheet. See pages 17 and 19.
http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf
DTR is not on the 6 pin cable. It uses RTS instead.
Even the label on the Arduino Pro board labeled it correctly as RTS with respect to a standard 6 pin
FTDI cable.
http://arduino.cc/it/Main/ArduinoBoardPro




But all this is irrelevant with respect to the code inside the 8u/16u AVR chip that has replaced the FTDI chip
for the USB to serial conversion.
To switch to using RTS instead of DTR is a simple code change inside the 8u/16u AVR chip to use the RTS status bit in the messages
vs the DTR bit when driving the output that goes to the other AVR reset pin.


--- bill

SirNickity


westfw

Quote
USB to serial AVR chip code should be tweaked to use RTS

If we're going to fiddle with the 8u2 and "arduino" programmer type in avrdude, I'd like to get away from using rs232 signals at all.  I think PaulS suggested picking a rare and uncommon bitrate, and resetting the Arduino AVR when that was set.

OTOH, "backward compatibility with 500,000 existing Arduinos..."

Quote
what is it about UNO in particular?

Different and Dumber bootloader, running at a different bitrate.  Possibly a newer version of Avrdude in newer IDE releases.
Prior to Uno, the Bootloader would exit quickly when it saw "illegal" commands.  The Uno bootloader isn't smart enough to check for illegal commands (although the most recent version can check for improperly received commands, as "probably" occur when commands are received at the wrong speed.)

kf2qd

Another reason is that there have been attempts to reduce the size of the bootloader. The smaller it is, the less bells and whistles. Could add all kinds of capabilities to it, but that would just lead to complaints doe to the amount of memory that it would use.

Go Up