Semaphore release in ISR using NIOS II

danyup wrote on Sunday, February 13, 2011:

Hello to all,
I’m working on measurements over FreeRTOS for a thesis in Computer Engineering. I’m using FreeRTOS over NIOS II processor in an Altera FPGA and a custom made board.
Here is what i’m trying to verify:
A task is blocked on a semaphore, released by an hardware interrupt that fires once every 650us. I want to see if the task keep the same period of the interrupt and what is the latency of using this method (a task waiting for a semaphore) for interrupt management.
When the Interrupt management task is executed alone everything is fine: i can see it starting once every 650 us. If I try it with other lower priority tasks I found that the task is launched once every 2ms, that is the RTOS tick period.
It seems to me that the context switch that should wake the interrupt management task doesn’t occur until the intervention of FreeRTOS kernel, instead of being forced by the semaphore release function and the macro portEND_SWITCHING_ISR.
Am I doing something wrong?
Thanks for your help.
Here’s my source code:

static void test_irq(void* context){
portBASE_TYPE highPrioWoken = pdFALSE;
xSemaphoreGiveFromISR(semaphore, &highPrioWoken);
static portTASK_FUNCTION( vSporadicTask, pvParameters ){
int i;
for(i = 0; i<NUMTEST; i++){
xSemaphoreTake(semaphore, portMAX_DELAY);
m_testBuffer[i] = alt_timestamp();
tst_put_string("name", "SporadicTest");
tst_put_int("numtest", NUMTEST);
tst_put_int("numtask", NUMTASK);
tst_put_ulong("TickFreq", alt_timestamp_freq());
tst_put_ulongbuffer("data", m_testBuffer, NUMTEST);
static portTASK_FUNCTION( vDummyTask, pvParameters ){
int m_dummyVar = 0;

Functions starting with tst_put_ are custom functions used to put the array containing the timestamps on standard output so that i can retrieve and analyse it. However they are called after the test is completed so they should not affect the correct behaviour of the task.

richard_damon wrote on Sunday, February 13, 2011:

You don’t show the code for creating the tasks, but from your description, it sounds like vDummyTask and vSporadicTask are assigned to the same priority level, thus when the semaphore is given, vSporadicTask will not interrupt vDummyTask, but only be scheduled ready and take its turn at the next tick.

danyup wrote on Sunday, February 13, 2011:

Uh… sorry for the missing source… However the sporadic task has an higher priority than the dummy task. That’s why I can’t explain what’s happening…

void startSporadicTest(){
xTaskHandle handle=NULL;
int basePrio = tskIDLE_PRIORITY+1;
if(semaphore != NULL){
xSemaphoreTake(semaphore, 0);
createDummyTasks(NUMTASK, basePrio);
alt_ic_isr_register(SYSID_IRQ_INTERRUPT_CONTROLLER_ID, CONTATORE_AVALON_0_IRQ,test_irq, NULL, NULL); //registering interrupt function
IOWR(CONTATORE_AVALON_0_BASE, 4, 1); //Enabling interrupt
m_testBuffer = pvPortMalloc( NUMTEST * sizeof(alt_u32) );
printf(“Errore!! Impossibile creare il buffer m_testBuffer\n”);
xTaskCreate(vSporadicTask, (signed char *) “Test”, configMINIMAL_STACK_SIZE, NULL, basePrio+1, &handle);

void createDummyTasks(int numtasks, int prio){
int i;
xTaskHandle m_handle=NULL;
for(i = 0; i < numtasks; i++){
xTaskCreate(vDummyTask, (signed char *) “Dummy”, DUMMYSTACK, NULL, prio, &m_handle);
printf(“Errore!! Memoria insufficiente per il task %d\n”, i); //That is out of memory

danyup wrote on Sunday, February 13, 2011:

I forgot the code tag… :frowning:
Why can’t I edit the post?
However thanks for your reply

richard_damon wrote on Sunday, February 13, 2011:

One thought, is configMAX_PRIORITIES (in FreeRTOSConfig.H) at least 3? (Since you have 3 priorities, 0, 1, 2).

danyup wrote on Wednesday, February 16, 2011:

Yes, it is… configMAX_PRIORITIES is set to 5.
Is there someone else who tried this kind of test? Even with different platform?

richard_damon wrote on Thursday, February 17, 2011:

I will say that I have a somewhat similar structure in one of my projects, with a task that is woken up via a semaphore connected to a higher speed interrupt than the tick interrupt. and it runs fine. I will admit I don’t have the equivalent of your dummy task that is just wasting time.

My only suggestion would be (if possible) to trace with a debugger through the give and switch to see why the task isn’t starting.

The only thing I see that looks unusual to me is that the line m_testbuffer = alt_timestamp(); seems to keep setting the same variable each time, I would expect it to be m_testbuffer_ = alt_timestamp(); or something like that._