I am using FreeRTOS on the K65 MCU and I keep running into an assert error stating the FreeRTOS kernel could not be started, because I did not have enough memory in the FreeRTOS heap.
I opened the FreeRTOS.h file and changed the value of configMINIMAL_STACK_SIZE to 8192 (since value is in words, that translates to about 32 kb). I also changed the value of configTOTAL_HEAP_SIZE to 163,840 bytes (K65 has a total of 256 kb on its SRAM). I noticed if the value for configMINIMAL_STACK_SIZE is too low (such as its initial value of 90 words aka 360 bytes), I get a semi host hard fault.
These values for the stack and heap size should be PLENTY ENOUGH to create a couple threads, yet I keep running into this assert error. I am not sure what I am possibly doing wrong. When I go through the debugger, it keeps pointing to that line in vTaskStartScheduler() function definition.
Since memory is dynamically allocated in the creation of tasks, is there something else I am suppose to do? As in do I manually need to “point” FreeRTOS to use the heap to create the tasks?
I presume you mean FreeRTOSConifg.h, as you should never edit FreeRTOS.h.
file and changed the value of
configMINIMAL_STACK_SIZE to 8192 (since value is in words, that
translates to about 32 kb).
The only place the kernel uses that constant is to dimension the size of
the stack allocated to the idle task. The constant is however used in
lots of placed in our demo code too (to make the demos portable across
architectures). If you want to save memory for other tasks, then do not
increase configMINIMAL_STACK_SIZE, ad it will result in more memory
being consumed by the idle task. It is unlikely the idle task will need
a higher value than 100 unless you have added your own code into the
idle task by implementing an idle hook function.
I also changed the value of
configTOTAL_HEAP_SIZE to 163,840 bytes (K65 has a total of 256 kb on its
SRAM). I noticed if the value for configMINIMAL_STACK_SIZE is too low
(such as its initial value of 90 words aka 360 bytes), I get a semi host
hard fault.
That is probably a clue to the route cause of your problem - you will
not be able to use FreeRTOS and semi hosting at the same time.
That is interesting that I won’t be able to use FreeRTOS and semi hosting at the same time. When I was first learning the FreeRTOS API, I created a couple small programs where I created a task and I printed out the results in MCUXpresso IDE console via semi hosting. Why did it work back then? Unless I misunderstood your statement about not using FreeRTOS and semi hosting at the same time?
Semi-hosting may not be totompatable with FreeRTOS, but may not work well with it. Semi-hosting tends to block up the CPU doing I/O, which isn’t really supportive of ‘real time’ requirements.
A couple of important questions:
Which Heap#.c file are you using?
Can you look back on the stack track when it stops on lack of heap, what allocation is it trying to do?
Heap#.c file? I am not sure. Could you please direct me on how to find that out?
It seems the lack of heap error appears because xReturn != pdPASS meaning the task was not successfully created, which is weird since in other parts of my code I have the return value of xTaskCreate() and the pointer value of the task’s handle printed out and they are non-zero, non negative values.
As part of your project, you need to include one of the files heap1,c, heap2,c, heap3.c, heap4.c, or heap5.c to provide the definitions the of memory allocation functions for FreeRTOS. These files are in the src/portable/memmang directory.
xTaskCreate() returns the task handle, so you should not be comparing its value to pdPASS,
For the heap files, is this where I configure pvPortMalloc() to use a particular HEAP management system? If so how do I go about doing that? Also how do I go about choosing among the different heap files?
I found the heap1.c, heap2.c, heap3.c, heap4.c and heap5.c in the amazon-freertos/portable directory. I did not find the specific directory you mentioned. I did notice all of the heap files have a diagonal slash through them and appear to be kinda greyed out, except for heap4.c.
The xReturn == pdPASS line that failed was in the function definition for vTaskStartScheduler(). Also I thought it was xTaskCreateStatic() that returns the task’s handle, where as xTaskCreate() returns a positive or negative value that is comparable to pdPASS?
The slash is your IDE’s way of showing that those files are not being used, so it looks like you are using heap4.c
I was misremembering the API, xTaskCreate takes a pointer to return the handle, not returning it itself (I mostly use wrappers so I don’t write many calls to the direct API).
heap4.c does use the configTOTAL_HEAP_SIZE parameter, so you should have that much heap.
That says that it sounds like you are running out of heap. Perhaps the best option would be to put a breakpoint just inside pvPortMalloc so you can see who is using up your heap memory, and look at the sizes of each of the allocations.
I found the heap1.c, heap2.c, heap3.c, heap4.c and heap5.c in the
amazon-freertos/portable directory. I did not find the specific
directory you mentioned.
…because it sounds like you are using files from the Amazon FreeRTOS
repo, rather than from the FreeRTOS kernel download.
I did notice all of the heap files have a
diagonal slash through them and appear to be kinda greyed out, except
for heap4.c.
…so you are using heap_4.c.
The xReturn == pdPASS line that failed was in the function definition
for vTaskStartScheduler(). Also I thought it was xTaskCreateStatic()
that returns the task’s handle, where as xTaskCreate() returns a
positive or negative value that is comparable to pdPASS
That is right, xTaskCreate() return pdPASS/pdFALSE (actually an error
code that says it run out of heap space, which is the same value as
pdFALSE). The handle is passed out using the last parameter.
So I was able to resolve the heap issue. I put a breakpoint inside pvPortMalloc() as recommended and realized that it was indeed semi-hosting code that was eating my heap space. It turns out semi-hosting while it may work with FreeRTOS from time to time depending on the application, it is in general very problematic and best left alone (as mentioned by Richard Barry). So I basically redirected my output to TeraTerm via UART.
Now I am no longer getting the “ran out of heap memory to start the kernel” error message, however I am getting a semi-host hard fault handler towards the end of my program execution. I was wondering how was this possible, since I thought I removed all semi-hosting code (via remapping of printf() to DbgConsole_Printf() in MCUXpresso IDE)?
The semi-host hard fault handler occurs as soon as the debugger steps into vTaskStartScheduler(). What semi-hosting code could be inside that function?
I thought I did that when I switched the SDK debug console from semi-hosting to UART? Let me double check if there is any extra configurations I still need to do.
Also I want to point out the specific line in vTaskStartScheduler() that they semi host hard fault occured at: if( xPortStartScheduler() != pdFALSE ) at line 1998.
I found additional instructions to turn off semi=hosting in the debugger configuration by editing the libraries (switching from semi-host to no-host) and unfortunately that did not resolve the semi-host hard fault issue.
So I decided to dig further with the debugger inside xPortStartScheduler() ** and I noticed that the semi-host hard fault occurs exactly when I try to step into the following line:
** prvProcessReceivedCommands() at line 533 in timers.c file.
I’m not sure if this information further confirms I am still not turning off semi-host properly in the debugger configuration or if something else is at play now.