-STM32F7
-uVision 5.28
-FreeRTOS 10.10 (Basic API in use not CMSYS OS API)
Our project is programmed in C. The project has a modular structure. This means that a task (T1) runs and calls functions in several modules. One of these modules (A) has a semaphore to protect a memory area. This memory area is called by another function (b()) from another module (B) by the task (T1) and should write the memory when it gets the semaphores. The function (a()) of module (A) called after function (b()) by task (T1) should copy the same memory area to another area if the semaphore is available. At the very first call of the functions b() and a()) the semaphore is occupied although nobody has taken the semaphore and the semaphore is set free during initialization. After that the process works. Maybe you already had such problems? Possibly a timing or priority problem?
When creating a semaphore, the software needs to decide if it should be created takeable or taken. xSemaphoreCreateBinary() creates the semaphore in the taken state, as semaphores are most often used for one task to signal another that it is ready to run.
For what you are doing, a Mutex sounds like a better idea, mutexes are designed for ensuring mutual exlusion on use of a resource, and implement special functions like priority inheretance to handle some special problems with this use.
The other option would be that just after creating the Binary Semaphore, you can do a xSemaphoreGive() on the semaphore, to move it to the takeable state.
Hi,
Thanks for your response. I give the semaphore in a task initialization routine. I use a semaphore because I give it in an isr. The problem was in another task (Tn) where I was waiting for another semaphore a tick too long and this leads to the misbehaviour in the task (T1).