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

Problem using vTaskDelayUntil and vListRemove

Posted by Alberto Lega on September 23, 2011

Hi,
I tried to mout FreeRTOS V7.0.1 on a Fujitsu MB96F356RWB. The project is compiled using Softune (F2MC-16 Family SOFTUNE Workbench V30L35). I started from FreeRTOS released for MB96340.

I created a new Softune project using start.asm working on my system. I slightly modief it to be as close as possible to the one contained in the release for MB96340.

I added all the files needed except croutine.c and I modified FreeRTOSConfig.h to exclude co-routines.
I implemented memory model contained in heap_3.c (should be a wrapper for standard malloc and free).

As first try, I created one task in main() with the following code:




#define CHA_VEH_STATE_MACHINE_TSK_TICK( (portTickType) (CHA_VEH_STATE_MACHINE_PERIOD_MS / portTICK_RATE_MS) )

void CHA_VEH_StateMachine(void* parParam){
portTickType xLastWaitTime;

for(;;){




/* Wait until next execution */
vTaskDelayUntil(&xLastWaitTime,CHA_VEH_STATE_MACHINE_TSK_TICK);
}
}


The project was compiled and downloded into the micro, bur some problems raised. Micro's Program Counter jumped to position 0x000000 and was impossible to continue execution or to take micro control via EUROScope (debugger). This problem does not happen without the call to vTaskDelayUntil.

Moreover, the problem does not raise if I create another task with a low priority which is kept running as a fake background task.

With an empirical method of cut code and try I found that the problem is related to the call to vListRemove, in particular to its first lines:


pxItemToRemove->pxNext->pxPrevious = pxItemToRemove->pxPrevious;
pxItemToRemove->pxPrevious->pxNext = pxItemToRemove->pxNext
;


Actually, I do not know deeply FreeRTOS implementation, so I can only make a guess of what is happenning, but I am scared to make some pointer to point to something that does not exist (the task is only one, so there is no next!)
In vListRemove I cannot see any check on this possibility.

Anyhow, this is only my guess. Because it is not possible to take micro control using the debugger (it does not work) I do not know if my gess is correct or not.

So, if someone found similar problem, please tell me how to make a workaround to avoid micro crash.

Bye.


RE: Problem using vTaskDelayUntil and vListRemove

Posted by Richard on September 23, 2011
For expediency, the linked lists have items at their ends that are always there. That means you don't have to check as you are always guaranteed to have one item in the list.

Check that your start up code is performing the necessary initialisation of variables, including clearing the bss section to zero.

Regards.

RE: Problem using vTaskDelayUntil and vListRemove

Posted by Alberto Lega on September 27, 2011
Thank you very much for your help, richardbarry.

I am sorry, but I was wrong about the descriptioon of the problem in the previous post . I say that because I found a way to get micro control: I have inserted a while(!Dummy) before the execution of any OS-related function.
This makes the micro stop execution until the variable Dummy is 0. When the micro is turned on and before EUROScope takes control, it remains stuck in the while().

I ran the code lots of time, and I understand that my problem raises when exiting the following function:

__nosavereg __interrupt void vPortYield( void )
{
/* Save the context of the interrupted task. */
portSAVE_CONTEXT();

/* Switch to the highest priority task that is ready to run. */
vTaskSwitchContext();

/* Restore the context of the new task. */
portRESTORE_CONTEXT();
}


the macros portSAVE_CONTEXT() and portRESTORE_CONTEXT() are directly written in assembly, whereas the function vPortYield() is compiled and a short header and tail are placed. Header and tail depends on how is defined the function call interface in the project properties. I am currently using "Stack argument passing", which means that the header is simply the instruction
LINK #$00

whereas the tail is
UNLINK


The problem happens when executing ULINK, the assembly instruction before RETI. This instruction affects Stack Pointer (SP) and Register Word 3 (RW3) in this way:

(SP) <- (RW3)
(RW3) <- ((SP))
(SP) <- (SP)+2

In particular, RW3 in the context of the new task in execution contains a value which cannot be used as SP because it points to 0 (i.e.: ((RW3))=0).
This makes me loose the control over the micro and makes the PC be stuck to 0.

This problem happens at the first context swich, when the task in execution calls for the very first time the function vTaskDelayUntil.

What should I check or do to solve this problem?

Thank you very much.
Bye





RE: Problem using vTaskDelayUntil and vListRemove

Posted by Richard on September 27, 2011
“Header and tail depends on how is defined the function call interface in the project properties. I am currently using "Stack argument passing",”


Is that the same as the project shipped for the MB96340 located in the FreeRTOS/Demo/MB96340_Softune directory?

“he macros portSAVE_CONTEXT() and portRESTORE_CONTEXT() are directly written in assembly, whereas the function vPortYield() is compiled and a short header and tail are placed.”


The documentation page for this port says that the function you highlight will not work correctly if optimisation is set to 0 - and that if zero optimisation is required the function should be re-implemented in asm code. Do you have optimisation set to 0?

Regards.

RE: Problem using vTaskDelayUntil and vListRemove

Posted by Alberto Lega on September 27, 2011
Hi,
both the options for argument passing (Stack) and for optimisation level (level 1) are the same in demo project and in mine.

I am giong to check all the other options, but I need some time. I let you know.

Thank you again for you help.

Bye

RE: Problem using vTaskDelayUntil and vListRemove

Posted by Alberto Lega on September 28, 2011
Hi,
I think I solved the problem using optimisation level 1 (as in demo project). Moreover also the otions you can set in the form which apperars pressing detatiled optimize button form must be equal.

1) The comntrol optimisation for pointer aliasing must be done.
2) The inline expansion must be done for functions below 127 lines.
3) The function vTaskIncrementTick and vTaskswitchcontext must be forced to be inlined.

I check the part of code which crated the problem and I saw that now the LINK and UNLINK instructions are no more inserted when compiling the function vPortYeld().

Thanks again.

Bye.


[ 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