cancel
Showing results for 
Search instead for 
Did you mean: 

Running a system with two separate stacks

infoinfo976
Associate II
Posted on January 07, 2011 at 11:28

Running a system with two separate stacks

10 REPLIES 10
stst9187
Associate II
Posted on May 17, 2011 at 14:20

What are the benefits of two stack model?

infoinfo976
Associate II
Posted on May 17, 2011 at 14:20

''What are the benefits of two stack model?''

using a RTOS, first stack for all app tasks, second stack for interrupt/exception handler,in an ARM7/9 system you have allways separate stacks for the different handlers

read the book from Joseph Yiu for full understanding
joseph239955_st
Associate II
Posted on May 17, 2011 at 14:20

Sorry that I don't have any example project that use STM32 in the book.  (The examples were written before STM32 were available.)

Some advantages of two stack pointer model:

If a task corrupt the process stack pointer and crashed, a fault exception handler can still run even it need stack, and the fault handler might be able to kill the task and allow the OS to continue other tasks.

It is less likely that a task can corrupt the stack memory used by the OS kernel.  If the OS support MPU, it can use the MPU to prevent a task from corrupting data in the kernel and other tasks.

Easier OS design.  Changing the process stack pointer in the OS kernel doesn't affect the current selected stack pointer (main stack pointer), so accesses to the C local variables (in stack) are not affected.

regards,

Joseph

Nickname12657_O
Associate III
Posted on May 17, 2011 at 14:20

Dear Joseph,

Thank you so much for your Contribution

0690X0000060MlVQAU.gif . I'm just reading your book ( 2nd Edition ) when I saw your Message on our Forum. It is always a pleasure reading from you.

Ciao,

STOne-

picguy2
Associate II
Posted on May 17, 2011 at 14:20

Perhaps I don’t understand.

Without an MPU a runaway stack is likely to crash the entire application.  If the application is not to crash, stack overflow (or underflow) must not happen.  Having only one non-system stack and no MPU will not prevent either problem.

Yes, use one system stack for interrupts.  But in my book, each independent task should have its own stack.  Certainly this is needed in an RTOS.  

One stack for independent tasks?

I suppose it could be done but one of two things must be true.  Every task must return to the OS at a fixed stack level.  I.e. no task context can exist on the stack.  Or ... the OS must implement a stack save and restore.

My dumdum non-preemptive OS uses a separate stack for each task.  I switch stack pointers to switch tasks.  Task uses SVC, all registers saved ... other tasks may run ... back in task scheduler restore sp, pop saved registers and return from the SVC.

joseph239955_st
Associate II
Posted on May 17, 2011 at 14:20

Hi PICguy,

You are right that without the MPU, it is possible that a task can crash the own

application. But there is a fairly good chance that the task will fail over very quickly

when the stack pointer is corrupted (e.g. function return to invalid address)  and

cause a fault exception before the rest of the system crash. 

With just a single stack pointer, as soon as one task corrupted the stack pointer,

the whole system could be gone. (It is possible to work around).

With two stack pointers, there is a chance (depends how much data is corrupted) that you can return to the kernel and recover the system when:

1. SysTick timer interrupt (OS can check stack pointer value here) trigger

2. Application task causing a hardfault

When one of these happened, OS can possibly stop the task and start some

recovery actions before the whole system is crashed.

> each independent task should have its own stack.

Agree

> One stack for independent tasks?

I was thinking of one stack pointer, not one stack.  I know that many OS use just one stack pointer to handle task switching, as your OS have done.

Hi STOne-32,

You're welcome. 🙂

Thanks for running the forum, and best wishes for 2011 !

regards,

Joseph

infoinfo976
Associate II
Posted on May 17, 2011 at 14:20

The goal to have 2 stacks (one for interrupts, one for app task\s) is also to minimize the app task stack size.

With one stack for all, every task stack area should additional provide the

needed stack size for the interrupts.

Andrew Neil
Chief II
Posted on May 17, 2011 at 14:20

''The goal to have 2 stacks (one for interrupts, one for app task\s) is also to minimize the app task stack size.''

 

 

Presumably, you mean 1 stack for interrupts, and one stack for each task in the application?

infoinfo976
Associate II
Posted on May 17, 2011 at 14:20

''Presumably, you mean 1 stack for interrupts, and one stack for each task in the application?''

yes, the rtos reserve one area of the RAM as stack for all tasks,

on switching from one task to another, the rtos self change the

(stack)-pointer in this area.