When FreeRTOS software timer enabled, SPC570Sxx_RLA FreeRTOS SERIAL Test Application fail to work

[Job Shen]

Posted on December 12, 2017 at 02:47

Hi,

I am using the sample application SPC570Sxx_RLA FreeRTOS SERIAL Test Application for Discovery and my hardware is the SPC570S-DISP board.

I found that if i enable the 'Use software timers' in the SPC5 FreeRTOS component RLA, then generate and build the code, and program the board, debug through it, it suppose to stay in the 'vTaskStartScheduler();', but it doen't. It will step through it and fail the sample application. I wonder what is the cause for the failure? According to FreeRTOS documentation, if it run out of heap or other problem, it will step out of the vTaskStartScheduler().

Did i do something wrong or the software timer is not supported?

BTW, i noticed the Timer task stack depth is 2048, is that too much? I sort of noticed that during my experiment of my application, if i asked for 1000 stack depth for my task, the application will fail. But for the timer task stack depth, the range is 1024 - 8192.

Best Regards,

Job

#spc570s-disp #soft-timer #freertos

[Erwan YVIN]

Posted on December 12, 2017 at 09:49

Hello Job ,

I have requested some helps from the application team.

  Best Regards

               Erwan

[Erwan YVIN]

Posted on December 13, 2017 at 10:54

Hello Job ,

the recommandation for a software timer is to use 2048 as a limit of your task size. (it is an example)

Anyway , if you set 1024, it seems to work. I have no problem in the software timer (Task Priority 3, Timer Queue Length 10)

in FreeRTOS point of view,

the minimal Stack size is 256.

for your task (Size 1000) , you have maybe :

• a stack overflow
• a coredump (check your LR and your PC)

      Best Regards

                   Erwan

[Job Shen]

Posted on December 13, 2017 at 20:01

Hi Erwan,

Thank you very much for trying it out.

For the SPC570Sxx RLA FreeRTOS SERIAL Test Application for Discovery sample application, if only change the Timer task stack depth to 1024, it will work. I tried different value and found that stack depth 1125 will fail and 1120 will pass. (i didn't need to narrow down further). The sample application created 2 other tasks which use stack size 256.

Then i tried with our application which has 3 tasks each set to stack size 256, and if i enable timer with 1024 timer stack depth, it will fail. I had to comment out one task in order to make the application run.

This comes to a conclusion that if want to use freeRTOS software timer, your application is limit to 2 tasks with 256 as stack size, and timer stack depth set to the minimum 1024 (or 1120 if you need some extra byte for the stack).

Could you confirm this conclusion is correct? Or there is a global configuraion somewhere which can increase the default overall stack cap to allow more tasks to be created.

Best Regards,

Job

[zambrano.luigi]

Posted on December 14, 2017 at 11:53

Hi Job,

sorry for the issue. Let me explain the root cause: when you enable the software timers, a further task (timer task) is created. The stack size of this task is specified through the configuration parameter 'Timer task stack depth', set by default to 2048. This value is NOT the size in bytes. The size in bytes is calculated as (2048 * sizeof( StackType_t )), where StackType_t for our platforms is 4bytes. So, in other words, the stack size for the software timer task is, by default, 8k. Moreover, in our test application other 3 tasks (vTaskOne, vTaskTwo and the idle task) are created. For these tasks the stack size is (configMINIMAL_STACK_SIZE  * sizeof( StackType_t )) = (256 * 4) = 1k. So, overall, to work fine our test application with the software timer enabled requires at least 11k. But in our test app the heap size for FreeRTOS is set to 8k. For this reason the test app fails when the software timer is enabled. In order to solve the issue, you can increase the heap size (for example, from 8192 to 12288) or reduce the software timer stack size (for example, from 2048 to 1024, that means 4k). Last but not least, please let me underline that in the heap and stacks dimensioning it is better to guarantee a small margin because a small part of memory is used to manage the control structures.

Best Regards,

Lugi