Quality RTOS & Embedded Software

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




Loading

Is there a problem in cTaskResumeAll() ?!

Posted by Nobody/Anonymous on December 1, 2004
Dear Contributers,

I noticed (and fixed) a problem in cTaskResumeAll().

Calling this function before any task was initialised may result in a problem. In line 780 (tasks.c) the macro listGET_OWNER_OF_HEAD_ENTRY is called. If the lists were not initialised in a prior task-creation, this macro tries to dereference (?) the uninitialised list-pointer.

Now you could ask, why anyone should call cTaskResumeAll() before the creation of task. This doesn' t make sense, in fact. But the suspend-all and resume-all funtions are called in the memory-allocation routines. Calling this routines before task-creation makes sense. As memory-allocation is a part of the task-creation I got mysterious hang-ups, when I used suspend/resume-functionality in memory-allocation.

In previous versions the macros portENTER_CRITICAL() and portEXIT_CRITICAL() were used to make memory-routines safe.


Changing line 776 as follows solved the problem for me:
if (( ucSchedulerSuspended == pdFALSE ) &&(usCurrentNumberOfTasks > 0))

With no task created, no actions to put task on any list are performed.

I wonder if anyone noticed this before. Please cross-check this issue and tell me of your experience. Maybe there are other problems in my program.


I use the latest version available on a C167CR. The port to this platform was completed by me. There were some changes in the kernel. I'm in discussion with my tutor, if we could contribute this kernel-version to www.freeRTOS.org . I made my changes to the kernel in a way, that enables the user to scale them away via constant-definitions and conditional compilation.

Thanks in advance, Daniel

P.S.: I apologize for my english, as it may be bad.

RE: Is there a problem in cTaskResumeAll() ?!

Posted by Nobody/Anonymous on December 1, 2004
Sorry, to post again. My EMail-Adress : Guru79@web.de

Daniel

RE: Is there a problem in cTaskResumeAll() ?!

Posted by Nobody/Anonymous on December 1, 2004
Sorry for double-posting : EMail-replies to Guru79@web.de

RE: Is there a problem in cTaskResumeAll() ?!

Posted by Richard on December 1, 2004
Hi Daniel,

I think you are making a good point here. The memory allocation schemes are intended for the kernel's use, but there is nothing to say that the user should or shouldn't use them also. This is particularly true if you wanted to create a queue for example before the pointer was initialised.

The enter/exit critical functions were replaced by cTaskSuspend/ResumeAll() functions to prevent the interrupts being disabled for the duration of the call.

Your fix is good, at the minor cost of an additional check each time the function is called - which could be frequently.

For now I will update the documentation to say the functions should not be used unless the pointer has previously been initialised and add an entry into the bug list. I will modify the code for the next release.

Thanks for bringing this to my attention.

As regards to the C167 port - this would be very nice to have, especially if you have some documentation also. Really as an open source project you should be making this available to the wider community. You would of coarse be credited with the work.

Regards.

RE: Is there a problem in cTaskResumeAll() ?!

Posted by Richard on December 7, 2004
Release V2.5.4 has been made available to correct this.


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




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

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