FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [December 2004 Threads] 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|