Go Down

Topic: When does UNO bootloader run? (Read 4 times) previous topic - next topic

JimG


Well the Uno in rev2 and the present rev3 did add a 1K ohm pull-down resistor on the DTR output pin from the 16U2 chip that the older arduino 2009 board did not use on the FTDI DTR output. I wonder if that pull-down resistor keeps the 328p reset pin low long enough after initial power-up to cause a true pin1 external reset condition and thus activation the bootloader wait period to be active?

Just to be clear, the tests I did were not on Uno boards.  I did my testing on a clone board modeled after the original issue Uno, but with FT232RL instead of the 8U2 for USB-serial.  The 1K pull-down you mention is not on my board, but it does have the clamping diode on the RESET line that was added to later Uno's.

Jim
TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

westfw

Quote
Did I get that right?

No.  There are pretty complicated algorithms involving invisible timers that come into play, both for the reset itself, and for starting the CPU AFTER the reset has occurred, so instruction execution doesn't start immediately after the  power level meets some voltage.  The way I read it, on powerup it waits for 16k clock cycles to occur, and then does the reset processing which uses the WD oscillator to time about 65ms (for the way Uno fuses are set.)  An external reset only does the second half, since the oscillator is assumed to already be running.

retrolefty

Quote
Avrdude and IDE now already create the needed pulse by driving CTS low then high again.



I thought for legacy reasons that AVRDUDE and/or IDE pulsed both DTR and RTS comm signal lines so that either could be used to trigger the auto-reset circuit, but not CTS?

Lefty

bperrybap


Quote
Avrdude and IDE now already create the needed pulse by driving CTS low then high again.



I thought for legacy reasons that AVRDUDE and/or IDE pulsed both DTR and RTS comm signal lines so that either could be used to trigger the auto-reset circuit, but not CTS?

Lefty

oops.  :smiley-red: It is RTS not CTS. Total goof on my part. (CTS is on receiving end)
BUT.... DTR is not pulsed. It merely changes state (drops) on the first open and then changes
back (back to high) on the last close of the serial port. The transition is handled by the OS
not the application.
But in the larger picture, I don't understand why DTR is still being used for auto-reset
now that there is RTS toggle support for auto-reset as
turning a falling edge into a pulse is what complicates things so much.
Plus s/w like the IDE and AVRdude have no control over this DTR transition, it happens
*before* they have control over the serial port because it happens in the OS driver when
when the serial port is opened/closed.
If things were just switched over to using RTS instead of DTR things get much simpler
AND you don't get an auto-reset when you simply open the port.
You have to explicitly toggle RTS after the serial port is opened to get the auto-rest.
I use this on my boards and it is very nice. I get the auto-reset when the IDE
wants to upload a sketch but I don't get it when the serial port is opened
for communication.

IMO, RTS is the way to go. It allows control of the auto-reset.
I understand why DTR was initially used as it was a h/w hack that worked
before the IDE/Avrdude software was modified to control RTS. But now that the s/w
toggles RTS, why use DTR anymore?

--- bill

retrolefty

Quote
IMO, RTS is the way to go. It allows control of the auto-reset.
I understand why DTR was initially used as it was a h/w hack that worked
before the IDE/Avrdude software was modified to control RTS. But now that the s/w
toggles RTS, why use DTR anymore?

--- bill


I believe if you research back carefully to the very first arduino boards produced that included a auto-reset function that RTS only was signal used, and then later boards changed that to use DTR instead. I never read a reason for the original choice they used and why the later change, but now they are kind of stuck to having to send both RTS and DTR from the IDE and or AVRDUDE to be able to support all possible legacy boards. At least that is my take on the history of the now infamous auto-reset feature, which has had a pretty wild journey to present.

Lefty

bperrybap


Quote
IMO, RTS is the way to go. It allows control of the auto-reset.
I understand why DTR was initially used as it was a h/w hack that worked
before the IDE/Avrdude software was modified to control RTS. But now that the s/w
toggles RTS, why use DTR anymore?

--- bill


I believe if you research back carefully to the very first arduino boards produced that included a auto-reset function that RTS only was signal used, and then later boards changed that to use DTR instead. I never read a reason for the original choice they used and why the later change, but now they are kind of stuck to having to send both RTS and DTR from the IDE and or AVRDUDE to be able to support all possible legacy boards. At least that is my take on the history of the now infamous auto-reset feature, which has had a pretty wild journey to present.

Lefty

I don't know the exact history either, but my guess is that
that DTR was chosen as it was simple to implement and
had no impact on s/w whereas RTS required software updates.
I do know that RTS is what the OEM FTDI USB to TTL serial cable uses so when that starting
being used, it required updated s/w to support toggling RTS.
But while the IDE and AVRDUDE must continue to support both,
the hardware going forward could now use RTS instead of DTR.

I prefer using RTS because it doesn't reset the AVR when the serial port
is opened but auto-reset still works for an upload.

--- bill

TheGipp

Interesting discovery....

I've just built my own DAPA programming cable and used it successfully with avrdude.

During that process (before running avrdude) I noticed that with the UNO board powered by battery (no USB connection) with the ISP connected via the DAPA cable to my computer's parallel port, the bootloader does NOT run on power up.  To double check I unplugged the ISP connector and cycled battery power.  The bootloader runs.  Plug the ISP cable back in and cycle battery power, the bootloader does not run.

avrdude functions properly with my ISP DAPA connection and when it's done, the sketch starts (again without bootloader running).

Please note, when I say bootloader not running I mean that it does not fall into the flash LED 3 times and into the loop waiting for serial data.  Instead it appears to jump into the sketch as the "quickboot" feature should.

My conclusion is that having the ISP connected via DAPA cable to my computer puts some different capacitance/load on the RESET line and somehow makes the "external RESET" assertion not occur.

Maybe an EE can confirm that possibility?

All-in-all, a curiosity..  Nothing troubling.

TheGipp

Nick Gammon

Using an R3 Uno I find this after plugging in a battery and with nothing else connected (except the logic analyzer):



Note 3 flashes of D13 pin.




Zooming in:



It appears that reset is raised (high) 423 uS after the power comes on.

I wonder though, if power comes high first, and then reset, it may count as an external reset rather than a power-on reset.
http://www.gammon.com.au/electronics

Nick Gammon

This is the +5V vs Reset on the scope:


http://www.gammon.com.au/electronics

Go Up