I’m new with FREERTOS or with STM32
currently using STM32F767Z.
I’m using FREERTOS - 3 tasks.
task 1 - generate and send messages with SPI
task 2 - retransmitting the messages also with SPI
task 3 - reads from CAN and UART and updating one of the structs.
the code is using pvPortMalloc() and vPortFree() functions.
initializing a new array and allocating memory with pvPortMalloc
when I’m running with debug mode I get stuck on HardFault_Handler() due to memset function (my implementation- the function is ok) on the new array.
seems like bad memory allocation.
it happens before the tasks start to execute… (in the init section)
I did some digging on this issue and I understand I must adjust the tasks stacks and the total heap size.
I have enabled the USE_MALLOC_FAILED_HOOK option and added a breakpoint in the vApplicationMallocFailedHook function and the code stoped there
I tried to read the comments in the ioc file but I don’t understand how to do it right.
this is the RAM configuration
_Min_Heap_Size = 0x200; / required amount of heap / _Min_Stack_Size = 0x400; / required amount of stack /
if you wrote your memset() function yourself AND the fault reliably occurrs during your memset(), it should be easy for you to devise debugging strategies yourself!
What I would do is record source and target pointer to your memset() upon entry. I’m fairly certain that your memset() faults whenever the target pointer is corrupted (typically a 0 pointer due to a malloc() fail).
You should also add the minimum useful information (eg which port you use and which x in heap_x.c).
The port is the portable layer dealing with/abstracting the actual MCU (core) and compiler you’re using.
I guess in your case it’s (Source/portable/GCC/)ARM_CM3 or Source/portable/GCC/ARM_CM4F when using FPU.
Heap seems sufficient at the 1st place but maybe it isn’t.
Are you able to estimate the required amount of memory you allocate ?
When stopping in the failed hook on a breakpoint you can usually follow back the call stack to see which call with which arguments you came from with the debugger.
Try to step through init code to see that the linked list size and the number of arrays isn’t too big unexpectedly (due to programming bug).
What exactly doesn’t work ? It will work if the heap is big enough for ALL your allocations. Note there is more memory taken from heap e.g. the memory needed for the tasks itself including their stack.
Also each allocation usually needs a bit more memory than asked for required for heap internal buffer management.
ok, so I have 4 memory allocations on 4 different arrays.
let’s assume I’m calculating all 4 of them like we just did in the example above.
then I also have a linked list queue and I’m using pvPortMalloc for the new node each time I have to add a new SPI message to the queue.
I don’t know how many nodes will be created during run.
it depends on the SPI messages.
so it’s hard to calculate how much memory is taken from the heap in this case.
I have 4 different arrays with different sizes - we can calculate their memory usage
I have linked list queue that I can calculate each node memory size but I can’t know how many nodes will be created.
and the memory needed for the tasks
Yes - you can estimate the statically needed amount of heap (if the arrays are static you could declare them static and don’t use the heap, but it doesn’t really matter. RAM is RAM, almost regardless from where it’s taken, data section or heap).
Sure, the dynamic memory requirements can be harder to estimate. But you need a certain idea to start with and then testing is required with the alloc failed hook enabled.
Then you know if it’s sufficient or not
Basically it has nothing to do with FreeRTOS. It’s just C (embedded) application programming.