# TRACE\_ASSERT upon taking a MUX

**URL:** <https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367>\
**Category:** Percepio\
**Created:** [July 8, 2025, 10:10pm UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367 "2025-07-08T22:10:22Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![MartinB](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@MartinB](https://forums.freertos.org/u/MartinB)\
**Post date:** [July 8, 2025, 10:10pm UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/1 "2025-07-08T22:10:22Z")

</div>

Hi

First of all, i apologize if this is not the right forum, but i fail to fund any other supportforum for Percepio view on Percepios own website.

I have a system running FreeRTOS 11.2.1 and Trace recorder 4.10.3 in snapshot mode on a STM32G474. I have just started using Percepios tools, so it seems very likely that I am doing something simple wrong.

I followed the “getting started” video from Percepio and I also changed a few more config flags.

- I added assert (TRC\_CFG\_USE\_TRACE\_ASSERT)
- I used TRC\_RECORDER\_BUFFER\_ALLOCATION\_DYNAMIC for buffer allocation
- Added TRC\_CFG\_INCLUDE\_TIMER\_EVENTS
- added TRC\_CFG\_INCLUDE\_PEND\_FUNC\_CALL\_EVENTS
- Made sure all my 130 mutexes could fit by setting TRC\_CFG\_NMUTEX 140

Now, when a Mutex is taken, the call to traceQUEUE\_RECEIVE in Queue.c:1696 leads to a TRACE\_ASSERT so that “Invalid value for objecthandle” is reported.

Removing TRC\_CFG\_USE\_TRACE\_ASSERT and debugging the code leads me to see that  
in uiIndexOfObject, objecthandle is 0 and objectclass is 2.

In prvTraceSetObjectState we also find that value is 7.

After that, i get lost in the macro expansion of traceQUEUE\_RECEIVE but I do see that it makes use of the tasknumber, which I have modified early in my code in order to be able to sort the task to my liking in another debugging feature.

Best regards  
Martin

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [July 9, 2025, 5:25am UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/2 "2025-07-09T05:25:33Z")

</div>

> [@MartinB](#):
>
> which I have modified early in my code in order to be able to sort the task to my liking in another debugging feature.

Is it possible to remove this modification just to confirm if this is the cause of the issue?

@johankraft Do you have any other suggestion?

---

<div class="post-metadata">

**Author:** ![MartinB](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@MartinB](https://forums.freertos.org/u/MartinB)\
**Post date:** [July 9, 2025, 11:28am UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/3 "2025-07-09T11:28:31Z")

</div>

Hi

I have temporarily removed it and it absolutely have had an effect. The trace view makes a lot more sense now.

However, the original problem persists.

I extracted the full expand of the traceQUEUE\_RECEIVE call

```auto
if ((1696 < 0)) \
	{ \
		if (prvTraceGetTaskNumberHigh16((void*)prvTraceGetCurrentTaskHandle()) & CurrentFilterMask) \
		if (prvTraceGetQueueNumberHigh16((void*)pxQueue) & CurrentFilterMask) \
			prvTraceStoreKernelCall((uint8_t)((((((((((((((((((((0x00UL) + 1UL) + 3UL) + 4UL) + 8UL) + 8UL) + 8UL) + 8UL) + 8UL) + 8UL) + 8UL)) + 8UL) + 8UL) + 8UL) + 8UL) + 8UL) + 8UL) + 8UL) + TraceQueueClassTable[prvTraceGetQueueType(pxQueue)]), TraceQueueClassTable[prvTraceGetQueueType(pxQueue)], ( ( traceHandle ) prvTraceGetQueueNumberLow16(pxQueue) ));; \
	} \
	else \
	{ \
		if (prvTraceGetTaskNumberHigh16((void*)prvTraceGetCurrentTaskHandle()) & CurrentFilterMask) \
		if (prvTraceGetQueueNumberHigh16((void*)pxQueue) & CurrentFilterMask) \
			prvTraceStoreKernelCall((uint8_t)(((((((((0x00UL) + 1UL) + 3UL) + 4UL) + 8UL) + 8UL) + 8UL) + 8UL) + TraceQueueClassTable[prvTraceGetQueueType(pxQueue)]), TraceQueueClassTable[prvTraceGetQueueType(pxQueue)], ( ( traceHandle ) prvTraceGetQueueNumberLow16(pxQueue) ));; \
	} \
	prvTraceSetObjectState(TraceQueueClassTable[prvTraceGetQueueType(pxQueue)], ( ( traceHandle ) prvTraceGetQueueNumberLow16(pxQueue) ), (uint8_t)TraceQueueClassTable[prvTraceGetQueueType(pxQueue)] == ((traceObjectClass)2) ? (uint8_t)(traceHandle)(prvTraceGetTaskNumberLow16(prvTraceGetCurrentTaskHandle())) : (uint8_t)(pxQueue->uxMessagesWaiting - 1));;

```

Regards  
Martin

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [July 9, 2025, 11:41am UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/4 "2025-07-09T11:41:05Z")

</div>

> [@MartinB](#):
>
> However, the original problem persists.

This seems like Tracelyzer specific, so I’d let @johankraft comment. Meanwhile, can you try removing TRC\_CFG\_USE\_TRACE\_ASSERT?

---

<div class="post-metadata">

**Author:** ![MartinB](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@MartinB](https://forums.freertos.org/u/MartinB)\
**Post date:** [July 9, 2025, 11:54am UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/5 "2025-07-09T11:54:34Z")

</div>

Hi

It seems it was a “PEBCAK” problem after all.

I went back and read [[Getting Started with TraceRecorder on FreeRTOS](https://percepio.com/getstarted/latest/html/freertos.html)](Percepio getting started) and noticed that i am not allowed to create any FreeRTOS objects prior to calling `(void)xTraceEnable(TRC_START);`  
As the mutexes that were causing the problem was created before the call, it was easy to catch.

Moving the creation of the mutexes fixes the problem.

Best regards  
Martin

---

<div class="post-metadata">

**Author:** ![johankraft](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@johankraft](https://forums.freertos.org/u/johankraft)\
**Post date:** [July 9, 2025, 12:06pm UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/6 "2025-07-09T12:06:13Z")

</div>

The main problem is that TraceRecorder is not configured as recommended in the getting-started guide. It seems the “recorder mode” setting has been changed to “snapshot mode”. This is a legacy setting that shouldn’t be used anymore and has been removed in the upcoming v4.11 release.  
When set to “snapshot mode”, TraceRecorder uses a separate older implementation that is more complex and can be challanging to configure correctly.

I suspect the problem will go away if using TraceRecorder with the default configuration, i.e. with the recorder mode set to the default “streaming mode”. Use the RingBuffer streamport.

We are aware this “recorder mode” setting can be confusing and is easy to misunderstand, which is why we are removing it now. Sorry about that.

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [July 9, 2025, 2:35pm UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/7 "2025-07-09T14:35:29Z")

</div>

Thank you for sharing your solution.

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [July 9, 2025, 2:35pm UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/8 "2025-07-09T14:35:41Z")

</div>

Thank you @johankraft for your response!

---

<div class="post-metadata">

**Author:** ![timo12](https://avatars.discourse-cdn.com/v4/letter/t/fbc32d/32.png) [@timo12](https://forums.freertos.org/u/timo12)\
**Post date:** [July 14, 2025, 9:41am UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/9 "2025-07-14T09:41:12Z")

</div>

> [@johankraft](#):
>
> “recorder mode” setting can be confusing … we are removing it now

I’m guessing that you meant to say that “snapshot mode” is being removed 🙂

---

<div class="post-metadata">

**Author:** ![johankraft](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@johankraft](https://forums.freertos.org/u/johankraft)\
**Post date:** [July 14, 2025, 10:15am UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/10 "2025-07-14T10:15:39Z")

</div>

Yes, but also the “recorder mode” setting, since it has only one option remaining (streaming mode).

---

<div class="post-metadata">

**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\
**Post date:** [July 14, 2025, 10:38am UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/11 "2025-07-14T10:38:15Z")

</div>

Does that imply that all options to in-memory record will be eliminated? That would be fatal because streaming debug support does not only (to my knowledge) require rather expensive debug probes but also on certain platform special wiring that would need to be designed into the PCB layout.

---

<div class="post-metadata">

**Author:** ![johankraft](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@johankraft](https://forums.freertos.org/u/johankraft)\
**Post date:** [July 14, 2025, 11:13am UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/12 "2025-07-14T11:13:24Z")

</div>

No. The recommended method for snapshots still remains, i.e. the RingBuffer streamport module. The “snapshot mode” that is being removed is a legacy thing, redundant and have been deprectated for years, but sometimes people still find that setting in trcKernelPortConfig.h and use it by accident.

---

<div class="post-metadata">

**Author:** ![MartinB](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@MartinB](https://forums.freertos.org/u/MartinB)\
**Post date:** [July 14, 2025, 1:02pm UTC](https://forums.freertos.org/t/trace-assert-upon-taking-a-mux/23367/13 "2025-07-14T13:02:02Z")

</div>

“people” will now wait until the next release and hopefully get it to work better then :-). To me, it is still confusing, but it is working now.

// Martin