Autoreset Circuit on Uno

Hi There,

I'm mildly confused as to how the autoreset circuit works on the arduino uno. I assume DTR goes low when the serial transmission from the PC begins. That discharges the 100 nF cap which pulls the reset line low. With a time constant determined by the 10k pullup to 5V and the 100 nF cap the cap will recharge and the reset line will be high. I assume that the bootloader takes over right after the reset line goes high at which point it slurps up whatever it gets over the serial line as program code and then resets the processors instruction pointer. Is that correct? Is there any indication when programming is complete? How long is DTR pulled low for (I don't have a scope :(). Thanks!

D

doov:
Hi There,

I'm mildly confused as to how the autoreset circuit works on the arduino uno. I assume DTR goes low when the serial transmission from the PC begins. That discharges the 100 nF cap which pulls the reset line low. With a time constant determined by the 10k pullup to 5V and the 100 nF cap the cap will recharge and the reset line will be high. I assume that the bootloader takes over right after the reset line goes high at which point it slurps up whatever it gets over the serial line as program code and then resets the processors instruction pointer. Is that correct? Is there any indication when programming is complete? How long is DTR pulled low for (I don't have a scope :(). Thanks!

D

Yes that is basically how it works. The IDE (via AVRDUDE) just pulses the DTR signal on then off to cause the AVR to reset (it also pulses the RTS signal which older boards used instead of DTR) which starts the bootloader code that then communicates to the IDE via AVRDUDE to actually then start the upload data transactions, which when completed the bootloader jumps to the sketches start in flash memory. If the bootloader gets no proper response from AVRDUDE after a specific time out period and if there is already an existing sketch loaded some prior time then the bootload jumps to the program.

Awesome! Thanks for the info. Is there any pin that goes high/low to indicate that avrdude and the arduino finished programming and everything is good (besides the sketch running)? I'd like to use that to enable a bluetooth modem which sits on the uart. If it's enabled during programming then it screws with avrdude (presumably because it's driving the tx line at the same time that avrdude is trying to drive the same line.). Thanks!

doov:
Awesome! Thanks for the info. Is there any pin that goes high/low to indicate that avrdude and the arduino finished programming and everything is good (besides the sketch running)?

Nope.

doov:
I'd like to use that to enable a bluetooth modem which sits on the uart. If it's enabled during programming then it screws with avrdude (presumably because it's driving the tx line at the same time that avrdude is trying to drive the same line.). Thanks!

You should probably wire it so it can be switched on/off via the Arduino and power it on in your setup() function.

doov:
Awesome! Thanks for the info. Is there any pin that goes high/low to indicate that avrdude and the arduino finished programming and everything is good (besides the sketch running)? I'd like to use that to enable a bluetooth modem which sits on the uart. If it's enabled during programming then it screws with avrdude (presumably because it's driving the tx line at the same time that avrdude is trying to drive the same line.). Thanks!

No there is not. There is a upload completed message printed on the IDE status line if there are no errors. If you have an extra I/O pin you could just use one to light a led in the setup part of the sketch to signal that the sketch has started, and analog input pins can be used as extra digital pins if pin counts get short.

Lefty

Great. Thanks a lot for the info guys. Much appreciated.

retrolefty:

doov:
Hi There,

I'm mildly confused as to how the autoreset circuit works on the arduino uno. I assume DTR goes low when the serial transmission from the PC begins. That discharges the 100 nF cap which pulls the reset line low. With a time constant determined by the 10k pullup to 5V and the 100 nF cap the cap will recharge and the reset line will be high. I assume that the bootloader takes over right after the reset line goes high at which point it slurps up whatever it gets over the serial line as program code and then resets the processors instruction pointer. Is that correct? Is there any indication when programming is complete? How long is DTR pulled low for (I don't have a scope :(). Thanks!

D

Yes that is basically how it works. The IDE (via AVRDUDE) just pulses the DTR signal on then off to cause the AVR to reset

Not exactly.
The DTR signal is not pulsed. It is a level.
DTR is set by the OS when the serial port is opened before the application gets control of the serial port.
By default DTR is high.The OS sets DTR low (not the application) when the first open occurs
and then back to high when the last close occurs.
DTR is used as a single to know if there is anything attached to the serial interface.
High - nothing is there. Low something is there listening.
The capacitor is a h/w kludge that turns the falling edge of the DTR signal into a pulse
to reset the AVR.

Some operating system have the ability to change this DTR behavior but normally
that is the way DTR works.

RTS on the other hand is normally used for hardware flow control but the application
can control its level after the the application has opened the serial port.
The IDE or avrdude can pulse RTS - which they do to perform an auto reset,
because some hardware uses RTS vs DTR.

Some Arduino boards use DTR some use RTS.

Summary:
OS changes DTR from high to low when application opens port before application
has control of port. Capacitor is used to change falling edge to pulse.
RTS is used for h/w flow control but can be controlled by application after port is opened.

The IDE and avrdude upload can work with boards that use DTR or RTS for autoreset.

I prefer RTS over DTR for autoreset because with RTS you only get an autoreset when
code is being uploaded to the board.
But with DTR you get an autoreset every time the port is opened by an
application which means you can't open the serial port to talk to the arduino without reseting it.

--- bill

bperrybap:
I prefer RTS over DTR for autoreset because with RTS you only get an autoreset when
code is being uploaded to the board.
But with DTR you get an autoreset every time the port is opened by an
application which means you can't open the serial port to talk to the arduino without reseting it.

An interesting twist on the brain-deadedness of using DTR rather than RTS is a phenonemon I discovered only recently: On some Windows systems, connecting or disconnecting another device on a different USB port can cause the DTR reset to occur on a USB connected Arduino! Coding Badly suggested this may be due to a background "helper" application that probes the USB ports whenever a system change is reported by the OS, although on my system in question I haven't been able to identify the culprit.

Sheesh. Why did the change from using RTS to DTR occur anyway? Was there actually a rationale, or was it just one of the random "design" decisions passed on without explanation or prior discussion from On High?

RTS and DTR are a little more bizarre than I thought. I have both an FTDI cable [uses RTS] and
an FTDI Friend [uses DTR]. Don't have the scope handy, but using the DMM, where S-M means Serial
Monitor,

FTDI Cable: RTS=0V [steady] when S-M=off, RTS=5V [steady], when S-M=on.

FTDI Friend: DTR=5V [steady] when S-M=off, DTR=0V [steady], when S-M=on.

So, don't leave out the 100nF cap whatever you do.

Quote from: doov on Today at 05:29:49 PM
I'd like to use that to enable a bluetooth modem which sits on the uart. If it's enabled during programming then it screws with avrdude (presumably because it's driving the tx line at the same time that avrdude is trying to drive the same line.). Thanks!

You should probably wire it so it can be switched on/off via the Arduino and power it on in your setup() function.

Yeah, you cannot really have BT or XBee connected to the Arduino RX line at the same time as the standard
USB port, because the 2 signals conflict, so some XBee shields at least have a switch.

doov:
I'd like to use that to enable a bluetooth modem which sits on the uart. If it's enabled during programming then it screws with avrdude (presumably because it's driving the tx line at the same time that avrdude is trying to drive the same line.). Thanks!

If you use an Arduino Leonardo instead of a Uno (if that is what you are using), then uploading a program to it does not use the serial port, and the problem will not occur.

retrolefty:

doov:
Hi There,

I'm mildly confused as to how the autoreset circuit works on the arduino uno. I assume DTR goes low when the serial transmission from the PC begins. That discharges the 100 nF cap which pulls the reset line low. With a time constant determined by the 10k pullup to 5V and the 100 nF cap the cap will recharge and the reset line will be high. I assume that the bootloader takes over right after the reset line goes high at which point it slurps up whatever it gets over the serial line as program code and then resets the processors instruction pointer. Is that correct? Is there any indication when programming is complete? How long is DTR pulled low for (I don't have a scope :(). Thanks!

D

Yes that is basically how it works. The IDE (via AVRDUDE) just pulses the DTR signal on then off to cause the AVR to reset (it also pulses the RTS signal which older boards used instead of DTR) which starts the bootloader code that then communicates to the IDE via AVRDUDE to actually then start the upload data transactions, which when completed the bootloader jumps to the sketches start in flash memory. If the bootloader gets no proper response from AVRDUDE after a specific time out period and if there is already an existing sketch loaded some prior time then the bootload jumps to the program.

Can you program other pre-upload conditions into AVRDUDE? I'm wondering if it could send a specific text sequence that a bluetooth serial connected arduino could interpret to self reset prior to being programmed over BT connection?

Riva:
Can you program other pre-upload conditions into AVRDUDE? I'm wondering if it could send a specific text sequence that a bluetooth serial connected arduino could interpret to self reset prior to being programmed over BT connection?

Yes, but avrdude is a pretty complex program.
A much easier way is to write a wrapper that gets run instead of avrdude.
The wrapper can do it's magic thing then run avrdude.

--- bill

bperrybap:

Riva:
Can you program other pre-upload conditions into AVRDUDE? I'm wondering if it could send a specific text sequence that a bluetooth serial connected arduino could interpret to self reset prior to being programmed over BT connection?

Yes, but avrdude is a pretty complex program.
A much easier way is to write a wrapper that gets run instead of avrdude.
The wrapper can do it's magic thing then run avrdude.

The downside of this is I either have to hack Arduino IDE to use wrapper instead of AVRDUDE or rename AVRDUDE and call my wrapper by the same name. Both then have the problem of reverting to normal AVRDUDE for standard USB connected devices.
Could one just add a new programmer definition to AVRDUDE that's basically a duplicate of maybe the stk500v1 protocol but with the prefix string needed to reboot BT attached arduino and then add another programmer definition to the Arduino programmers.txt file.

Riva:
The downside of this is I either have to hack Arduino IDE to use wrapper instead of AVRDUDE or rename AVRDUDE and call my wrapper by the same name. Both then have the problem of reverting to normal AVRDUDE for standard USB connected devices.
Could one just add a new programmer definition to AVRDUDE that's basically a duplicate of maybe the stk500v1 protocol but with the prefix string needed to reboot BT attached arduino and then add another programmer definition to the Arduino programmers.txt file.

I have done this very thing to get the chipkit uno32 auto-reset working on the Arduino 1.5 IDE
when I moved the pic32 core over to the latest Arduino IDE.

In Arduino 1.5 you can specify the name of the uploader
program so you really don't have to rename it.

I simply renamed the original avrdude command, then I created a simple bash shell script.
It runs a few extra commands then passes the same arguments it received
on to the original/real avrdude command.
Easy Peasy...

The wrapper can be as smart as is needed.
It can look at any of the avrdude arguments and make decisions
on what to do based on those arguments before it passes
them on to avrdude.
Depending on the arguments, it could choose to do nothing before running avrdude.

The reason I went with a wrapper is that it is minimizes the changes necessary
to the IDE tree. No changes to boards.txt, no changes to platform.txt
just rename the original avrdude and insert a shell script.


As far as adding a new programmer/protocol to avrdude. Yes it can be done
but have you looked at the avrdude code? It isn't as simple as you might think.
Plus you have to have the tools to rebuild it.
While not hard in a unix/linux environment its not so easy for Windows environments.
And then you may have to create special boards.txt entries to use the new protocol/programmer
I see this route as more work vs creating a wrapper.

--- bill