Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
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!




RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
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>
.....

RE: vTaskList - TCB gehts destroyed

Posted by Richard on January 3, 2008
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.

RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
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 :(


RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
And i forget to thank you for the quick reply. Thank you.

RE: vTaskList - TCB gehts destroyed

Posted by Dave on January 3, 2008
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.

RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
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!?

RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
@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.


RE: vTaskList - TCB gehts destroyed

Posted by Dave on January 3, 2008
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.

RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
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?

RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
But i investigate now in the stack.
Thank you so far, i will post my results.

RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
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

RE: vTaskList - TCB gehts destroyed

Posted by Richard on January 3, 2008
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.

RE: vTaskList - TCB gehts destroyed

Posted by Wildcard on January 3, 2008
Yes the static was the problem.
Thank you very much.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists