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

Problems with FreeRTOS 5

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

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.

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.

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?

Adrian

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.

Regards.

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 );

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.

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.

thanks.
- marc


[ 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