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?orIs perhaps my reading of the source code incorrect?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...)

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

(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.)

(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.

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.

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.

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?

Another source of this unexpected behaviorcan be due to the OS and drivers going out and probing the serial port to try to determine the type ofserial 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, thenthe OS & drivers open the serial port (which causes an auto-reset to occur) and probe around tryingto 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 occuras the serial port is opened multiple times by different things probing the serial port.

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.

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 pullupdoes hold it down for 2.5us before the the 16U2 can turn itsoutput 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 16Mhzand 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 createsso 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 16U2and RESET header pin inputs.