Problems after updating to traceviewer 4.11.1

[MartinB (Martin Belohorka)]

Hi

After updating to 4.11.1, im facing a few problems.

• my ___stack_chk_fail function gets called as xTraceEventCreate1 is returned.
• in trcTaskMonitor.c, there is an assumption that standard stdio.h can always used. It looks like it is prepared that TRC_CFG_PRINTF should be a standard configuration define, but it is not mentioned in any other file. I caught this as I have poisoned “malloc” and printf references malloc via reent.h
• In trcKernelPort.h, there are a lot of macros that expand to switch statements. All of these switch statements lack default cases which triggers warnings when compiling with -Wswitch-default

The last two bullets are simply feedback to @johankraft, however I would appreciate help on the stack issue.

I have started to investigate the stack issue, but so far, all things I have done to influence the issue have had no effect.

• I have tested on both GCC 13.3 and 14.3.
• I have tried both -Os and -Og.
• drastically changing _Min_Stack_Size in my .ld file.
• I also tried to increase the idle task stack, knowing that it should not have any effect.

I am working via stm32CubeIDE 2.0 on a stm32G474RE. FreeRTOS version is 11.2.0.

After 37 FreeRTOS tics, this happens

Does anyone have any good ideas?

Best regards,

Martin

[johankraft]

Thanks for the feedback. We will investigate this.

So it worked as expected with an earlier version? What version did you use then?

[MartinB (Martin Belohorka)]

Hi

I have basically done no change since my unorthodox integration of version 4.10.3 that you might remember from this thread

TRACE_ASSERT upon taking a MUX

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 u…

since it was so unorthodox, I removed that integration completely and installed a new one.

// Martin

[MartinB (Martin Belohorka)]

Hi

The problem is somehow connected to the use of __stack_chk_fail.

If I comment out the definition of the __stack_chk_guard variable, the problem disappears.

If I remove the -fstack-check-all compiler flag, the problem is instead turned into a Hardfault (Bus, memory management or usage fault, Attempt to switch into invalid state). It is also the detected at another place

To be continued.

// Martin

[Boudewijn.Dijkstra]

Hi Martin,

It looks like you’re simply running out of stack space. If you investigate the HardFault, you will probably find a value in BFAR that’s just outside of a stack. When a SysTick IRQ happens, which stack is used? Are you sure that you tried to increase this stack?

Best regards,
Boudewijn (FAE at Percepio)

[MartinB (Martin Belohorka)]

Thanks for the feedback

I will double check this tonight.

// Martin

[MartinB (Martin Belohorka)]

Hi Boudewijn

BFAR is 0xE000EDF8 (close to the actual address of BFAR interestingly )

I should mention that I force busfaults to be precise by issuing:

SCnSCB->ACTLR = (SCnSCB->ACTLR | SCnSCB_ACTLR_DISDEFWBUF_Msk);

I showed in the original post that the Systick was called when the IDLE task was running. Here is a different view showing the same thing

But you are right. The problem is indeed a blown stack. I had a too aggressively big heap area which obviously gave me a (too) small stack. The reason why I did not catch that seems to be that I have done something wrong with the stack canaries that does not seem to trigger in the way that it should.

Thanks so much for the assistance.

I will keep adding to this thread when i figure out why that is.

But for now it works. I am abit confused about some of the output as View does not seem to pick up all the task names.

Best regards

Martin

[Boudewijn.Dijkstra]

Hi Martin,

Good to hear that it works now. I can’t explain the BFAR value.

We have a blog page about object names:

Naming your kernel objects - Percepio

The Troubleshooting section should help you.

/Boudewijn

[MartinB (Martin Belohorka)]

Hi and thanks for the link. I will investigate it.

Regarding the switch-default warnings, my own sollution was to add this to trcKernelPort.h

#define traceADD_SWITCH_DEFAULT() \
		default: \
			break;

And then add calls to that to all macros that lacked the ending default case like this for example.

#define traceQUEUE_CREATE( pxNewQueue )\
	switch ((pxNewQueue)->ucQueueType) \
	{ \
		case queueQUEUE_TYPE_BASE: \
		traceQUEUE_SET_CASE_HELPER() \
			(void)xTraceObjectRegisterWithoutHandle(PSF_EVENT_QUEUE_CREATE, (void*)(pxNewQueue), "", (uint32_t)uxQueueLength); \
			break; \
		case queueQUEUE_TYPE_BINARY_SEMAPHORE: \
			(void)xTraceObjectRegisterWithoutHandle(PSF_EVENT_SEMAPHORE_BINARY_CREATE, (void*)(pxNewQueue), "", 0); \
			break; \
		traceQUEUE_CREATE_HELPER() \
		traceADD_SWITCH_DEFAULT() \
	}

Regards

Martin