Task handling in FreeRTOS

I have basic questions about FreeRTOS,

  • Do segmentation Fault or any other hard fault will occur for a task? If so what will happen to other task running without any issue
  • How to detect segfault or hard faults?
  • Is it recommended to kill and restart the task in FreeRTOS?
  • How to detect task is not deleted but it is out of infinite loop and came out of task function?

Thank you,
Vijay

You don’t say which processor you are running on, but in nearly all cases FreeRTOS is statically linked into your application code, so you have a single executable. If the processor enters a fault handler, nothing else will run on the core until you handle the fault because the core is inside the fault handler.

How you detect a fault will depend on your processor and how you set up fault/exception handlers - but if a fault occurs you will know because the processor will execute the fault handler.

Ref determining if you exited a loop that implements a task: Some ports create a stack frame that will call an error handler if you exit a task - others will just crash. You can add an assert (configASSERT()) to the end of functions that implement tasks to alert you should you reach the end of the function for any reason.

One point to make is that FreeRTOS tasks are NOT highly isolated like separate processes on a large protected OS, so in general, if one task faults, it is very questionable to assume that the system can just continue with that one task somehow restarted.

Hi,
Thanks for the update.

FreeRTOS runs in ADSP SC594 - Arm Cortex-A5.

My aim is to watch the system for below conditions

  • hard faults
  • Software watchdog to monitor the tasks (Eg : to check any task is blocked or dead)

Do we have any solution available with FreeRTOS?

Both of those things are VERY application specific. In general, I would say that an that that can generate a hard fault should be considered to having a bug that needs to be corrected. If there are special cases that it makes sense to handle, being special cases says that a FreeRTOS generic method isn’t likely, but it will be application specific.

Being non-maskable interrupts, fault handlers will need some special smarts to manipulate the system state. That means they may want to be implemented used the source code extention hook in tasks.c.

For Watchdogs, it is very application specific on how to test that things are “working”, so again a generic answer is unlikely. Often I will use a low priority task to interface with a hardware watchdog, so if some task hogs the CPU, that will trip the watch dog, and that tasks has some interface into the various parts of the system that need to be running to confirm that they are working as expected. If you don’t have a hardware watchdog, then you want a very HIGH priority task, or better yet a non-maskable interrupt, that periodically scans the system state for signs of things not working. Again, the definition of “Not Working” is very application specific., but generally looks for outstanding requires that haven’t been timely completed.