taskYIELD()

Kernel
1

nobody wrote on Saturday, August 05, 2006:

Hi,

I 'am programing a project with FreeRtos 3.2.2, IAR 4.40 and a AT91Sam7S256.
The project has 2 tasks with the same priority. The second task checks UART activity:

void vDeviceTask( void *pvParameters ) {
   while(1) {
     …
     taskYIELD();
   }
}

Checking the UART takes not much time so taskYIELD "restarts" the main task.

After a short time the system crash complettly:
The IO’s are reprogramed, the OSC stops , the reset pin is no longer activ and the watchdog is not able to restart the system.

When i remove the taskYIELD() line the program run stable over days.

Below are the  RTOS settings:

#define configUSE_PREEMPTION        1
#define configUSE_IDLE_HOOK        0
#define configCPU_CLOCK_HZ        ( ( unsigned portLONG ) 47923200 )
#define configTICK_RATE_HZ        ( ( portTickType ) 1000 )
#define configMAX_PRIORITIES        ( ( unsigned portBASE_TYPE ) 2 )
#define configMINIMAL_STACK_SIZE    ( ( unsigned portSHORT ) 500 )
#define configTOTAL_HEAP_SIZE        ( ( size_t ) 10000 )                  // 14200
#define configMAX_TASK_NAME_LEN        ( 16 )
#define configUSE_TRACE_FACILITY    0 
#define configUSE_16_BIT_TICKS        0
#define configIDLE_SHOULD_YIELD        1

#define INCLUDE_vTaskPrioritySet        0
#define INCLUDE_uxTaskPriorityGet        0
#define INCLUDE_vTaskDelete            0    #define INCLUDE_vTaskCleanUpResources            0
#define INCLUDE_vTaskSuspend            0 #define INCLUDE_vTaskDelayUntil            0
#define INCLUDE_vTaskDelay            1

Has anybody an idea what is going wrong in the original code ?

There some points in my code where i like to use
taskYIELD() instead of vTaskDelay(1).

This crash doesn’t happens when the code is running under IAR debugger !

Thanks for your comments.

Regards

Rainer

2

nobody wrote on Saturday, August 05, 2006:

It is interesting that it works fine with the debugger.  Are you using different optimisation levels between the debug and non debug versions?  If so it could well be a missing volatile or something of that nature.

What are the optimisation settings you are using.

Before Richard asks the question :slight_smile: are you sure you are not just running out of stack space.  Try making the stacks bigger in the tasks.

On the SAM7 the reset button input is setup in software, maybe the same is true of the watchdog.

3

nobody wrote on Monday, August 07, 2006:

Hi,

thanks for your response.
It seams that taskYIELD() is not the problem. With some other test parameters the problem still occurs.
This morning it happens with the debugger but we are not able to access the arm core.
The problem also happens with debug code in the past, so it seams not to be an optimization problem.
I have checked the stack while the system works and there is sufficient space on stack.
We are familiar with the reset and watchdog setting and the watchdog works fine when we have an endless loop in the main task.
When the error happens it seams that a couple of processors registers are changed and the core stops.
The main problem is, that the error occurs not very reliable.

Regards

Rainer

4

nobody wrote on Monday, August 07, 2006:

Are you able to set a data breakpoint?  If so can you set one on the watchdog register so the program breaks when it gets written to?

5

nobody wrote on Monday, August 07, 2006:

We have notice this problem only once or twice unter debugger controll. It happens mostly without debugger controll.