I am having a problem getting the above function to work correctly. Some background: I am using FreeRTOS 8.1.2 on a TI CC3200 LaunchPad I am creating 3 different timers with intervals of 10ms, 1s, and 30s to do various things. The application is running rock solid in various configs on a number of devices but a number of things I am finding wrong being: A: Missing “Tmr Svc” task from the task list. See output below [ 27.621] +-+———-+——+—+——+——–+———+ [ 27.621] 0 (null) | 0/ 0 | 0 | 0 | 0.00% | 0 [ 27.621] 1 Console | 2/ 2 | 1 | 328 | 0.03% | 93 [ 27.621] 2 SLSpawn | 4/ 4 | 2 | 184 | 0.00% | 12 [ 27.621] 3 SmpLnk | 4/ 4 | 2 | 400 | 4.56% | 12430 [ 27.621] 4 Receive | 2/ 2 | 2 | 856 | 15.22% | 41482 [ 27.621] 5 Transmit | 2/ 2 | 2 | 920 | 15.14% | 41243 [ 27.621] 6 Engine | 3/ 3 | 2 | 120 | 0.00% | 6 [ 27.621] 7 Sensors | 1/ 1 | 2 | 360 | 0.01% | 41 [ 27.621] 8 IDLE | 0/ 0 | 1 | 352 | 64.68% | 176207 B: if I perform a specific set of console instructions I succeed in corrupting the xTaskNumber and pcTaskName variables for the xTaskNumber=0 and pcTaskName=(null) entries. My questions are: A: Why the missing details (ALL of it) for the “Tmr Svc” task, even though it is there and running perfectly ? B: How do I pinpoint where the task table entries get corrupted? All help appreciated. Andre

I have tried a few experiments and in all cases the timer service task is showing up in the list – so I can’t replicate your issue there. However, the 0 (null) in the list would seem to indicate you already have a data corruption, so would guess that to also be the cause of the missing timer service task. Do you have stack overflow detection turned on? In V8.1.2 to task control block will be corrupted by an overflow. In version 8.2.0 (currently available for download as a release candidate) the TCB of the offending task will not be corrupted to facilitate debugging – at the cost of the TCB of a different task potentially being corrupted. Do you have configASSERT() defined? Regards.

Thanks for the quick response, but hopefully I can claim back some remnants of respectability by saying I found the bug a couple of hours ago. It was related to… a) wanting to display the tasks always in task number numeric sequence; and b) assuming task numbers start from zero, based on the earlier 0/(null) displayed; and c) hence matching/sorting incorrectly. I have downloaded V8.2.0 and had a look but not tried yet, have enough bugs of my own to create then squash, without muddling my thoughts with suspicions of bugs in what has been a superb and stable product to work with (FreeRTOS) Thanks again, Andre