Strange behavior: semaphore deletes itself

Hello, first and foremost I have to clarify that Im new to RTOS programming.
Im writing firmware that controls the speed of 2, 4 pin CPU fans. The system is accessed using usart commands. In the following image the architecture of the project is explained

So far I have made it work using 1 fan and using variables instead of queues.
But now that I leveled it up in what was supposed to be a more advance architecture I’m experiencing weird errors regarding memory.

My setup:
CMSIS-V2 on top of FreeRTOS v10

The problem is as the title states it, the usart_task semaphore “deletes itself” (or so it seems because the memory location of where the semaphore was is set to 0) the second time it is released after the fan_control_task runs. Problem is that this does no happen at a specific point, it may happen at different points in the code of the fan_control_task. Its obvious that I don’t delete the semaphore.
The thing is that when I change the memory of the semaphore from dynamic allocation(originally everything with dynamic allocation and heap_4.h) to static allocation the weird behavior persists, even in heap_2.h. When I tried to put most of the tasks, queues etc in static the weird behavior shifted from the semaphore to the queues, which for some reason did not host the value I was putting in them until a hard fault triggers after the second element comes(queue size = 1)
I have tried using an other MCU and yet this weird behavior persists.
Anyone else has experienced something like this? what could the origin of this weird behavior be?
PD: instead of fans I tried to pull the lines low with a button by hand and the problem persists.

Standard answer to questions describing weird application behavior :wink:
Did you define configASSERT and also enable stack overflow checking for development/debugging to catch possible fatal errors or data corruption ?
Another issue might be wrong interrupt priorities for interrupts using FreeRTOS API in their corresponding ISRs resp. ISR callbacks.
See e.g. Understanding priority levels of ISR and FreeRTOS APIs - #16 by aggarg for a pretty good explanation.