Hi,

I have used FreeRTOS 4.2 under a number of projects with great success, but I'm having massive troubles getting FreeRTOS5 to work :(

I'm using Crossworks for ARM 1.7 (Release 13) on an AT91SAM7S256 processor. Code which was once working in 4.2 is no longer working in 5, I've made the necessary changes to the FromISR routines to code with the parameter now being a pointer rather than a value and I've changed to the new ISR macros.

Infact, I've even stripped down the code so that it starts a task that simply does

for(;;)
{
vTaskDelay(5000);
}

Going into vTaskDelay causes a dataabort when inside that it reaches a portYIELD()

This has got two of us absolutely stumped here, no explanation as to why it does this or indication from the link register/stack frame how it got into data abort, seems to have gone off into a random location.

It's more bizarre that code that was once working and has been working faultlessly for the past year (it's in a system which runs our building management system - we've got 16 of these networked in our building) is completely broken now, no other code changes (apart from the changes required for FreeRTOS5) and just a compiler & OS version change.

Any ideas or pointers from you guys would be highly appreciated!!!

Adrian

I assume that your code with the delaying loop is running in a task, and so the scheduler has actually started when you call vTaskDelay(). An obvious point maybe but thought I would mention it all the same.

Check:

i/ You have setup a stack for Supervisor mode.
ii/ You are in Supervisor mode when vTaskDelay() is called.
iii/ You have installed the SWI handler correctly.

Hi dave,

Yeah, the main() basically just creates an init task and then starts the scheduler, the init task I've commented out all of the normal code and just put in a delay loop.

This code has been running flawlessly on FreeRTOS 4.2.0 for 14 months non-stop 24/7 on multiple systems without falling over!!! I can't even get something simple on 5.0.4 to run at all!

In regards to your other questions:

1) Yes, have stack for supervisor mode and main() starts in SVC mode
2) Yep.
3) swi handler is present and correct afaik, it worked in 4.2?

Adrian

i've got the same problem. (using GCC/ATMega323)

vTaskDelay( (portTickType) 767 );

and below works, but

vTaskDelay( (portTickType) 768 );

and above not.
i still couldn't find the bug.

- marc

Can you create the smallest possible project that exhibits this behaviour (without any absolute file paths), then zip it up with build instructions if necessary, and send it to me at r (dot) barry [_at_] freertos.org. Thanks.

Regards.

Thanks for sending me your project.

I have had a quick look using the AVRStudio simulator and found that the problem caused by an inadequate stack being assigned to your test task. You have only allowed 32bytes for the task stack. Your application is therefore crashing when the task is being restored after its delay period.

If you change the code from
xTaskCreate( &task1, (const signed char*)"test", 32, NULL, tskIDLE_PRIORITY, &xHandle );

to

xTaskCreate( &task1, (const signed char*)"test", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, &xHandle );

Then everything is working fine.

Here are some pointers, although these are a bit harder to use on 8bit devices:
http://www.freertos.org/Stacks-and-stack-overflow-checking.html
http://www.freertos.org/uxTaskGetStackHighWaterMark.html

Regards.

wow, thx!
i would never have thought about that, because it worked with ticks<512+256 of delay.
verry strange, that it worked at all.
i wonder, wether adrian's problem was the same; maybe one need a larger stack with rtos5 than with rtos4, or that bug magically didn't happen with rtos4.

thanks.
- marc