RTX tiny and radio interrupt of NRF24LE1

Are you aware that in good software design, you should basically never delete a thread? You don't need the thread anymore, you let the thread end itself instead of having someone else kill it while the thread is in a random, unknown, state.

Think about a trivial piece of code like:

    char *s = malloc(buf);
    do_something();
    free(s);

What would happen if the above sequence is part of a thread, and someone kills the thread after malloc() has allocate a block of memory, but before free() has released it? You think the memory will ever be reclaimed?

So maybe you don't use dynamic memory? But you are most likely using other resoures that has alloc/free, lock/unlock, inc/dec, open/close, ... behavior and where it is important to match the two operations to not create some form of leak.

If your software works so badly, that a supervisor needs to kill a thread, then it's time to consider a full reboot. And debugging/rewriting to solve the issues the supervisor noticed.

So - what are the exit requirements for your receive function? That should give you some indication why it might fail to return. Maybe it fails to return because it is waiting for a resource that is already locked by a thread you have already killed - then there are no thread in existence that will release that resource so your function will never manage to claim it.

In the end - how are your calls to os_delete_task() taking into account all possible state changes of the state machine(s) that is formed by your program? How do you prove that you always move from one valid state into another valid state when you kill a task?

Are you aware that in good software design, you should basically never delete a thread? You don't need the thread anymore, you let the thread end itself instead of having someone else kill it while the thread is in a random, unknown, state.

Think about a trivial piece of code like:

    char *s = malloc(buf);
    do_something();
    free(s);

What would happen if the above sequence is part of a thread, and someone kills the thread after malloc() has allocate a block of memory, but before free() has released it? You think the memory will ever be reclaimed?

So maybe you don't use dynamic memory? But you are most likely using other resoures that has alloc/free, lock/unlock, inc/dec, open/close, ... behavior and where it is important to match the two operations to not create some form of leak.

If your software works so badly, that a supervisor needs to kill a thread, then it's time to consider a full reboot. And debugging/rewriting to solve the issues the supervisor noticed.

So - what are the exit requirements for your receive function? That should give you some indication why it might fail to return. Maybe it fails to return because it is waiting for a resource that is already locked by a thread you have already killed - then there are no thread in existence that will release that resource so your function will never manage to claim it.

In the end - how are your calls to os_delete_task() taking into account all possible state changes of the state machine(s) that is formed by your program? How do you prove that you always move from one valid state into another valid state when you kill a task?

Your answer is a very big lesson for me!Special thanks from me i
was really confused! have a nice day............