vTaskList – TCB gehts destroyed

Hello, i try the following code: serial port IRQ handler: void vSER_ISR_Handler(void) // called when i send something to the uart {    static portBASE_TYPE xTaskWoken = pdFALSE;    uart0_putc(AT91C_BASE_US0->US_RHR); //debug    xTaskWoken = xSemaphoreGiveFromISR( xReadyReadDump, xTaskWoken );     AT91C_BASE_AIC->AIC_EOICR = 0; //end isr } void test_taskA(void * pvParameters ) {    vSemaphoreCreateBinary(xReadyReadDump);      xSemaphoreTake(xReadyReadDump,portMAX_DELAY);          int i;   while(1)   {     if( xSemaphoreTake( xReadyReadDump, portMAX_DELAY ) == pdTRUE )     {          uart0_putc(’r’);            vTaskList(my_buf);          uart0_puts(my_buf);     }     } } and 2 other tasks (b+c), which just give out a character: void test_taskB( void * pvParameters ) //same for task C {      int i;   while(1)   {          for(i=0;i<0xfffff;i++);          uart0_putc(’B’);   } } Before starting the Sheduler vTaskList reports: Task B<9><9>R<9>1<9>482<9>1<r><r> Task C<9><9>R<9>1<9>482<9>2<r><r> Task A<9><9>R<9>1<9>482<9>0<r><r> and after one isr: Task B<9><9>R<9>1<9>475<9>1<r><r> ø<31> <9><9>R<9>1102140<9>0<9>2105240<r><r> Task C<9><9>R<9>1<9>475<9>2<r><r> IDLE<9><9>R<9>0<9>82<9>3<r><r> what happend to tcb of task a? After this task a does not run anymore but the others do their normal work! Also the underlying uart-Interrupt of taska works normal, just the task a does not execute. Could anyone try to help me? Thank you very much!

vTaskList – TCB gehts destroyed

Hi again, using heap_1.c instead of heap_3.c seems to fix the error with the tcb but the main problem is the same. task a gets excutetet only one time, although the isr should set the semaphore…. 2.nd task list (now with heap_1.c) …. Task A<9><9>R<9>1<9>3489<9>0<r><r> …..

vTaskList – TCB gehts destroyed

You don’t say which port you are using, but some initial thoughts: What does uart0_putc() do?  Does it simply write to a register?  Is it safe to call from a task and an ISR simultaneiously? Where is my_buf defined?  How big is it? Regards.

vTaskList – TCB gehts destroyed

my_buf is a 150 char array, putc simply writes a register (i could also use prinf, which is implemented reentrant, but i dont think thats the problem in this case) but i found out now: if i try in task A: if( xSemaphoreTake( xReadyReadDump, 2000 ) == pdTRUE ) instead of if( xSemaphoreTake( xReadyReadDump, portMAX_DELAY ) == pdTRUE ) it works. After xSemaphoreTake timeouts it recognizes the avaible semaphore in the next call. Why the unlimited "timeout" does not work in my case? It seems xSemaphoreTake does not recognize the state change of the semaphore :(

vTaskList – TCB gehts destroyed

And i forget to thank you for the quick reply. Thank you.

vTaskList – TCB gehts destroyed

It might have something to do with the call you make to xSemaphoreTake() after the semaphore is created. I dont think this is needed and would cause you to at least miss the first character I think. Try taking it out.

vTaskList – TCB gehts destroyed

Just a guess: In my case xSemaphoreTake has to wait a relative long period of time – the time i decide to send something to the MCU. Could be there an overflow? Or missunderstood i the principle auf xSemaphoreTake with no timeout?I think that it has to recognize a change of the semaphore even it is setup with no timeout!?

vTaskList – TCB gehts destroyed

@Dave: Thank you. If i take it out, task a gets executed (one time) right after the start – xSemaphoreTake returns pdTRUE, even the interrupt did NOT call xSemaphoreGiveFromISR. Am i wrong with this: semaphore create -> create + semaphore give? But the results seem to underly this.

vTaskList – TCB gehts destroyed

My mistake you are right. From your first post you start with three tasks being listed then get four tasks with the fourth being corrupt and the original three still showing correctly. This must be some memory corruption going on which could cause any kind of unwanted behavior so this could be the cause of the strange semaphore behavior. I would start by checking that you are not getting stack overflows. This is the most likely cause so should be checked first, especially if you are using string handling library functions which can use a lot of stack. Is your interrupt handler just called when the last character has been sent or after every character. From your code I would assume just when the last character was sent.

vTaskList – TCB gehts destroyed

Thank you. The TCB is no okey. I figured out, that the critical Task A is suspended and does not return from this state throw a call of if( xSemaphoreTake( xReadyReadDump, portMAX_DELAY ) == pdTRUE ) but is i use if( xSemaphoreTake( xReadyReadDump, 2000 ) == pdTRUE ) it return after the timeout, does its work. What should i do to let xSemaphoreTake resume the task without setting a timeout != portMAX_DELAY?

vTaskList – TCB gehts destroyed

But i investigate now in the stack. Thank you so far, i will post my results.

vTaskList – TCB gehts destroyed

Ok i got it. The Problem with the destroyed TCB came up with a too small stack, when calling i/o routines. The second is my own, oh my god…: In your api documentation/example for xSemaphoreGiveFromISR you put the following code snippet: ………………………………………………. void vTimerISR( void * pvParameters ) { static unsigned portCHAR ucLocalTickCount = 0; static portBASE_TYPE xTaskWoken = pdFALSE; // A timer tick has occurred. // … Do other time functions. // Is it time for vATask () to run? ucLocalTickCount++; if( ucLocalTickCount >= TICKS_TO_WAIT ) { // Unblock the task by releasing the semaphore. xTaskWoken = xSemaphoreGiveFromISR( xSemaphore, xTaskWoken ); // Reset the count so we release the semaphore again in 10 ticks time. ucLocalTickCount = 0; } // If xTaskWoken was set to true you may want to yield (force a switch) // here. } ………………………………………………. This will result in giving the Semaphore just for one interrupt. No following interrupt will give the semaphore… But thank you for you quick help! Greeting from Hamburg, Germany

vTaskList – TCB gehts destroyed

Oops, the static is the problem right?  Sorry about that.  I have updated the page on the FreeRTOS.org site, you may need to refresh (F5) to see the new page. Regards.

vTaskList – TCB gehts destroyed

Yes the static was the problem. Thank you very much.