Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by jembeddev on January 25, 2019

Hello Everyone,

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 configMINIMALSTACKSIZE to 8192 (since value is in words, that translates to about 32 kb). I also changed the value of configTOTALHEAPSIZE to 163,840 bytes (K65 has a total of 256 kb on its SRAM). I noticed if the value for configMINIMALSTACKSIZE 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?

Please, any help is greatly appreciated!

Thanks!!


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by rtel on January 25, 2019

I opened the FreeRTOS.h

I presume you mean FreeRTOSConifg.h, as you should never edit FreeRTOS.h.

file and changed the value of configMINIMALSTACKSIZE 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 configMINIMALSTACKSIZE, 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 configTOTALHEAPSIZE to 163,840 bytes (K65 has a total of 256 kb on its SRAM). I noticed if the value for configMINIMALSTACKSIZE 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.


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by jembeddev on January 27, 2019

Thanks for the reply!

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?


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by richarddamon on January 27, 2019

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?


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by jembeddev on January 28, 2019

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.


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by richarddamon on January 28, 2019

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,


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by jembeddev on January 28, 2019

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?

Thank you for your help thus far!


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by richarddamon on January 28, 2019

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 configTOTALHEAPSIZE 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 keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by rtel on January 28, 2019

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.


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by jembeddev on February 4, 2019

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 keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by rtel on February 4, 2019

Turn semi-hosting off in the debugger configuration.


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by jembeddev on February 4, 2019

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 keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by jembeddev on February 8, 2019

**update

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.


I keep running into the following error message: configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

Posted by jembeddev on February 19, 2019

Are there any particular patterns or common themes in terms of bugs, that programmers tend to create that results in a semi-host hard fault handler?


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Mediatek

Renesas

RISC-V

SiFIve RISC-V

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner