Folks, I have been playing a bit with Atmega328 and ATtiny processors, but in trying to understand them, it would help a lot if I can get the answer to a really basic question : When a brand new, unprogrammed AVR processor is powered on for the first time, what does it do?

Computers I have worked with in the past, when powered on, did basically one thing : they started executing instructions, starting at memory location zero.

Now the reason why I ask about the AVR :
I bought a Teensy2 - an Arduino lookalike based on the Atmega32U4, with a USB connector and a boot loader on the chip. I wrote a little assembler program on it using Atmel's Studio-7 IDE, but when I was going to compile it, it asked if I wanted it to start at address zero. There wasn't an option to say where else I might want it, so I said No, in case it overwrote the boot loader, which I imagined at that time, must be at location 0x0000. Seemingly, it did overwrite it anyway, because although my program ran when the chip was powered on, it had lost the ability to communicate with my PC. I contacted the people responsible for the Teeny, but it turned out mine was a clone, and not supported by them. However, they mentioned that on their product, all user programs run from address zero, and the boot loader is at the top of memory - so does the AVR core store the place to start from when powered up, in non-volatile memory - probably fuse-protected?

 

All of the 8-bit AVR devices have a series of "vectors" which point to locations in "program" memory (aka FLASH) where things are to be located. How you find this out is by downloading and READING the datasheet. Sometimes you have to go over it multiple times before you find the "pearls".

"Pearls" -- Items of information that you need hidden in a 438 page datasheet. Let's take the ATMega32U4

http://www.atmel.com/Images/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf

I draw your attention to page 63 which has a list of "Interrupt" Vectors. A "vector" in this context is simply a pointer to an address in Program Memory where the processor should go. In this regard Power On RESET is treated like an interrupt, and control is transferred to address $0000. Notice the footnote(1).

Note (1) says
When the BOOTRST Fuse is programmed, the device will jump to the Boot Loader address at reset, see
“Memory Programming” on page 353.

I draw your attention the following page, p. 354, Table 28-3, where you will find the HWBE(Hardware Boot Enable) bit.

Moving right along to p. 81, §10.3.4 Alternate Functions of Port E, where the table describes the operation of PE2 as HWB*. This active low signal will take you to the alternate RESET vector, which is where the boot loader is located, when this signal is low after power up reset. Congratulations you just overwrote the bootloader.

This is still not the end of the story, go to p. 340 and read §27.5.2 Boot Reset Fuse, in which the Boot Loader Reset Vector is describe in table 27-8 on p. 349

On p. 349, in table 27-8, you will see the location of the bootloader and the location of the alternate set of vectors (interrupt and RESET). For a maximal size bootloader, the RESET vector is at address 0x3800.

Does that clear things up or did I just confuse the ALS out of you?
I made a claim in another thread that there was no question about microcontrollers that I cannot ferret out with enough time and patience. I repeat that claim here.

 

All of the 8-bit AVR devices have a series of "vectors" which point to locations in "program" memory (aka FLASH) where things are to be located. How you find this out is by downloading and READING the datasheet. Sometimes you have to go over it multiple times before you find the "pearls".

Thank you so much for this very full reply. I gather you've been around uControllers a bit before! I bow down in worship.
Before anybody can work this stuff out, they have to have a pretty in-depth knowledge of the capabilities of the processor, and a good understanding of what each of those features does. In short, you have to almost know the datasheet off by heart. It took me a good 45 minutes just to read through your explanation and get some sort of inkling of what it all meant. I wonder how long it would have taken me without help.
What convoluted minds the designers must have!

Lucky I only asked a naive question. Thank goodness it wasn't a complicated one.

 

Thank you so much for this very full reply. I gather you've been around uControllers a bit before! I bow down in worship.
Before anybody can work this stuff out, they have to have a pretty in-depth knowledge of the capabilities of the processor, and a good understanding of what each of those features does. In short, you have to almost know the datasheet off by heart. It took me a good 45 minutes just to read through your explanation and get some sort of inkling of what it all meant. I wonder how long it would have taken me without help.
What convoluted minds the designers must have!

Lucky I only asked a naive question. Thank goodness it wasn't a complicated one.

As you might suspect, this ability did not spring up overnight. In the early days (ca. 1971) datasheets were a good deal less comprehensive and we had to build our own tools for assembling and debugging code. There are certain basics that a part must have and I have seldom seen a product come to market where there were details that were overlooked. As time marched on, manufacturers got better at adding modular features and DOCUMENTING them in a regular way. As I was familiar with the AVR and ATMega families, I pretty much knew where to look. I guess I didn't confuse the ALS out of you. Congrats on your industry.