3 tasks: A, B and C. when A is running, other 2 tasks will stop. B and C tasks can work at same time

Kernel
1

Hello,
Device info:
MCU: stm32F4
freertos version: 9.0.0v
I have 3 tasks, A, B, and C, where A is the primary function; it takes the most resources; B and C are for testing if 2 or 3 tasks can work together.
The test results are:
a. A and B together, only A works;
b. B and C together, they both are working;
c. A and C together, only A works;
d. A, B and C together, only A works;
so the original guess is task A takes too many resources, or A clock is too fast, so there is no time for other tasks.
But after checking by trcanlyzer a, c,d all states, the A tasks got quite a long wait time(maybe the waiting time is occupied by some executions in the code of task A ???)
1. resource allocation

#define START_TASK_PRIO		1 
#define START_STK_SIZE 		4000  
TaskHandle_t StartTask_Handler;
void start_task(void *pvParameters);

#define TASK1_TASK_PRIO		4 
#define TASK1_STK_SIZE 6500
TaskHandle_t TTCANTask_Handler;
void TTCAN_task(void *pvParameters);

#define TASK2_TASK_PRIO		3
#define TASK2_STK_SIZE 		2200
TaskHandle_t Task2Task_Handler;
void  Task2(void *pvParameters);

#define TASK3_TASK_PRIO		2
#define TASK3_STK_SIZE 		500  
TaskHandle_t Task3Task_Handler;
void Task3(void *pvParameters);

2. task info:

Task A
void TTCAN_task(void *pvParameters)
{
  switch(ECUNode) {
    case 0:
      Master_Node();
      break;
    case 1:
      ABS_Control_Node();
      break;
    case 2:
      Speed_Node(); 
      break;
    case 3:
      ECU_Node(); 
      break;
    default:
      break;
    }
}
**Task B**
void Task2(void *pvParameters)
{
 u8 task2_num=0;
 u32 qq;
 UBaseType_t StackUsageMinSize;
 StackUsageMinSize = uxTaskGetStackHighWaterMark( Task2Task_Handler );
  while(1) {
     LEDA7=!LEDA7;
     vTaskDelay(500); }

**Task C**
void Task3(void *pvParameters)
{  while(1) { 
     LEDA8 = !LEDA8;
      vTaskDelay(500); }
}

3. freertos configuration:

#define configUSE_PREEMPTION					1                       
#define configUSE_TIME_SLICING					1

4. trcalyzer:

snap_55.17_ECU_sreenshot
snap_55.17_ECU_sreenshot1191Ă—259 9.04 KB

yellow: A task
red: ready
green: running
blue: waiting

2

First, have you checked the results of create tasks to make sure they all were created successfully.

Second, Tasks B and C have vTaskDelays in them, and infinite loops.

Task A is calling other functions, so it isn’t clear if it will be blocking (if not, because It is the highest priority, the other tasks will never run). I note that task A will run of its end and return when what ever function is first called returns, which isn’t allowed. It needs either an infinite loop or a command to delete itself.

3

Thanks for your reply.
All tasks were set ok.
The main reason is that task A has no delay() related functions, which means when A starts running, it won’t give CPU to any other tasks. Cause Task A is critical; it must run all the time, so send commands to some other boards by CAN periodically.

Task A send CAN messages periodically(like an accurate vTaskDelay()) by hardware timer; this can not be sensed by freertos so freertos won’t allocate CPU resource to other tasks.

Is it possible to use a software timer to replace the hardware timer? Then freertos can sense task A in a waiting state when the software timer does not come to the AutoReloadCallback() function and change task A to suspend the state and other tasks into running the state.

4

If by “Software TImer” means code sitting in a loop waiting for something, which means FreeRTOS never gets invoked to see that it isn’t doing anything.

What you can do is have Task A block on something (like a direct to task notification) and in the ISR for the Hardware timer, you send the unblock signal.

IF by “Software Timer” you are meaning the FreeRTOS timers, then that would be activated by the System Tick, and either you have that timer callback send the unblock (like the hardware timer), or it does the operation itself (and Task A sort of goes away).

Don’t try to use “Suspend”, that is almost certainly NOT the right action. Task A needs to BLOCK on something (either a vTaskDelay, or something like a Semaphore or TaskNotification that is sent by something)

1 Like
5

Thanks for your reply; that helps a lot.
Yes, software timer here. I mean freertos timer.

the function in Task A is a while loop with a hardware timer set,
while the loop keeps running, and when the hardware timer ISR comes, do some actions according to the flag set in isr. So now I realize FREERTOS invokes this hardware timer won’t work when the timer is running, then can not switch the CPU to another task. Then I think the freertos timer can replace the hardware timer; after that, the task can give its occupying CPU to other tasks.

I need to check the semaphore and task notification to ensure the plausible method for solving that task A occupying CPU all the way problem.

6

Spinning in a loop waiting for a software timer will give you the same problem as the hardware timer.

The task needs to BLOCK, waiting for something like a semaphore or a direct-to-task notification, to allow FreeRTOS to switch to another task.

FreeRTOS doesn’t try to figure out that a task isn’t doing anything useful, tasks need to tell FreeRTOS they want to wait for something.