Pages: [1] 2   Go Down
Author Topic: When does UNO bootloader run?  (Read 3684 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 9
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Global Moderator
Boston area, metrowest
Offline Offline
Brattain Member
*****
Karma: 512
Posts: 26202
Author of "Arduino for Teens". Available for Design & Build services. Now with Unlimited Eagle board sizes!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17253
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
« Last Edit: October 09, 2012, 01:35:17 pm by retrolefty » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 9
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

Valencia, Spain
Online Online
Faraday Member
**
Karma: 142
Posts: 5275
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 124
Posts: 6632
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Offline Offline
Newbie
*
Karma: 0
Posts: 9
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Ayer, Massachusetts, USA
Offline Offline
Edison Member
*
Karma: 53
Posts: 1827
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 124
Posts: 6632
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Offline Offline
Newbie
*
Karma: 0
Posts: 9
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Kentucky, US
Offline Offline
Full Member
***
Karma: 1
Posts: 193
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

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

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17253
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 62
Posts: 2635
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 9
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


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
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 62
Posts: 2635
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


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


Logged

Pages: [1] 2   Go Up
Jump to: