TRACE_ASSERT upon taking a MUX

Partners & Sponsors Percepio
1

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

2

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?

3

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

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

4

This seems like Tracelyzer specific, so I’d let @johankraft comment. Meanwhile, can you try removing TRC_CFG_USE_TRACE_ASSERT?

5

Hi

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

I went back and read [Getting Started with TraceRecorder on FreeRTOS](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

6

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.

7

Thank you for sharing your solution.

8

Thank you @johankraft for your response!

1 Like
9

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

10

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

11

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.

12

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.

13

“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