Stack operation on ATmega164P/324P/644P

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

According to the data sheet for the ATmega164P/324P/644P the PC is 15/16-bits and but calls and interrupts decrement the stack pointer by three bytes. Why this inconsistency and waste of stack space? Or is it a simple error in the data sheet.

This is more than just simple curiosity. In one application I need to walk the stack for some information so it is important that I get the numbers right (and I don't have access to this particular processor (yet).

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

Which page(s) of the data sheet did you get that info from? Save us time looking through it.

edit I found that bit under stack pointer, it seems a typo as the Mega16 and a few others I checked have 2 bytes which makes more sense. Perhaps there is a newer datasheet around with an errata.

edit #2 The April revision still has the same typo. May want to do a formal report to Atmel. The stack increments/decrements by 2 as it should with calls, just did a sanity check with the real hardware and the Dragon.

edit #3 and finally the typo seems to have started with larger chips with a 24 bit address

Quote:
The Stack Pointer is incremented
by one when data is popped from the Stack with the POP instruction, and it is
incremented by two for ATmega640/1280/1281 and three for ATmega2560/2561 when
data is popped from the Stack with return from subroutine RET or return from interrupt
RETI.
and then for the M1284p
Quote:
The Stack Pointer is incremented by one when data is
popped from the Stack with the POP instruction, and it is incremented by three when data is
popped from the Stack with return from subroutine RET or return from interrupt RETI.
which seems ok, so from on every other chips including tiny models will have 3 bytes as they just BLINDLY copy and paste from the latest doc..so it must be right. :(

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Which page(s) of the data sheet did you get that info from? Save us time looking through it.

Sorry. John you are quite right I should have cited the source better.

I have doc8011H-AVR-04/08 and the relevant sections are 6.5 Stack Pointer (are on page 14) and section 7.2 In-System Reprogrammable Flash Program Memory (on page 19).

js wrote:
edit I found that bit under stack pointer, it seems a typo as the Mega16 and a few others I checked have 2 bytes which makes more sense. Perhaps there is a newer datasheet around with an errata.

edit #2 The April revision still has the same typo. May want to do a formal report to Atmel. The stack increments/decrements by 2 as it should with calls, just did a sanity check with the real hardware and the Dragon.


Thank you so much John. I'll e-mail avr support on this and get it the position clarified.

js wrote:
edit #3 and finally the typo seems to have started with larger chips with a 24 bit address
Quote:
The Stack Pointer is incremented
by one when data is popped from the Stack with the POP instruction, and it is
incremented by two for ATmega640/1280/1281 and three for ATmega2560/2561 when
data is popped from the Stack with return from subroutine RET or return from interrupt
RETI.
and then for the M1284p
Quote:
The Stack Pointer is incremented by one when data is
popped from the Stack with the POP instruction, and it is incremented by three when data is
popped from the Stack with return from subroutine RET or return from interrupt RETI.
which seems ok, so from on every other chips including tiny models will have 3 bytes as they just BLINDLY copy and paste from the latest doc..so it must be right. :(

According to another Atmel doc I found 0856E-AVR-11/05 (e.g. page 47 for CALL) there is a direct relationship with the number of bits in the PC. Two byte are pushed for 16 bit PCs and 3 bytes for 22-bit PCs.

My fear was/is that this direct relationship no longer holds for newer devices. I can see it could make more sense for all members of the family to work the same way, even if some members had a smaller PC.

On the evidence of what you've uncovered I'm inclined to think that this is typo in the datasheet(s) and 0856E-AVR-11/0 is still correct. That's a fairly bad typo to have as it affect stack size calculations. And RTOS writes must either know about this or they'll find their RTOS will break on some processor (many RTOSs play with the stack don't they?).

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

You may also want to post it here:
https://www.avrfreaks.net/index.p...

Another freak (Mike B) has a list of typoes too but cant find it now.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I've mailed a support request to Atmel.

Yes, that good idea to post in the Gotcha thread. Had not noticed that sticky before. I'll do that when it's confirmed by Atmel. I wonder how many other devices this affects.

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

This has been confirmed as a typo by Atmel. I've added it to the list