TaskNumber vs TCBNumber

Kernel
1

Hi,
As far as i can determine these fields are used inconsistently and there is at least a documentation level error.

uxTCBNumber - assigned when task created.
uxTaskNumber - assigned via vTaskSetTaskNumber()

uxTaskGetTaskNumber() - claims to return uxTCBNumber in tasks.h but infact returns uxTaskNumber
vTaskGetInfo() - returns uxTCBNumber as pxTaskStatus->xTaskNumber

Regards
Steve

2

A recent change seems to address this issue:

3

Agreed that will resolve the obvious error. Thanks.

I would suggest that the dual use of the term ‘Task Number’ is still potential source of problems. Having had a look at the FreeRTOS-Plus-Trace library I wonder how it works. As far as I can tell it makes use of uxTaskGetTaskNumber() without corresponding use of uxTaskSetTaskNumber()

4

Good point. It seems that the xTaskNumber field of the TaskStatus_t struct is unfortunately named. The caller of vTaskGetInfo() would need to be careful not to expect the xTaskNumber field to match the return value of uxTaskGetTaskNumber().

I couldn’t immediately see the problem you refer to in +Trace. The user of the +Trace library has the option to use the task number but does not have to do so. As you say, if they actually use it, they would need to call vTaskSetTaskNumber() if they have expect uxTaskGetTaskNumber() to return something meaningful.

5

Thanks for the replies.

You say they have the option to use it but it seems to be embedded in the +Trace library.

UxTaskGetTaskNumber called by prvTraceGetTaskNumberLow(|High)16
prvTraceGetTaskNumberLow16 used by TRACE_GET_TASK_NUMBER
TRACE_GET_TASK_NUMBER called in many places e.g.

  • trcKERNEL_HOOKS_TASK_SWITCH which passes it to prvTraceStoreTaskswitch()
  • uiTraceStart()

vTaskSetTaskNumber called by prvTraceSetTaskNumberLow(|High)16
prvTraceSetTaskNumberLow16 is only used by TRACE_SET_TASK_NUMBER
TRACE_SET_TASK_NUMBER is not automatically used anywhere.

Therefore without the user putting in explicit calls to UxTaskSetTaskNumber or TRACE_SET_TASK_NUMBER for each of their threads the underlying pxTCB→uxTaskNumber will be 0. I can’t find evidence of this in any of the Demo projects .

I’ve not currently got the TraceAnalyser tool to look at the data recorded, e.g. by the Posix_GCC Demo to see what an end user would see.

Disappearing down a rabbit hole, I’m obviously missing or failing to appreciate something basic…

Cheers
Steve

6

I suspect the Tracealyzer UI doesn’t “need” the task number at all, but maybe the UI can show the number if the user wants to see it. In that case the user’s own application code would be setting the task number. I don’t have Tracealyzer anymore so can’t check.

7

We are using TaskNumber in Tracealyzer for trace filtering. Only used in the snapshot recorder . We do use vTaskSetTaskNumber() when a task is created. It is done by some macro magic:
#define TRACE_SET_OBJECT_NUMBER(CLASS, pxObject) TRACE_SET_##CLASS##_NUMBER(pxObject)
Here is an example in a debugger after a task is created:
image
We take the TCBnumber and add 0x10000.

/Kristoffer @ Percepio

1 Like
8

Grand. Thanks for clearing that up for me.

9

I alittle related but in our FreeRTOSConfig.h we map tcb to TaskNumber.

#define portSETUP_TCB( pxNewTCB ) pxNewTCB->uxTaskNumber |= ( pxNewTCB->uxTCBNumber & 0xffff)

(this is when we use Tracealyzer, when not using Tracealzyer we just have a direct = )

This is called in task create. We found that it made things simpler for us to have these numbers be equal to the same thing. Your mileage may vary.