Skip to main content
MEber.10
Visitor II
November 14, 2018
Question

Is there a way to disable the automatic default task creation in CubeMx ?

  • November 14, 2018
  • 10 replies
  • 8079 views

We are using CubeMX (incl. FreeRtos) to update our settings.

The problem is that CubeMX will always create a default task in the main. We also tried to remove the following line from the ioc file "FREERTOS.Tasks01=defaultTask,0,128,StartDefaultTask,Default,NULL" but it will automatically rewrite it.

Is there a way to disable the default task code generation ?

Thanks

This topic has been closed for replies.

10 replies

Khouloud GARSI
Technical Moderator
November 16, 2018

Hello @MEber.10​ ,

I will highlight this point internally and one of our STM32CubeMX experts will answer you ASAP. Meanwhile, could you please precise which STM32CubeMX version you're using.

Khouloud.

Visitor II
December 4, 2018

Hi @MEber.10​ 

I want to know the CubeMX version you are using as well as the ioc file that generated this problem.

Best Regards,

Wael.

Visitor II
December 5, 2018

Hi @MEber.10​ 

I tried with an STM32F4 MCU. I noticed that you're right

Your request has been redirected to the development team. it will be corrected in the next release.

Best Regards.

Wael.

SAnde.12
Associate
January 23, 2019

Hi, I just updated to STM32CubeMX V5.0.1 /2-January-2019 and issue is still there. Not possible to delete defaultTask using GUI and it is re-added if manually removed from ioc.

In which release is this planned to be corrected?

Best regards

/Stefan

Visitor II
January 23, 2019

Hi @SAnde.12​ 

Your request has been redirected to the development team. it will be corrected in the release 5.2.0 of CubeMX .

Best Regards,

Wael

PR.10
Associate III
August 31, 2022

The problem still exists in 1.10.1. The task creation is in main now so the workaround with return does not work. All application tasks are created elsewhere using freertos API. In my project the default task is empty only taking memory and cannot be used to anything else. I was considering deleting it by that won't help when full static allocation is used.

Is there any plan to fix that? It would be nice for processors with just few kB of ram not not waste it. Just add a user section around so we can use #if 0 or add checkbox to mx ui

char_array
Associate III
September 1, 2022

Latest version of STM32CubeMX is 6.6.1. I just tested it and task creation is still the same. Maybe you have a different MCU? Or maybe the newer STM32CubeIde comes with a different version of STM32CubeMX. An option in STM32CubeMX would be the best, but maybe there still is a possible workaround with a macro. Can you share more details?

Jordi Becares
Associate III
January 23, 2019

Hi all,

I "fixed" this problem, renaming the defaultTask to another task used in my application, and this works.

It is not a "final" solution, but I can kept RAM free.

I will wait for oficial soution.

Regards

Jordi

david.s.keck
Associate
August 14, 2019

I am having a similar issue. When I remove the code generated for the DefaultTask, I am met with a hard fault. What is depending on this default task being around and how do I break that dependency?

char_array
Associate III
October 20, 2021

My workaround is to simply add a return statement inside MX_FREERTOS_Init() user code section.

void MX_FREERTOS_Init(void) {
 /* USER CODE BEGIN Init */
 startMyTask(); // create and start your own task here
 return; //return to avoid creation of default task
 /* USER CODE END Init */
 
 /* USER CODE BEGIN RTOS_MUTEX */
 /* add mutexes, ... */
 /* USER CODE END RTOS_MUTEX */
 
 /* USER CODE BEGIN RTOS_SEMAPHORES */
 /* add semaphores, ... */
 /* USER CODE END RTOS_SEMAPHORES */
 
 /* USER CODE BEGIN RTOS_TIMERS */
 /* start timers, add new ones, ... */
 /* USER CODE END RTOS_TIMERS */
 
 /* USER CODE BEGIN RTOS_QUEUES */
 /* add queues, ... */
 /* USER CODE END RTOS_QUEUES */
 
 /* Create the thread(s) */
 /* creation of defaultTask */
 defaultTaskHandle = osThreadNew(StartDefaultTask, NULL, &defaultTask_attributes);
 
 /* USER CODE BEGIN RTOS_THREADS */
 /* add threads, ... */
 /* USER CODE END RTOS_THREADS */
 
 /* USER CODE BEGIN RTOS_EVENTS */
 /* add events, ... */
 /* USER CODE END RTOS_EVENTS */
}

The default task will never start this way. The compiler should be smart enough to optimize out the function as it is an empty function and only referenced by dead code.

JimYuill
Associate II
September 28, 2023

A work-around is to tell STM32CubeIDE to not generate the main() function in main.c.

When FreeRTOS is installed via the IDE, the IDE generates a main() with calls to CMSIS-RTOS functions, to start the FreeRTOS scheduler and a task.
If the calls to CMSIS-RTOS functions are removed manually, they will be recreated the next time that code is generated for the project.

To not generate main(), the IDE's configuration-setting is in the *.ioc file’s "Project Manager" window.
There is a check-box “Do not generate the main().”
I could not find ST documentation for this configuration-setting.

Presumably, you'd need to create main() yourself.
In main(), you'd need to call the MCU set-up functions that the IDE generates in main.c, such as SystemClock_Config(). 

I've tried-out the configuration-setting, “Do not generate the main()”.
But, I haven't tried coding main(), as I just described.

MAbub.1
Associate
January 6, 2024

Hi,

Is there any update on it?

We are around 5 years in with an issue affecting many people and still no progress and no response from ST. That is some gold-tier performance by ST. Please give these people a raise they deserve it for their outstanding work. Keep up the good work guys.

Senior
January 6, 2024

Unfortunately FreeRTOS development is discontinued and ST now relies on Microsoft solutions to keep on offering RTOS support with their X-CUBE-AZRTOS packs. If you start a new project from it, after reading some documentation and understanding some basic examples it could be easy. But if you wish to port an old FreeRTOS project to it, forget it !

MAbub.1
Associate
January 6, 2024

Hi @Oskar_H,

  I hope you are doing well. If I understood you correctly, It is implied that FreeRTOS is not actively developed and discontinued and therefore ST has to move to other solutions. If this is correct, then, I respectfully have to disagree with this statement. If you see the GitHub repo then you can easily verify that FreeRTOS is very much actively developed and the last release was on 4th March 2023 and the last commit was a few days ago. In fact, Amazon is investing in its development. I also failed to find any mention of it being discontinued during my brief Google searches.

If I am mistaken then please provide a link to the official statement of FreeRTOS discontinuation. Hey, we learn new things every day and I am open to updating my knowledge. :)

 

Putting that aside for a moment and thinking along the lines of providing FreeRTOS legacy support. I don't think it is asking for much to provide a simple boolean option to disable the default task creation. ;)