what happens on Arduino power-on, and how long does it all take?

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Here's how I think it all works and times where I know them.  It's actually mostly not Arduino-specific.  My hope is to eventually get this exact and with good time bounds all filled in,

refinements extremely welcom.

 

* Power-on, input caps to the 328P begin charging and Vcc to the 328P rising

* From the time it first comes to life, internal 328P hardware holds an
internal reset line low.

* Vcc to 328P climbs past the power-on reset voltage threshold V_pot, which has
a maximum value of 1.6V (see the ATmega328P_datasheet_revision_DS40002061A.pdf
Table 29-11).  For a 9V battery with a typical internal resistance of 2 ohms,
the time constant with the ~100 uF of input capacitance on the Arduino
is RC = (2 * 0.0001) = 0.0002 s.  So this normally happens pretty fast,
but note that if additional loads are connected to the Arduino Vcc or Vin
things might take longer.

- A reset timer on 328P begins running.  When it expires the internal reset
line will be released.  How long this timer will run depends on fuse settings.
For the default Arduino fuse settings the timer will run for about 65 ms.
For a 3.3V Arduino variant the typical time will be slightly longer (~69 ms).
See ATmega328P_datasheet_revision_DS40002061A.pdf Table 29-11 Chapter 9
for details.

- The PD7 line of the ATMEGA16U2 chip on on the Arduino holds the external
reset line low past the point in time at which the internal reset is released,
which causes the EXTRF bit of the MCUSR register on 328P the 328P to end up
set (indicating an external reset).  FIXME: does it actually work like this
(hold it low longer)?  FIXME: How long exactly?

- The external reset is released by the ATMEGA16U2

- The bootloader on the 328P begins executing

- The bootloader examines the MCUSR and finds that EXTRF is set, but WDRF
of MCUSR is not set.  It therefore quickly flashes the on-board LED several
times and the attempts to download a new program over the serial line.
This process takes about 1.6 s total.

- The download attempt terminates with a watchdog timer timeout and consequent
watchdog timer reset.  The EXTRF bit of MCUSR remains set (it is sticky and
is only cleared by a power-on reset or explicit 0 write).  Time: pretty quick

- The bootloader starts executing (again).  Time: pretty quick 

- The bootloader examines the MCUSR and finds that the EXTRF and WDRF bits
of the MCUSR are both set.  It interprets this to mean that the bootloader
just executed and terminated due to a watchdog timeout, i.e. it decides that
an upload attempt has already been made.  It therefore clears the WDRF flag
(since it thinks it probably set it itself) and jumps to the start of the
application flash instead of making an upload attempt.  Time: pretty quick

- All the setup code required to provide the C environment your main()
program requires runs.  This includes for example copying global variable
intial values from flash to RAM, etc.  Time: FIXME?

- main() begins executing.

Last Edited: Mon. Nov 2, 2020 - 03:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

- The PD7 line of the ATMEGA16U2 chip on on the Arduino holds the external
reset line low past the point in time at which the internal reset is released,
which causes the EXTRF bit of the MCUSR register on 328P the 328P to end up
set (indicating an external reset).  FIXME: does it actually work like this
(hold it low longer)?  FIXME: How long exactly?

You are exhibiting a lot of faith that the 16u2 resets and begins acting "deliberately" before the 328p does.

 

- The external reset is released by the ATMEGA16U2

I am pretty sure that the 328 RESET is only capacatively coupled to the 16u2, via the nominal "DTR" output (backward compatible with non-smart USB controllers.)

So this is less deterministic than you think.  (let's see - ~8k pullup for the 10k external + 40k internal reset pullup, 0.1uF capacitor...)

 

- The bootloader examines the MCUSR and finds that EXTRF is set, but WDRF
of MCUSR is not set.  It therefore quickly flashes the on-board LED several
times and the attempts to download a new program over the serial line.
This process takes about 1.6 s total.

Sounds about right.  It flashes the LED 3 times over a short period (0.6s?), and then enables a 1s watchdog timeout.

 

 

- The download attempt terminates with a watchdog timer timeout and consequent
watchdog timer reset.  The EXTRF bit of MCUSR remains set (it is sticky and
is only cleared by a power-on reset or explicit 0 write).  Time: pretty quick

- The bootloader starts executing (again).  Time: pretty quick 

- The bootloader examines the MCUSR and finds that the EXTRF and WDRF bits
of the MCUSR are both set.  It interprets this to mean that the bootloader
just executed and terminated due to a watchdog timeout, i.e. it decides that
an upload attempt has already been made.  It therefore clears the WDRF flag
(since it thinks it probably set it itself) and jumps to the start of the
application flash instead of making an upload attempt.  Time: pretty quick

For this stuff, you need to start knowing exactly which version of the bootloader you are running.

Older versions of Optiboot would reset all of the MCUSR bits.

Newer versions attempt to preserve them with a sort of complicated dance to detect the "HW Reset= RUN bootloaer" vs "Watchdog Reset = run application" differences, while still leaving the bits for the application to check.

 

 

- All the setup code required to provide the C environment your main()
program requires runs.  This includes for example copying global variable
intial values from flash to RAM, etc.  Time: FIXME?

- main() begins executing.

Sounds right.  Note that there is only ~2k of RAM.  With a couple of cycles to read and a couple to write and a couple to loop, you're probably still looking at times in the "pretty quick" range.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the point of this exercise?  If your described setup takes over one second of wait/processing time, what difference does 200us switch time for a 9V battery make?

 

Is your Uno hot or cold?  If you restart, there will be less delays, right?  Are we talking about a particular schematic here?  I'd expect to see the 9V switched on to a cold (completely discharged) board, an input tank starts to charge with raw V, input to some type of regulator with varying characteristics, then a regulated V tank starts filling, other tanks (bypass caps etc.) and components begin receiving V including the AVR.  Is this a stripped-down board?  It doesn't sound like it. 

 

And in the end, no real AVR app will not use BOD so all the detail talk of individual electrons in the reset circuit is moot, right?

 

Grab a 'scope, multi-channel makes it easier, and characterize the external levels first.  Does it fit your hypothesis?  If not, figure out why.

 

Hmmm--a logic analyzer that can handle e.g. 9V and has a fairly low trigger threshold could give an octopus of information with a single setup?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Nov 2, 2020 - 12:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And at the completion of this exercise, you will only have 100+ more Arduino's of different types to characterize as different processors will have different startup times. 

How will this info be useful?

 

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"