nobody wrote on Monday, May 30, 2005:
I have a problem that I cannot put my finger behind (I am relatively new to FreeRTOS).
My example program has two tasks, plus the idle task, with the preemtive scheduler (it runs on an LPC2138, it is compiled with GCC). One high-priority task sits in a loop waiting for something to do. As there is nothing to do (yet), the task just sits in a loop calling "vTaskDelay(10)". No trouble here.
The other (low priority) task runs in a loop doing continous transfers over an I2C protocol, in small bursts (but no delay between the bursts). As the I2C interface is intended to be shared between several tasks, I folded the function that does a single burst transfer inside xSemaphoreTake() and xSemaphoreGive() calls.
This runs for several hundreds or thousands of "bursts", and then everything stops. xSemaphoreTake() does not time-out either. I put logging (over a serial line) in the code to verify whether xSemaphoreTake() or xSemaphoreGive() hangs, but then the problem "magically" goes away (logging slows things down).
I replaced the semaphore with taskENTER_CRITICAL() and taskEXIT_CRITICAL(), and everything works again.
So… just use a critical section, one would say. However, the high-priority task does not use I2C and it would be unfortunate if it were "held up" by the low-priority task(s).
Oh, another thing that I tested was using the semaphore-protected I2C protocol without ever starting the scheduler (and without logging). This gives no problem either. At first sight, it appears that particular sequence of grabbing/freeing the semaphore and the scheduler causes the task to be blocked, especially if the "take/give" sequence is very quick.
Any help on this is greatly appreciated. Thanks in advance,