Hi,
I have HardFault_Handler after prvPortStartFirstTask, I am tries to detect when or where it happens.
Every time it happens from another location.
My app is very big and it difficult to understand where it is – right know this is my approach
I am frequently checks the heap available size:
xFreeBytesRemaining size_t 44824
I have setup #define configCHECK_FOR_STACK_OVERFLOW 1 //Stack Overflow Detection - Method 1 #define configASSERT( x ) if ((x) == 0) {assert_failed((uint8_t *)FILE, LINE); taskDISABLE_INTERRUPTS(); for ( ;; );}
void vApplicationStackOverflowHook(void ){ assert_failed (FILE, LINE);}
but I cannot catch it. How can I debug it from the HardFault back to location of the error.
this is not happen right a way after starting the kernel
port: not sure what is it.
Compiler : GCC), STM32CubeIDE.
FreeRTOS:V1,FreeRTOS Kernel V10.3.1
configCHECK_FOR_STACK_OVERFLOW - now I set it to 2.and i will monitor it
now it stopped to go to HardFault, don’t know why - still under investigation
I think it crash due, task size what too low.
How can I know that the size of the task is starting to get small?
This is the task definition I have used:
osThreadDef(runnig_main_ThreadName, runnig_main, osPriorityNormal, 0, 4048+1024);|
osThreadCreate(osThread(runnig_main_ThreadName), NULL);|
Another thing,
my code is in the original used RTX and it converted to FreeRTOS runnig_main is Initialize the all system it reads staff from SPI(interrupts) created and tasks, mutex’s, timers… Initializing staff
When I used RTX - runnig_main not in task, but here It have to do it like that because the freeRTOS disable interrupts until the kernel starting.
After runnig_main task creating all the tasks… it can finish, but the other tasks will stoped as well, so I hold it inside
I am not sure this is the best practice for that, what is your opinion on this?
When you say the task size is too small, do you mean the task’s stack size is too small?
If it is not going to a hardfault now, what is the code doing? Is it in an assert?
Which hardware are you using? If possible, it might be useful to comment out some tasks to narrow down the problem. This page provides some additional details about debugging hard faults - Debugging and diagnosing hard faults on ARM Cortex-M CPUs