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_PREEMPTION1
#define configUSE_IDLE_HOOK0
#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_FACILITY0
#define configUSE_16_BIT_TICKS0
#define configIDLE_SHOULD_YIELD1

#define INCLUDE_vTaskPrioritySet0
#define INCLUDE_uxTaskPriorityGet0
#define INCLUDE_vTaskDelete0 #define INCLUDE_vTaskCleanUpResources 0
#define INCLUDE_vTaskSuspend0 #define INCLUDE_vTaskDelayUntil0
#define INCLUDE_vTaskDelay1

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

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 :-) 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.

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

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?

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