Malloc failing on xTaskCreate

I trying to run the FreeRTOS demo program main_blilnky() for the RM46L852 and get a malloc failure the first time a task is created, specifically on xTaskCreate( vCompeteingIntMathTask, “IntMath”, intgSTACK_SIZE, ( void * ) &( xTaskCheck[ sTask ] ), uxPriority, ( TaskHandle_t * ) NULL );.

I have tried increasing the configMINIMAL_STACK_SIZE in FreeRTOSConfit.h from 128 to 1024 but it makes no difference. I have also tried doubling the configTOTAL_HEAP_SIZE; it still fails.

I’m using heap_4.

Any ideas to how to approach fixing this would be greatly appreciated!

If malloc is failing the first time a task is created then increasing the stack size will probably make it worse as it will result in malloc attempting to allocate a larger block.

If you are using heap_4 then the size of the heap used by the kernel (used by calls to pvPortMalloc()) is set by the configTOTAL_HEAP_SIZE constant in FreeRTOSConfig.h - what do you have that set to?

If you step through pvPortMalloc() inside the xTaskCreate() function, what do you see as the reason for the allocation failure.

Are you certain the C start up code is executing correctly? The C start up code should initialise variables, and if it is not executing correctly variables being left uninitialised will result in them containing random values which could in turn make malloc fail (not because you have run out of heap, but because you are using variables that do not have their correct values).

I have not changed any variables from the example code.

configTOTAL_HEAP_SIZE = 32768

The reason for the failure in pvPortMalloc is pvReturn = NULL. It is the first time that pvPortMalloc it is called, so pxEnd = NULL and prvHeapInit() is called. It executes prvHeapInit() twice, which I don’t understand why, and then checks “the requested block size is not so large that the top bit is set” ( if( ( xWantedSize & xBlockAllocatedBit ) == 0), which it is set. This leaves pvReturn = NULL because the memory is never allocated. This causes vApplicationMallocFailedHook() to execute.

This only occurred after I moved my code from one drive to another. And it is intermittent: sometimes when I compile, it works and sometimes it doesn’t. It is as though, as you said, that something is not getting initialized properly. Where might this be?

There is no path through the code that can happen. Are you stepping through the code in the debugger when you see this? Which path is it actually taking.

If it is truly expected to be set then I think you are trying to allocate a block that is bigger than your defined heap - so failing to allocate and returning NULL would be the expected behaviour. I think that is unlikely though - how big a block are you trying to allocate? Can you see that as the value of the xWantedSize parameter inside the pvPortMalloc() function - you should be able to step through the code and see exactly why each path is taken.

I suspect there is something more fundamentally wrong here - like you need to do a clean rebuild of the entire code base, or you are not connected to the hardware you think you are, or you are not able to program the flash correctly so the program actually in the microcontroller does not match the one you are trying to debug. In any case, this sounds like a tools issue rather than directly a FreeRTOS issue - my best guess is still that the C start up code is not executing correctly (which could mean the linker script is wrong).

Sometimes when I compile the code works, and sometimes it doesn’t. I have run a clean build and it still fails. I believe you are correct that something is not getting initialized correctly, but I don’t know what that might be.

I am having problems with CCS single stepping through the code - I cannot put break points in many places, and it doesn’t allow me to step to many of the lines of code. Does this mean that the debugger is not synced properly with the code? If so, I’ll chase TI on this problem and not bother you.


This is what I’m doing when I see the prvHeapInit execute twice (which it is not supposed to do, and maybe is not doing, but I just don’t understand…):

heap_4.c: place a bp on ln120 at vTaskSuspendAll() and a bp on ln124 “if( pxEnd == NULL )…”
Run to the bp on ln120
Step over vTaskSuspendAll()
Runs to ln124
Step over
Instead of stepping over prvHeapInit(), it enters that function
Step return: goes back to ln124
Step over
Instead of stepping over prvHeapInit(), it enters that function (again)
Step return: goes back to ln124
Step over
Steps to ln137

When this happens, xWantedSize = 512

If you still think that my linker script is probably wrong, I’ll get help on this from TI - don’t want to bother you with non-FreeRTOS stuff.

BTW: In your experienced opinion, if you were developing for TI Hercules parts, what IDE or tool would you recommend?

Which would be consistent with variables taking random values when you boot. I’m not saying that is what the case is, but evidence would suggest it is.

If you do something like this:

volatile uint32_t ulDummy = 0x12345678UL;

void main( void )
    configASSERT( ulDummy == 0x12345678UL );

    /* Rest of your code here. */

Do you hit the asset the first time you run the code?

Do you have optimisation turned on? If so then the object code may not match the C code directly, in which case you could see strange jumping around. Try without optimisation first.

I work with all IDEs and have good relationships with all IDE vendors - so I’m afraid I don’t recommend one over the other :smile:

I added the ulDummy declaration before main and the configASSERT inside of main. I do hit the ASSERT the first time I run the code.

I turned off compiler optimization; the debugger now appears to bypass prvHeapInit() all together!

Not really sure what to do next…

That would seem to prove the start up code is not initialising the variables. I think you will need to start a debug session from the entry point (before main() is called) so you can step through the start up code to see if it is initialising anything at all. You may need to ask the compiler vendor, I think it is clear at this point that it is not a FreeRTOS issue.

Another suggestion would be to use the tool to create a brand new project for the same chip, then compare the linker script and start up code to that in your existing project to see if you can notice any differences.

1 Like

I finally found the problem. It was as you suggested: the code was not linking properly. The problem occurred when I changed the processor type under the project properties. When that is done, the field for the Linker command file goes blank, and then without that specified, nothing works correctly… Moral of the story: never ignore warnings.

Thanks again for your help in pointing me in the correct direct direction; I learned a lot about freeRTOS through this exercise.

1 Like

Thanks for taking the time to report back.