This topic was lost when the forum software was switched back to the old version. I am pasting the entire thread below as a single post so it does not get lost.

I work in ARM-Cortex M3 (stm32). I read any interrupts whose ISR's have calls to FreeRTOS API should not be enabled before vTaskStartScheduler().
I need to run a task at 100Hz just after calling vTaskStartScheduler(), which has to collect data from I2C sensors & process the data with an algorithm. At present I'm starting this task when i send a command to board via Bluetooth or USB. This command will Starts a TIMER whose ISR will trigger the Task. I would like to remove this command, so that the task will be started when i just power on the board.
What is the recommendable way to do this?
Any code listing would be really helpful.
Thanks

Last edit: hari 13 hours ago
Link

Richard Damon
15 hours ago
All tasks created before calling vTaskStartScheduler will be started immediately after the call (and execute in priority order). I tend to create most of my tasks before calling vTaskStartScheduler. Most of these will enter the task infinite loop and then block on the queue/semaphore that they will be feeding from.

Link

hari
13 hours ago
Hi Richard Damon,
I did not find the answer in your reply. If i understood correctly you stated what problems will happen if we start task before vTaskStartScheduler().


Last edit: hari 13 hours ago
Link

Gavin Lambert
12 hours ago
Just create the task before calling vTaskStartScheduler. It will automatically start running when the scheduler starts, because no tasks can run before that anyway.
Unless instructed differently by your particular port, you should also make sure that interrupts are disabled throughout your init code. When the scheduler starts it will normally enable interrupts automatically anyway, and it's usually not safe to have any interrupts get triggered before the scheduler is up and running.

Link

Richard Damon
7 hours ago
There is no problem with creating all your tasks, queue, etc before calling vTaskStartScheduler. In fact this gets around the problem of tasks/interrupts needing to check if the needed resource has already been created before using it.
The only time I would think of doing otherwise would be in a very memory constrained application that needed to run different tasks in different conditions, but the work needed to prove that the setup was "stable" is high, as this almost by definition requires using dynamic allocations at run time, which is very hard to fully verify as it has a long "memory" in the state of the heap.

Link

hari
7 hours ago
Please find the attached file for my code( I was unable to use code hiliter here).
Board has two ways of communication, via Bluetooth virtual com port and USB virtual COM port. With this code on board, if I try to connect to board by opening COM port, sometimes it will be connected & sometimes not. I doubt some PRIORITIES PROBLEM.
But this code works fine if the Timer2 starts when i send a command to board via Bluetooth or USB. This command will Starts a TIMER2 whose ISR will trigger the Data Task.
My last reply to my another thread on this forum has more information of my hardware & interrupts here: https://sourceforge.net/p/freertos/discussion/382005/thread/074eec0c/
Thank you.

Last edit: hari 7 hours ago
Attachments