Handling OS_STATUS_LIMIT Error

Handling OS_STATUS_LIMIT Error

Question:

How can I handle the OS_STATUS_LIMIT error?

Answer:

The OS_STATUS_LIMIT error occurs when the underlying task causing this error has been activated more often than allowed/configured. The activation could be done by the user or via alarms. Cyclic activation by alarms is arguably the most common source of this error. There are four approaches to handle this error:

1. Ignore this error in the Error Hook:
   
   You can choose to ignore this error if you are absolutely sure it is safe to do so. With this, you do not eliminate the error but simply overlook it.
   
   Go to the Error Hook in your Os_Callout_Stubs.c file and adapt it to include the following:
   
   
    
   This will make sure that all OS_STATUS_LIMIT errors are ignored.
    
2. Increase the number of allowed activations for this task in the configuration:
   
   This approach is useful to prevent the error in case of system runtime bursts but not in case of permanent runtime overload. 
   
   In DaVinci Configurator Pro, either go to Os/OsTaks from the Basic Editor or All/Tasks from the Comfort View, and select the corresponding task. (how to find the task causing this error, see the note at the end of the document).
   
    
   
   There, in the field Task Activation increase the number to a desired value. Default is 1 which means by default, only a single activation is permitted for this task. No activation, i.e. 0 is not allowed.
   
    
3. Avoid this error by using extended tasks:
   
   For extended tasks, the SchM and Rte use the setting of events for triggering the mapped runnables instead of the ActivateTask alarm actions. Once an extended task has been activated, it will either be running or waiting for the events to be set and has no defined end. The setting of events is not tracked by any counter which means that events can be set multiple times without any limit. Thereby removing any reason for the activation limit of the tasks to be reached. In short, extended tasks do not have multiple activation issues (unless the user deliberately tries to activate an already activated extended task).
   
   For basic tasks, the mapped runnables could be triggered cyclically by OS alarms even when the task is already activated and running, or is currently preempted (but still activated).
   
   To set a task as an extended task, either go to Os/OsTaks from the Basic Editoror All/Tasks from the Comfort View in DaVinci Configurator Pro, and select the corresponding task(s).
   
    
             
   There, in the field Task Type select EXTENDED from the drop-down menu.
   
   
   
   Note: 
   Using extended tasks exclusively while bypassing the OS_STATUS_LIMIT error will also increase your RAM usage.
    
4. Eliminate the cause(s) of the multiple activations:
   
   When a task is activated multiple times than it is scheduled to be running, one of two things are taking place:
    

   cause_1

   This task has a low priority and other higher priority tasks or interrupts are starving this task. These tasks or interrupts consume so much runtime that the starving task is activated over and over again, without running until the maximum number if activations are reached. The OS is not capable to schedule the task in the wanted cycle time and there is not enough execution time left.

   solution

   Depending on whether you want to solve the priority issue, execution time issue, or limit of maximum activation issue, the solution will differ: Increase the number of allowed activations for this task (see 2. increase the number of allowed activations for this task in the configuration ) Increase the priority of this task (this might however lead to starving of the next low priority task) Lower the cycle time of the starving task (this is sometimes not possible as the cycle time might already be at minimum) Increase the CPU frequency  Check if the starving task and the corresponding activation alarm has an autostart. If yes, remove the autostart of the task if possible. Strategetically call SchM_Deinit to safely deactivate the task activation alarm(s) and then call SchM_Init when it is acceptable to reactivate them.

    

   cause_2	Hardware timers are being used for periodic interrupts which continue running even when in debug mode (when breaking the software run or stopping at a breakpoint). Stepping through the software resolves a timer interrupt which could potentially cause the OS to interpret as a trigger to reactivate an already activated task which cannot be processed at the moment.
   solution	The hardware timer should be suspended either in the debugger or in your main function before the initialization steps. Most likely your hardware will have a STMx_OCSregister (where x = 0, 1, 2, etc) in which the OCDS Suspend Control field needs to be set to SUSPEND.

Note:

1. You can find the task with the multiple queued activation requests by using the following API in the Error Hook:
   
   OSError_ActivateTask_TaskID()
   
   if(CurrentError.Error == OS_STATUS_LIMIT)
   {
     TaskType activatedTask
     activatedTask = OSError_ActivateTask_TaskID();
   }
    
2. From a code point of view, this error is returned by one of the following functions (therefore good for setting breakpoints):
    

• Os_TaskActivateLocalTask()
• Os_TaskActivateRestartTask()
• Os_TaskActivateTaskInternal()
• Os_Api_ActivateTask()
• Os_Api_ChainTask()