Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Problems with FreeRTOS 5

Posted by Adrian Carpenter on October 20, 2008

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


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!!!


RE: Problems with FreeRTOS 5

Posted by Dave on October 20, 2008
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.


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.

RE: Problems with FreeRTOS 5

Posted by Adrian Carpenter on October 20, 2008
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?


RE: Problems with FreeRTOS 5

Posted by Marc Ziegert on October 31, 2008
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

RE: Problems with FreeRTOS 5

Posted by Richard on October 31, 2008
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.


RE: Problems with FreeRTOS 5

Posted by Richard on November 1, 2008
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 );


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:


RE: Problems with FreeRTOS 5

Posted by Marc Ziegert on November 1, 2008
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.

- marc

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

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers





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

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

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner