When I use OS_WaitBinSem with OSNO_TIMEOUT in a task, and then try to signal the binsem from within an interrupt, my task will never resume even though the binsem has been signaled.

I'm trying to read in some bytes over uart using an interrupt. What I'd like to do is in my task payloadTest turn on the uart1 interrupt and then wait on a binary semaphore. When the interrupt has received enough bytes it will signal the binary semaphore, my payloadTest task should resume, and the task will disable the interrupt. If I wait the binsem with a timeout it will return to my task after the timeout. If I wait with no timeout it will never return to my task. I verified that the interrupt is hitting the line that signals the binsem. In the main loop where ossched() is called I've read the binsem using OSReadBinSem after my interrupt has run enough times and it says that the binsem is 1, but my task payloadTest never resumes.

As a sanity check I tried setting up two test tasks one called Test and the other Temp. Test will wait on a binsem with no timeout, Temp will delay for 5 seconds and then signal the binsem. I've verified that this behaves as expected: Test will wait on the binsem, then Temp will start executing and delay for 5 seconds. Since both are in a waiting state neither does anything in that 5 second period, after the 5 seconds is up Temp will signal the binsem, and the next time ossched() is called Test resumes execution. So it appears that I can wait with no timeout and signal a binsem between two tasks, but for some reason when I try to do the same with a task and an interrupt it doesn't work.

I'm not sure what could be causing this behavior and would appreciate any input.

Because when you have a "rapid-fire" ISR where the ISR may occur (and thereby signal the binSem) faster than the task can successfully wait the binSem, then you will "lose count" (because the binSem pegs to a value of 1), if there is supposed to be a one-to-one relationship between the ISR and the data that it pushes to the task (e.g., individual, incoming Rx chars).

binSem: 20 rapid Rx char ISRs, but only 13 of them are immediately followed by the task successfully waiting the binSem: 7 chars are "lost", in the sense that you are now "behind" emptying your Rx buffer by 7 chars.

Sem: 20 rapid Rx char ISRs, but only 13 of them are immediately followed by the task successfully waiting the Sem: 7 chars will be picked up when the task can run / the ISRs settle, because the "remaining" value of the Sem (in those 7 cases) after being successfully waited is (still) non-zero.

After some testing I found out that it wasn't hanging because the binsem wasn't getting signaled, it was hanging because I had some bad structure in my interrupt and wasn't grabbing the last byte I was waiting for. You're advice helped eliminate some possibilities of what could be wrong, thanks for your help aek! And I'll keep in mind your advice about using a sem instead of a binsem.