Running a system with two separate stacks

[infoinfo976]

Posted on January 07, 2011 at 11:28

Running a system with two separate stacks

[stst9187]

Posted on May 17, 2011 at 14:20

What are the benefits of two stack model?

[infoinfo976]

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]

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]

Posted on May 17, 2011 at 14:20

Dear Joseph,

Thank you so much for your Contribution . 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]

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]

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]

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]

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]

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.