Optiboot and SP initialization assumption

Hi guys, I'm new to the forum and quite new to the ATMEL MCUs world anyway I have some basis on C and ASM languages. I have some Arduino UNO board and also some standalone ATMEGA328P-PU chips so, in order to learn these a bit deeper, I'm studying the datasheet and the Optiboot too.

I have a question about the Optiboot assumption that "SP points to RAMEND": in the datasheet I can read:

  • the SP must be initialized by the user program "in the Reset routine (before subroutines or interrupts are executed)"
  • if the high fuse BOOTRST bit is programmed then the Reset vector points to the start of the bootloader flash section and, as far as I know, this is the case for the UNO board with the Optiboot installed, correct?

Now, if all above is correct, this tells me that the very 1st code running after a MCU reset is the Optiboot code so: could anybody please explain how the Optiboot can safely assume that "SP points to RAMEND"? When and where does it assume the SP is initialized to RAMEND?

By the way, in the Optiboot code I can see instruction:

#ifdef __AVR_ATmega8__
  SP=RAMEND;  // This is done by hardware reset

which initializes the SP but as I can see in the .lst file (disassembled code) this is not considered for the ATMEGA328P..

Thanks very much in advance for the explanation.

I found this in the data sheet:

Initial Stack Pointer value equals the last address of the internal SRAM...

I think this answers the question

Hi Olf2012 and thank you for your answer.

So you say that the meaning of the phrase you highlighted is that the SP is automatically initialized by HW to RAMEND at startup, correct?

Yes, this would justify the Optiboot assumption but then I couldn't explain the meaning of other parts of the datasheet, i.e.:

  • par 7.1:

All user programs must initialize the SP in the Reset routine (before subroutines or interrupts are executed)

  • par 7.5, the phrase just before the one you highlighted:

The Stack in the data SRAM must be defined by the program before any subroutine calls are executed or interrupts are enabled

  • and also, all ASM examples showing RESET sample routines (chapter 12) perform, first of all, an explicit initialization of the SP to RAMEND

All above seems to confirm that it's user code duty (and the bootloader is user code as well) to, first of all, explicitly initialize SP to RAMEND.

So, this wouldn't make sense if the SP is already initialized to RAMEND by HW, would it?!

Thanks and bye!

Earlier chips did not initialize the SP (ie Atmega8); I suspect that the verbiage dates to prior versions (You'll note that the text is very generic, including info about chips with SPL only.) The register description (7.5.1) is quite clear that SP is initialized on reset to RAMEND.

(and, you'll note that it works... :-))

Hello westfw, thank you very much for your reply and let me congratulate with you for your great work with the Optiboot!

So, you are saying that in newer chips (i.e. the 328p) the SP is automatically initialized to RAMEND by HW and that all references to explicit SP initialization requirements are a kind of backward baggage inherited by datasheets of older MCUs which are not really needed in the newer ones, correct?

Effectively I downloaded the ATMEGA8 datasheet and there I can see the SP initial value is specified as 0 and not as RAMEND like in the 328P datasheet.

That seem anyway a lack of precision by ATMEL which can be quite confusing particularly for newbies like me… :slight_smile:

Thank you very much for your clarification!

Correct. I don't know if it's ALL new chips; check the register definitions to be sure (and note that other architectures handle things differently.) Atmel Data sheets can be pretty awful, and the sad thing is that they are probably among the better datasheets that I've read. (latest gripe: look in the ATmega328PB datasheet for info on the second UART and I2C interface...)

(and there's also the "JMP and CALL are only available on 168PA and 328P" (instruction set summary) when in fact they work on the variants with more than 8k program space. (168, 168A, 328 as well.))