lajkabaus wrote on Thursday, November 05, 2015:
Hey, sorry for the delay, and thanks for your time!
I’ll try the evaluation version of that plugin and see how it goes, sound good!
It will not block indefinitely on that unless your tick interrupt is not
running. Is it possible the tick has stopped? If you view xTickCount
in the debugger is it still counting?
Yeah, the count is ticking, that definitely wasn’t the source of the problem.
I am not sure what was (or still is) causing the problem, but I’m pretty sure my inexperience plays a significant role in all this.
For example, the semaphore in question I’ve been using is, in fact, unnecessary, and I think I made some vicious circle between two tasks chasing each other’s tails.
To elaborate: this task (let’s call it task A for brevity’s sake) has a main purpose of filling the queue with sensor data, where the queue in question is blocking the (higher priority) task B in charge of sending data. Once it fills the queue, task A waits for the semaphore.
After task B, now being unblocked, finishes sending data, it will give to this semaphore, thus unblocking task A, and then returning to its wait to pull from the (now empty) queue.
This was the idea, anyway; task A to unblock task B (fill the queue), and task B to unblock task A (post to semaphore). I suspect I somehow succeded in creating a situation which was the polar opposite: one task was, for some reason, unable to unblock the other, thus rendering that task unable to unblock the first one.
I removed the semaphore - task A is now becoming blocked when the queue is full and that’s it. It seems to work for now. I’ll report here, should the issue reappear again.
P.S. I kinda lied; task A is not becoming blocked when the queue is full; since I am using Freescale’s port with its OSA wrappers, the OSA wrapper for posting to queue, in fact, doesn’t have the timeout argument. So I am just posting to the queue in an infinite loop untill I break upon the successful post.