Can ATMEGA328P take less than 2.1 seconds to startup?

I want the fastest startup possible. So, at least for now, and for expediency, I decided to excise the bootloader. As an experiment, though, I wrote a simple sketch which does only one thing, and that is turn on the LED that's on pin 9. With no bootloader installed, I expected it would turn on almost instantaneously after I applied power, but actually not. However, there's still an approximately 2.1 second delay (measured on an o-scope) between applying power to the atgmega328p and the LED lighting up. Is it normal for the atmega328p to take that long? What's slowing it down?

In case it matters, the fuse settings I'm using for the atmega328p are: 0xFF 0xDA 0xC2 i.e. I'm running at 8Mhz from the internal resonator, and BOD is turned off. I also tried turning BOD on at the fuse level to see if that might speed it up, but it didn't.

Please advise.

The quick answer is yes, an AT328 without a bootloader will boot considerablely faster than 2.1 seconds - so I would expect that the bootloader is still in place and AFAIK, you can't remove a bootloader from within the IDE.

Exactly how did you "excise" it and then install a new sketch? Please explain the steps you took to get to this point.

  1. I compiled the following sketch:
void setup() {
  pinMode(9, OUTPUT);
  digitalWrite(9, HIGH);
}

void loop() {
}
  1. Then, using AVR Dragon, I first erased the flash memory on an ATMEGA328P, and then I uploaded the hex for the sketch to the atmega328p using the AVR Dragon SPI programmer. There were two hex files that resulted from the compilation: one with a bootloader (about 11K bytes in size), and the other without (about 8K bytes in size). I used the hex file without the bootloader (about 8K in size).

Did you change the bootrst fuse? You ought not have that programmed if not using a bootloader

Actually, I tried the bootrst fuse both ways. Doesn't seem to make a difference which way I set it as far as the 2.1 second delay is concerned.

However, I disabled it again, just to be sure. Again, no difference.

Here are the current fuse settings: BODLEVEL = DISABLED RSTDISBL = [ ] DWEN = [ ] SPIEN = [X] WDTON = [ ] EESAVE = [ ] BOOTSZ = 256W_3F00 BOOTRST = [ ] CKDIV8 = [ ] CKOUT = [ ] SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_0MS

EXTENDED = 0xFF (valid) HIGH = 0xDF (valid) LOW = 0xC2 (valid)

My money is on you thinking you erased the part when you only really erased a portion of the device, most obviously not the bootloader region.

Once again, what did you do and how did you do it? We got the first part but you left out ALL the details. Avrdude? AvrStudio? Further, did you look at the addresses in the hex files? What's the highest address in the code file that you loaded?

Use Avrdude in console mode and look at 7C00 through 7FFF. If everything there shows as an FF, I'd agree that you erased the device. But, I'm betting you didn't.

One last thing... why do you have/show BOOTSZ = 256W_3F00 in a 32k part?

The optiboot bootloader has a "fast start" feature that causes it to bypass the bootloader for a reset cause by poweron. On my Uno-like system, I see startup to "LED lit" that is MUCH faster than 2.1s, even WITH the bootloader present ("instant" by human standards; probably the 65ms+14ck in reality.)

I can't imagine what would cause a 2.1s delay (what is that actually measuring "between"?)

why do you have/show BOOTSZ = 256W_3F00 in a 32k part?

That's the correct value for an Uno with Optiboot (Atmel tools use word addresses rather than byte addresses.) Also, the value is irrelevant unless BOOTRST is set.

westfw: The optiboot bootloader has a "fast start" feature that causes it to bypass the bootloader for a reset cause by poweron. On my Uno-like system, I see startup to "LED lit" that is MUCH faster than 2.1s, even WITH the bootloader present ("instant" by human standards; probably the 65ms+14ck in reality.)

That sounds promising. I'll give that a shot. If nothing else, it would be nice to start on the same page as someone else before removing the bootloader.

westfw: I can't imagine what would cause a 2.1s delay (what is that actually measuring "between"?)

It was 2.1 seconds between applying power and pin 9 going HIGH (see above for the very simple sketch).

westfw: Also, the value is irrelevant unless BOOTRST is set.

Good to know. Thanks for that additional piece of info. :)

Uh, I'd be careful about assuming your board has Opiboot loaded. Unless of course you loaded it yourself - but I've seen no mention of that. Absolutely anything to nothing at all could be preloaded in a Chinese clone.

Westfield - thanks the clarification on the word addressing. I've been working with 8051 derivatives too long...

This is awesome. I just installed Optiboot 6.2, and then loaded the sketch using the serial connection. Wow! Bill was right. Now pin 9 goes HIGH almost instantly after power is applied. I’m really impressed.

Thanks!

Measuring it on an oscilliscope, using Optiboot 6.2, it now takes 15ms from the event of applying power to event of pin 9 going HIGH. So, Bill was right: faster than human perception.

I figure that's 120,000 clock cycles (i.e. 15ms divided by (1/8,000,000)), which from that point of view still seems like a long time. On the other hand, it is quite a bit less than the 65ms+14ck that Bill was guessing above. In theory, how much, if any, improvement should I get by removing Optiboot 6.2 and running just the straight sketch without a bootloader?

"Nonetheless, if just the bootloader were removed, what would be the predicted time interval between poweron and pin 9 going HIGH (assuming the same sketch, of course)?"

Rather than predict, measure the time. Use Arduino as an ISP to get rid of the bootloader.

.

In theory, how much, if any, improvement should I get by removing Optiboot 6.2 and running just the straight sketch without a bootloader?

Very little. Optiboot does the power-on check VERY early, so almost all the startup time is consumed by the hardware reset and oscillator start (controlled by the fuses. The 65ms is the "slow starting crystal oscillator" start time, and you're probably seeing less that that because you've got the fuses set for internal 8MHz clock. IIRC, the startup time is controlled by the WD oscillator; an internal RC "somewhat close to" 128kHz clock.