OS-Stack Monitoring

The OS shall provide a stack monitoring which detects possible stack faults of Task(s)/Category 2 ISR(s). [SWS_Os_00067]

Stack Check Strategy

All OS stacks must be protected from overflowing. The OS shall offer different strategies to detect stack overflows or even to prevent stacks from overflowing.

In dependency of the configured scalability class there are the following strategies:

How to detect a stack overflow (Software stack check)

The use of stack monitoring is specified by OsStackMonitoring at the time of configuration.

There are three methods for detecting stack overflow.

• Stack pointer check method
• Magic number check method
• Stack remaining amount check method

The situation in which stack overflow can be detected differs depending on each method. Due to the specifications of each method, the stack monitoring function of the OS cannot always detect stack overflow.

Stack pointer check method

The stack pointer check method is a method for checking whether the stack pointer exceeds the range of the stack area of the target processing unit. At the time of checking the stack pointer, it can be detected if a stack overflow has occurred.

Magic number check method

The magic number check method is a method in which a special value (magic number) is written at the end of the stack area of each processing unit when the OS is started, and it is checked whether the magic number has been rewritten when the processing unit is switched. It can be detected when a stack overflow occurs during execution of a processing unit and it is written to the end of the stack area.

The magic number area in the magic number check method is allocated at the end of the stack assigned to each processing unit. The size assigned as a magic number to the stack of each processing unit is 4 bytes (eg. 0x5A5A5A5A).

Stack remaining amount check method

The stack remaining amount check method is a method to check whether the remaining stack size is sufficient by using the current stack pointer and the C2ISR stack size specified at the time of configuration when C2ISR is started by nested interrupts.

If CI2SR with medium interrupt priority is started while C2ISR with low interrupt priority is being executed, and if the total stack size used by CI2SR with medium interrupt priority or higher does not remain in the stack area for C2ISR, it is judged that the C2ISR with low interrupt priority has used more than the specified stack, and the stack overflows. Since stacks for C2ISR with different interrupt priorities are allocated in one stack area, the stack pointer check method and the magic number method can detect only when the stack overflows to the entire allocated stack area. Therefore, the stack remaining amount check method makes it possible to check whether the C2ISR that has been executed up to that point is using the stack too much when nested interrupts occur.

Cases when stack overflow cannot be detected

Even if stack monitoring is performed, stack overflow cannot be detected if the stack pointer returns to the range of the stack area without rewriting the magic number area after the stack overflow occurs. In other words, even if stack overflow is not detected, there is a possibility that an area different from the magic number area has been rewritten.

In addition, the memory area outside the stack range is destroyed by stack overflow, which may cause a malfunction before the timing when stack monitoring operates.

Operation timing of stack monitoring

The OS should perform stack monitoring at the timing shown below.

In the following cases, stack monitoring is performed in the same way as the timing of ①.

• When a task in the running state transitions to the suspended state by invoking the API TerminateTask or ChainTask.
• When a task in the running state is forcibly terminated.

If the PostTaskHook is enabled, stack monitoring is performed after calling the PostTaskHook. Since task dispatch occurs due to the expiration process by executing the IncrementCounter, a stack overflow may be detected during the execution of the IncrementCounter as in the timing of ①.

For the timings ③ and ④, the stack used by the hook routines and C2ISR is allocated in one area, so stack monitoring is performed for the stack area used in all these processing units. Therefore, even if the hook routines cause a stack overflow, there is a possibility that the stack overflow will be detected by the magic number check method of ③ and ④.

Note that there may be an overflow in the OS stack when returning from the hook routine, as there is no timing to monitor the overflow in the hook routine.

Behavior at stack overflow

Behavior on SC1

If a stack overflow is detected, the OS shall call the ShutdownOS service with the status E_OS_STACKFAULT. [SWS_Os_00068]

Behavior on SC3

If a stack overflow is detected, AND

• no ProtectionHook is configured, the OS shall call the ShutdownOS service with the status E_OS_STACKFAULT. [SWS_Os_00068]
• a ProtectionHook is configured, the OS shall call the ProtectionHook with the status E_OS_STACKFAULT. [SWS_Os_00396]

Precautions for use

Note that the stack monitoring function cannot always detect stack overflow due to its specifications. To improve the effectiveness of stack monitoring, it is recommended not to place static variables above the stack area (in the direction in which the stack grows). If it is unavoidable due to memory allocation, a sufficient margin must be provided between the stack area and static variables.