nobody wrote on Wednesday, December 01, 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.