Stack managment

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

Hello ,

i have to questions about the stack 

 

1) if i have a stack and i want to know places that i used in it and the places that i never used , how could i do that ?

2)if i have a stack over flow and i need to increase the stack size , how to know the exact size needed ?

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

1) Google " stack painting" (might also be "ram painting")

 

2) which C compiler are you talking about? If avr-gcc then it always defaults to "all free RAM" anyway (simply because SP starts as far from the end if BSS as it can)

 

If it is avr-gcc you are talking about then your only real concern is that the SP "low water mark" never impinges on the upper limit if BSS

 

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

amr01 wrote:
2)if i have a stack over flow and i need to increase the stack size , how to know the exact size needed ?
When?  (not if)

By calculation though there are tools to compute the maximum stack size; the tools may not be as complete if the application's source code has function pointers and/or recursion.

 

Mastering stack and heap for system reliability: Part 1 – Calculating stack size - Embedded.com

How to Prevent and Detect Stack Overflow | Barr Group

On Stacks - The Embedded Muse 309

GNATstack - Adacore

AVR | 7. Machine Specific Topics — GNATstack 20.0w documentation

Other stack-usage analysis tools

Are We Shooting Ourselves in the Foot with Stack Overflow? « State Space

Hardware Features | The Embeddded Muse 231

Re: above article, though AVR doesn't have the built-in stack overflow detection capability of PIC24 and dsPIC, some AVR OCD have enough data address comparators to detect stack overflow :

Atmel Studio 7 - Stack Overflow Detection Using Data Breakpoint

 

"Dare to be naïve." - Buckminster Fuller

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

You cannot control the stack size in a an AVR. Your only control is your method of coding. And, watching the memory use metric in the build output.

 

That said, there have been several routines posted on this list for "memory painting". These write some standard value (often 0x55, because of alternating bits, I think) to the RAM. Then, after it has run awhile or you have put  it through its paces (serial interface, menus, uSD access, and such, that might maximize the stack), break execution in the debugger and scan the RAM. If there is a block of paint bytes, then you know that the stack has not run into data. If there is no block of paint bytes, then get your axe out and start hacking.

 

One of the first places I always look is for constant strings which, by default, are copied from FLASH to RAM on boot up, then read out of RAM. There are some substitute functions that read constant strings directly out of flash and do not use the RAM intermediate memory. For me, paying attention to that usually saves a bunch of RAM.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sun. Oct 20, 2019 - 11:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You cannot control the stack size in a an AVR.

Well, at least in assembler, you can set the SPH/SPL to something other than the very end of ram...so giving it less room before crashing into other variables.   

In either case, once the stack runs out of room, your program is toast!  The memory painting sounds like a good sanity check.  I'd vote for painting in a byte count 1 2 3 4 5...to get a rough idea & slightly easier way to count 'em

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

ka7ehk wrote:
You cannot control the stack size in a an AVR.
Jim, actually you can because some of the C compilers for AVR use TWO stacks. The hardware stack is used for CALL/RET/PUSH/POP but a separate memory area is used for the data stack (local variables) and is created using an index register. The size set aside for this is usually definable. So, yes, sometimes the stack size can be changed. That is why I asked:

clawson wrote:
2) which C compiler are you talking about?

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

Fair point. Should have asked.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net