This looks like a hard one. Intermittently, like once a day, I’m getting this: CM4 FAULT!! SCB->CFSR = 0x00008200 Bus Fault! Fault address = 0x01000000 r0 = 0x00000000 r1 = 0xffffffff r2 = 0x08045a48 r3 = 0xfff783ef r12 = 0x100a875f lr = 0x100a9450 pc = 0x81010000 psr = 0x3e01ec70 The call stack …

It goes against my superstitions to say so, but it looks like the “Intermittent CM4 FAULT! Bus Fault!” problem that started this thread has been solved by setting #define configUSE_NEWLIB_REENTRANT 1 in FreeRTOSConfig.h. Dave’s page explains the reasons better than I can. I want to thank you all …

[image] aggarg: Use xTaskCreateStatic API to create these tasks so that you can supply your own stack buffer. Well, now I get an instant Bus Fault. I can’t get xTaskCreateStatic to work at all. The problem seems to come up around these lines in prvInitialiseNewTask in tasks.c: #if( tskSET_NE…

sizeof xStack is the number of byte, you want the number of elements. Either define a #define symbol with the number and use it the two places of use sizeof xStack / sizeof (xStack[0]) as the stack size parameter

D’oh! Thanks. I’ve got it running now, with a Variable Watchpoint set for write on xStack[0] for UITask.

[image] richard-damon: Thinking about it, this is a helper function for *printf, so check the calls, especially to sprintf to see if you might generate a too long string (sprintf really should be snprintf to avoid this) The only sprintf()s I can find are in +FAT tests that aren’t running no…

You previously mentioned that this task uses snprintf a lot, you might want to double check the size of all the string buffers and the size passed to snprintf, to see if you have a too small buffer anywhere. The other option is to scan through the stack like I did farther to find the call into the …

In completion to Richards hints it’s possible that the stack might not be overflowed say linearly. Once I encountered a (s)printf caused stack overflow with a gap where the stack data was not changed but with a corruption at a certain offset. This was caused by a serious underestimation of the sta…

[image] aggarg: Put a data break point on &( xStack[0] ) to stop the program when it changes - this will break the program in the debugger whenever stack gets overflown. It ran happily all night. [Of course: change one thing and the problem goes away… for a while.] But then, this morning I de…

I hope I don’t cause you a fruitless detour here, but I think PSoC Creator uses newlib for the C runtime. Newlib does need some care and feeding. I noticed in your FreeRTOSConfig.h: #define configUSE_NEWLIB_REENTRANT 0 Most likely you’ll need to change that to 1. This tells FreeRTO…

Looking at your original message, it looks like p got it value changed to point into your programs string constant area, in particular the value of the string message for the assert. I don’t know if you just got the wrong level of the call stack or if this is a sign of some of the memory mis-writes …

[image] jefftenney: #define configUSE_NEWLIB_REENTRANT 0 Most likely you’ll need to change that to 1 . This tells FreeRTOS to maintain a global pointer used by newlib to find its current “context” data. If you call a newlib function reentrantly (eg, from more than one task) without…

Intermittent CM4 FAULT! Bus Fault! in floating point app

Kernel

Topic		Replies	Views
Finding configTOTAL_HEAP_SIZE Maximum Value Kernel	28	2351	May 31, 2016
FreeRTOS stack corruption on STM32F4 with gcc Kernel	11	1344	February 25, 2013
How to catch code that caused the hard fault Kernel	21	3056	July 12, 2017
ARM Cortex M7 fault exception and stack corruption Kernel debug	15	4150	July 4, 2023
LPC1763, FreeRTOS 8.1.2: Stack Overflow Hook triggers on basic task. Kernel	10	558	April 10, 2015

Intermittent CM4 FAULT! Bus Fault! in floating point app

Related topics