Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Call Stack General Question

Status
Not open for further replies.

electroRF

Member
Hi,

I have a general question on Call Stack of Embedded uCs.

The Call Stack should include all the Active Sub-routines.

For example, in the following sequence:

Code:
Func 1 Start ---> Func 2 Start --> Func 3 Start ---> YOU ARE HERE

The Stack should include the Return Addresses of Func 2's Body and Func 1's Body,

Right?

At any certain moment (e.g. when the uC experiencing a SW Bug), Is it possible to have the uC to get all the Active Sub-Routines from the Stack and print them (e.g. for knowing it at the moment of Bug)?

It'd help me debug failures, when I don't work with a Debugger.

I know that Debuggers do that - i.e. show you the Call Stack at each moment - So I am wondering if I can get the uC to to it for me every time a bug occurs.

Thank you :)
 
The hardware stack on 16F is not readable nor writeable. Program memory addresses are "pushed" onto the stack in the event of a 'call' or an interrupt. They are then "popped" off of the stack and back into the program counter upon returning from a call or returning from an interrupt in the reverse order of the push (LIFO, or "Last In First Out").

I believe the stack on 18F and some enhanced 16F is read/writeable. Some 18F PIC's have a stack pointer register (STKPTR) along with top of stack registers TOSU, TOSH and TOSL. These 3 registers hold the 16-bit address in the stack at whichever stack level is being pointed to by the stack pointer.

If we're talking 8051, the stack just uses registers in RAM as the actual stack, and any/all values in the "stack" can be read if we know which RAM address the stack pointer register (SP) started with when values were "pushed" to it.

It would definitely take a bit of housekeeping in your code to pull it off but definitely possible with some uC's.
 
If you are using C then the stack is a huge slice of memory!!! The stack includes all function variables so if you have several large arrays between each function, you will soon run out.

MplabC18 defines a page ( 256 bytes ) software stack... If you have four nested functions, every local variable has to be stored... Therefore to do what you ask you will need to know A) where the compiler puts the stack B) the size each function takes..... If you just print out the whole stack you would need the address of each function ( you could do this with a function pointer... )

However! From the question I should imagine you are getting an overflow!! You need to workout how much data each one takes..... Just run through your code adding up each function's data and you'll see what I mean...
 
I know that Debuggers do that - i.e. show you the Call Stack at each moment - So I am wondering if I can get the uC to to it for me every time a bug occurs.
I simulate mine in ISIS and I can see the stack at every call so I can see where the errors are...

Once you know where in memory they are you can workout a way to see them....
 
Hi,
Thank you very much guys :)

When you work in an IDE, and run the uC "Online", you can stop at each point and view nicely the Call Stack - i.e.
main -> Func1
Func1 -> Func2
Func2 -> Func3

How does the IDE do that - meaning keep track of the Active Subroutines?

I agree that you can do it on your own, since all the "RETS" are stored in the Stack - but it's not trivial for a programmer (not IDE) to go track back all the "RETS" in the Stack and compose a "Call Stack".

Therefore, I wonder, how the IDE does it so "easily"?
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top