Hello, we’ve updated freertos in our project from 10.x to V11.0.1. After this update, our application doesn’t start anymore. I’ve analyzed the changes and found that kernel commit 30e6b8a5ead added changes to the cortex M4F port that check for correctly installed interrupt handlers (in my case “GCC…

Just to be thorough, when the assertion failures mysteriously go away, can you put a breakpoint on them to make sure they are actually still compiled in? Often, different build settings make configASSERT() disappear due to different #define definitions of configASSERT(). Does your bootloader provi…

[image] mwagner: This leads me to suspecting that I somehow get memory overwritten As @jefftenney suggested, please check that the assert is still there in the compiled code. If the memory seems corrupted, you can try to use data breakpoint to find the cause of the corruption. [image] jef…

Thanks for your replies. Took me a while to get the binary at least partly running with gdb/openocd (wdt, no symbols in release build, …) the assertion also happens when directly flashing binary without bootloader support, so I would rule out bootloader / handover problems. making seemingly random…

edit: forget this post, I’ve had the wrong elf loaded in gdb…

[image] mwagner: .weak PendSV_Handler .thumb_set PendSV_Handler,Default_Handler This is weak definition. You need to share the other definition of PendSV_Handler you have. Are you adding the following line in your FreeRTOSConfig.h: #define xPortPendSVHandler PendSV_Handler

I use the define (see my first post), this maps to the function in port.c

I’ve fount the line it hangs in the debugger: configASSERT( xUpdatedTickCount <= xNextTaskUnblockTime ); in tasks.c. stacktrace: Thread #1 (Suspended : Signal : SIGINT:Interrupt) vTaskStepTick() at portmacro.h:217 0x8005d5c vPortSuppressTicksAndSleep() at port.c:800 0x8005d5c prvIdleTask.l…

It seems this is the real assertion failure: configASSERT( xUpdatedTickCount <= xNextTaskUnblockTime ); To make sure, as an experiment can you define configUSE_TICKLESS_IDLE to 0 and verify the issue goes away? Are you using the built-in implementation of vPortSuppressTicksAndSleep() or your own …

disabling tickless idle makes the error go away. But I wouldn’t give to much on that as adding a few lines of code in the main() function also makes the error go away. we use #define configUSE_TICKLESS_IDLE 1, without adding/customizing any functions.

I’ve continued evaluating the problem in the debugger by adding some debug variables. This shows why the assertion fails. volatile uint32_t test3257 = 5; volatile uint32_t test3258 = 6; volatile uint32_t test3259 = 7; void vTaskStepTick( TickType_t xTicksToJump ) { TickType_t xUpdatedTickCo…

CM4F Assertion in port.c after update to V11.0.1

Kernel

aggarg (Gaurav Aggarwal) April 12, 2024, 5:28am 19

That does not make much sense. Which hardware are you using? Asking to see if I can repro this problem.

Topic		Replies	Views
ATSAM4E16C port.c assert in vTaskStepTick() Kernel	10	621	August 14, 2019
Porting FreeRTOS on F28M35x (Cortex m3), the program flies after instruction svc # 0 Kernel debug	16	532	February 1, 2024
Massive stack overflow on task when kernel starts. Any ideas? Kernel debug	50	1135	May 29, 2024
vTaskStepTick is randomly Asserting Kernel	42	3525	November 14, 2023
Cortex-M0+ core micro Issue with FreeRTOS integration ARM	23	2602	May 7, 2020

CM4F Assertion in port.c after update to V11.0.1

Related topics