When does UNO bootloader run?

Apologies for the cross-post. This is probably a better place for my question.

When I have a sketch loaded in the UNO, the bootloader still appears to run when I powerup the UNO using the battery/external power connector (no USB).
I get the three flashes and then the sketch starts after about another half-second.
Is that supposed to happen? Or better yet, how is that supposed to happen?
The optiboot source code indicates that the appStart() function is called directly in any reset case except for an external reset (EXTRF). I understand that after the watchdog timeout, the watchdog reset will result in the bootloader being called again. But, this time the WDRF flag would be set rather than the EXTRF and optiboot would call appStart() right away. That all makes sense.

But, why is it that on power up, optiboot still flashes the LED as if the bootloader has run, then sketch starts as expected?
I would expect (based on the optiboot source code) that on power-on reset, the bootloader would call appStart() right away and not flash the LED 3 times.

Is there something special about the UNO board that when the board powers up it causes an "external reset" instead of a power-on reset?
or
Is perhaps my reading of the source code incorrect?
TheGipp

Didn't you post this same thing yesterday?

I still don't know. Lately I have using File:Upload Using Programmer (with Atmel AVR ISP MKii) and not using the bootloader at all.

How old is your Uno board? Not sure the original Uno bootloader had the 'no wait' on power-up feature to start a prior loaded sketch, but I could be wrong.

I too am finding I use the upload using programmer method more and more these days, especially to run older sketches I'm not fussing with or still developing.
Lefty

It's an R3 board. Just purchased from Jameco last week.
I've checked the bootloader by using avrdude to read the flash and verified the .hex against the current optiboot .hex file - all match.

My mystery is why it's "waiting" on power-up and going into boot mode rather than proceeding straight to the sketch.

I'm wondering if anyone else sees this behavior. Powerup with DC plug and watch the UNO (R3) led and see if it flashes 3 times before your sketch runs.

Thanks for any help

TheGipp

TheGipp:
When I have a sketch loaded in the UNO, the bootloader still appears to run when I powerup the UNO using the battery/external power connector (no USB).
I get the three flashes and then the sketch starts after about another half-second.
Is that supposed to happen? Or better yet, how is that supposed to happen?

Yes, it still runs.

(It has to, if you think about it...)

Does it behave the same if you power it up by connecting via USB?

(In theory, the bootloader only runs when the reset status register identifies the reset cause as "external reset." "Power-on reset" is supposed to be a separate cause, which should not cause the bootloader to run.)

westfw:
Does it behave the same if you power it up by connecting via USB?

(In theory, the bootloader only runs when the reset status register identifies the reset cause as "external reset." "Power-on reset" is supposed to be a separate cause, which should not cause the bootloader to run.)

Yes, either way (via external reset button or power-up via DC plug or power-up via USB) the boot loader runs. And by "runs" I mean it flashes the LED 3 times and continues into the optiboot loop. Not just hit the check for EXTRF and jump to appStart(). So, it's not performing as the optiboot source code implies. It's not doing the "no-wait" on power-up.

Not that it's a big deal. Just trying to understand what I have. And I don't understand it yet. Unless, there is some sort of UNO board circuitry that asserts an external reset on power-up.

Does anyone else see this behavior with a new UNO (R3)?

TheGipp

TheGipp:
Not that it's a big deal. Just trying to understand what I have. And I don't understand it yet. Unless, there is some sort of UNO board circuitry that asserts an external reset on power-up.

Does anyone else see this behavior with a new UNO (R3)?

TheGipp

There is. This is one of the features of the UNO r3. Quoting from the fine manual:

Automatic (Software) Reset
Rather than requiring a physical press of the reset button before an upload, the Arduino Uno is designed in a way that allows it to be reset by software running on a connected computer. One of the hardware flow control lines (DTR) of the ATmega8U2/16U2 is connected to the reset line of the ATmega328 via a 100 nanofarad capacitor. When this line is asserted (taken low), the reset line drops long enough to reset the chip. The Arduino software uses this capability to allow you to upload code by simply pressing the upload button in the Arduino environment. This means that the bootloader can have a shorter timeout, as the lowering of DTR can be well-coordinated with the start of the upload.
This setup has other implications. When the Uno is connected to either a computer running Mac OS X or Linux, it resets each time a connection is made to it from software (via USB). For the following half-second or so, the bootloader is running on the Uno. While it is programmed to ignore malformed data (i.e. anything besides an upload of new code), it will intercept the first few bytes of data sent to the board after a connection is opened. If a sketch running on the board receives one-time configuration or other data when it first starts, make sure that the software with which it communicates waits a second after opening the connection and before sending this data.
The Uno contains a trace that can be cut to disable the auto-reset. The pads on either side of the trace can be soldered together to re-enable it. It's labeled "RESET-EN". You may also be able to disable the auto-reset by connecting a 110 ohm resistor from 5V to the reset line; see this forum thread for details.

Well, my (original generation) Uno does NOT run the bootloader when I plug it into USB.
It's probably not running the official optiboot code, but it should have the same startup code.

I'm mostly curious about what everyone's experience and knowledge is on a non-USB power-up - using the DC jack. In my case the bootloader runs and waits until watchdog time out. However the optiboot source code looks like it is intended to quick start and bypass the waiting in the case of a power-on reset. I understand the circuitry to signal an external reset from the USB port (for the purposes of programming) - that's very slick.

But, I don't see how the power-up via the DC jack is causing an EXTRF (external reset) which triggers the bootloader to wait.

I suspect the DTR autoreset mechanism is causing your bootloader to run on power up. At least I'm fairly confident this is true when a FT232RL chip is present for USB serial. But I'm only speculating that the 16U2 on the Uno behaves similarly.

I demonstrated this to myself by putting an Uno optiboot-flashed 328P on a breadboard and observed that the chip skips the bootloader (no 3 flashes) when power is applied. The 3 flashes show up when the RESET line is taken low, however.

The same chip, when inserted into the socket on an Arduino clone went through the bootloader code each time power was applied from either the DC jack or USB.

My conclusion is that the power up sequence causes a DTR reset. Don't know if it is the result of activity by the FT232RL, or if the RC network on the reset line caused it.

Jim

JimG:
I suspect the DTR autoreset mechanism is causing your bootloader to run on power up. At least I'm fairly confident this is true when a FT232RL chip is present for USB serial. But I'm only speculating that the 16U2 on the Uno behaves similarly.

I demonstrated this to myself by putting an Uno optiboot-flashed 328P on a breadboard and observed that the chip skips the bootloader (no 3 flashes) when power is applied. The 3 flashes show up when the RESET line is taken low, however.

The same chip, when inserted into the socket on an Arduino clone went through the bootloader code each time power was applied from either the DC jack or USB.

My conclusion is that the power up sequence causes a DTR reset. Don't know if it is the result of activity by the FT232RL, or if the RC network on the reset line caused it.

Jim

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?

Lefty

Another source of this unexpected behavior
can be due to the OS and drivers going out and probing the serial port to try to determine the type of
serial device attached.
I know that linux does this. I don't know what Windows or MAC OS do as I don't run either of
those OS's.

So what really is happening (at least on linux) is that the Arduino is powered up when the USB is plugged in.
All the USB enumeration happens along with creating the new virtual tty port, then
the OS & drivers open the serial port (which causes an auto-reset to occur) and probe around trying
to determine what type of serial device is attached.

It is the probing that is causing the "power up" to look like an external reset.

On ubuntu depending on how you have things configured you can even see multiple resets occur
as the serial port is opened multiple times by different things probing the serial port.

--- bill

Bill, my curiousity is mainly without any USB attached (no host computer).
I think Jim' experiment has confirmed my impression that the UNO (R3) cirucuitry is causing the "no-wait" to actually "wait".
Thanks, Jim for the experimentation.
I think that was a clever trial and quite helpful. Again, it's just a curiousity. Not a problem.

I wonder if the Optiboot gurus are curious too.

Cheers to all who contributed to this discussion!

TheGipp

retrolefty:
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?

Lefty

Interesting. That's a pretty hefty pull down.

From m328 spec:
tRST is 2.5us

So if the combination of the pull-down, 100nf auto-reset cap, and 10k pullup
does hold it down for 2.5us before the the 16U2 can turn its
output to high after power up, then an external reset will occur.

HardwareSetup() is called first thing in main() but 2.5us is only 40 instructions at 16Mhz
and a lot of stuff gets done (way more than 40 instructions)
before the pin driving the AVR reset line is initialized.
Plus the 100nf cap has to charge up using the 10k resistor to VCC.
If my math is correct using an RC network of 10k with a .1uf and voltage rising to 4.5 volts
(MAX/worst-case of .9Vcc for reset threshold voltage) That means the RC network
can hold reset down for 2.3ms (milliseconds not microseconds).

Did I get that right?

If so, an extern reset on powerup seems inevitable.

I wonder if these R3 boards ever see a powerup reset?
It would be interesting to see a scope picture of the AVR RESET pin during power.

That auto reset circuitry on the Rev3 board seems like a mess.
Given there is total control over the 16u output line controlling the RESET on the AVR,
I would switch it over to using CTS instead of DTR (1 line change to the 16u2 firmware)
to avoid the need to create an output pulse based on a single transition of a DTR, which creates
so many issues. Avrdude and IDE now already create the needed pulse by driving CTS low then high again.
Then I'd use a single pullup on the AVR reset line and use protection diodes on the 16U2
and RESET header pin inputs.

--- bill

retrolefty:
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

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.

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

retrolefty:

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. :blush: 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

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