How to make settings so that task that creates exception only gets destroyed and others remain intact on stm
Basic concept, Tasks in FreeRTOS are much more like threads than processes in a ‘big’ operating system. There is little ‘hard’ protections between Tasks and no resource tracking, so asynchronously killing one task is very likely to put your system into an unstable state.
Agree with that - but if you want to try you can write a hard fault handler that deletes the running task (you can get the running tasks handle by calling xTaskGetCurrentTaskHandle()) - but then you have to be able to return from the fault handler to a different task. That might be possible by calling taskYIELD() in the fault handler so the pendSV interrupt executes as soon as you leave the fault handler. PendSV is the interrupt that selects another task - but it will try saving the context of the deleted task first (which will probably be ok as nothing else could have used its memory by then).
You are doing an interesting experiment, and I’m curious of the outcome.
But still, I would go for a reset of the CPU, and before doing so:
- Store the value of all relevant registers
- Store the state of the tasks, if possible
( data may be corrupted ) - Make sure that all interrupts are off
- Restore the stack pointer to its initial value
- Restart
Some developers provoke a WDT overflow here, which gives a total reset. Some CPU’s have a soft/hard reset that works as well.
As pointed out here above, tasks are not really isolated from each other. When an exception occurs, you don’t always know for sure which task is “guilty”. For that reason, I would recommend restarting.
the idea of deleting the task in the fault handler looks good but the thing is whenever I want to debug the issue it shows some address of the location or shows from portstartfirsttask
can you give me some basic idea or references of things on how to implement this like how to save the registers and task states?
whenever I want to debug the issue it shows some
address of the location or shows from portstartfirsttask
Yes, normally when functions call each other, the return addresses are stored on the stack. That is how a debugger can show the call-stack.
When there is an ISR, often the CPU uses a special ISR-stack, so the debugger doesn’t see who was active.
And sometimes indeed, the address of vPortStartFirstTask() is found in the stack, which is not very useful for you.
When debugging, if possible, do not use any compiler optimisation, use -O0 ( O zero ).
But like Richard said, you can use xTaskGetCurrentTaskHandle()to know the active task handle.
how to implement this like how to save the
registers and task states?
I don’t know of any ready-made examples.
There is good documentation about hard-fault handlers and how to retrieve the values of the registers just before the exception.
You should put the information in a safe place, e.g. in an area in RAM that is not initialised when booting the device. For instance right after data/bss, and before the heap/stack area.
I would collect: a signature, date & time, program version, compilation date, values of registers ( just before exception ) , active task, number of task switches per task in the last N seconds.
I also developed a soft watchdog that makes sure that every tasks is alive: each task much call a “touch” function e.g. every minute. If not, the device will reboot.
I won’t provide sources here because they are too platform dependant.