Malloc returns NULL Pointer in FreeRTOS task.

[FedeRico1]

Hello Community,

I'm using an ST Nucleo-F767ZI and I create my project, for Atollic True Studio, with Cube32MX.

In my project I included FreeRTOS v10.

I'm in troubled with the malloc function, because this function return a NULL pointer.

I have several tasks, and I'm not able to allocate memory inside a task.

If I invoke the malloc function in the main.c, the function returns a pointer.

I don't know why this happens.

Thanks for the help.

Federico

[Tesla DeLorean]

>>I don't know why this happens.

You've presumably got all the source code, couldn't you look and do some static analysis?

Check if the heap has a mutex, and is thread-safe.

Check if the heap is fragmented, walk the heap in the failure condition and understand the allocations.

Use local/auto variables where possible.

[FedeRico1]

Hi Clive,

Just for my undestanding, does FreeRTOS with heap4 allows malloc?

I alloc memory as first instruction in the task.

Thanks for your time.

Federico

[Alex R]

You may want to look into FreeRTOS specific functions to provide memory buffers like Queue and Message:

https://www.freertos.org/a00018.html

https://www.freertos.org/RTOS-message-buffer-API.html

[FedeRico1]

I know Messages and Queues but a Middleware that I included into my project requires malloc function.

[FedeRico1]

My project is created with cubeMX 5.2.0 and I use FreeRTOS v10.0.1

Now I have a problem with malloc function, inparticular, with this new FreeRTOS version (v10.0.1) if I call malloc function inside a task, the function returns a null pointer. If I call the malloc function in the main.c the function retrun a non null pointer.

I tested the same project with FreeRTOS v9 and the malloc function works also inside a task.

[JB2500]

Federico

I have the same problem. I'm using CubeMX V5.3.0 + STM32Cube_FW_F7_V1.15.0 + FreeRTOS V10.0.1.

Did you find a solution?

Essentially my problem is that all memory allocation functions, including malloc, calloc, and pvPortMalloc, return NULL even for small requested sizes e.g. 16. They succeed if called outside any tasks, before any tasks are started.

I've tried heap_1 + heap_3 + heap_4 FreeRTOS heap types.

configSUPPORT_STATIC_ALLOCATION is 0, and configSUPPORT_DYNAMIC_ALLOCATION is 1.

The allocation functions work when I use FreeRTOS V9.0.0 (in STM32Cube_FW_F7_V1.13.0).

Cheers,

JB.

[Pavel A.]

Have you seen this? http://www.nadler.com/embedded/newlibAndFreeRTOS.html

-- pa

[JB2500]

Thanks!

Excerpt: As of July-2019, Cube-generated projects using FreeRTOS do not properly support malloc/free/etc and family, nor general newlib RTL reentrancy.

[JB2500]

I'm trying to understand why, like FedeRico, my memory allocation calls work when called from FreeRTOS tasks in my STM32F767VI project that uses STM32Cube_FW_F7_V1.14.0 (and hence RTOS V9), but not when the same project uses STM32Cube_FW_F7_V1.15.0 (and hence RTOS V10).

The STM32Cube_FW_F7_V1.15.0 project, but not the STM32Cube_FW_F7_V1.14.0 project, has a syscalls.c file in the Src folder.

This file has a _sbrk function.

This _sbrk function is not compatible with FreeRTOS because it checks that the heap doesn't collide with the top-of-memory stack and this always fails when FreeRTOS tasks call memory allocation functions because their stacks are further down the heap (info from Dave Nadler in the above link (http://www.nadler.com/embedded/newlibAndFreeRTOS.html)).

When this syscalls.c file is present, the _sbrk function in it is called when a memory allocation function is called.

When it is not present, a different _sbrk function is called. Here it is:

08010ca0 <_sbrk>:
 8010ca0:	4b04      	ldr	r3, [pc, #16]	; (8010cb4 <_sbrk+0x14>)
 8010ca2:	6819      	ldr	r1, [r3, #0]
 8010ca4:	4602      	mov	r2, r0
 8010ca6:	b909      	cbnz	r1, 8010cac <_sbrk+0xc>
 8010ca8:	4903      	ldr	r1, [pc, #12]	; (8010cb8 <_sbrk+0x18>)
 8010caa:	6019      	str	r1, [r3, #0]
 8010cac:	6818      	ldr	r0, [r3, #0]
 8010cae:	4402      	add	r2, r0
 8010cb0:	601a      	str	r2, [r3, #0]
 8010cb2:	4770      	bx	lr
 8010cb4:	2001333c 	.word	0x2001333c
 8010cb8:	20015a90 	.word	0x20015a90

This one does not result in the memory allocation function call failing (returning NULL). (I don't know whether it is fully compatible with FreeRTOS).

My STM32Cube_FW_F7_V1.15.0 project can be made to call the same code by renaming or deleting the _sbrk function in syscalls.c. It then works.

Fortunately, this file modification does not appear to be lost when the project is regenerated from CubeMX. However, I'd like not to have to make this change each time I create a project in CubeMX.

Finally, one odd thing: In the *.list file of my projects that have the syscalls.c file, there is this:

void SPDIF_RX_IRQHandler(void)
{
 800dd28:	b508      	push	{r3, lr}
  /* USER CODE BEGIN SPDIF_RX_IRQn 0 */
 
  /* USER CODE END SPDIF_RX_IRQn 0 */
  HAL_SPDIFRX_IRQHandler(&hspdif);
 800dd2a:	4802      	ldr	r0, [pc, #8]	; (800dd34 <SPDIF_RX_IRQHandler+0xc>)
 800dd2c:	f7f5 fe45 	bl	80039ba <HAL_SPDIFRX_IRQHandler>
 800dd30:	bd08      	pop	{r3, pc}
 800dd32:	bf00      	nop
 800dd34:	20015474 	.word	0x20015474
 
0800dd38 <_sbrk>:
	}
	return len;
}

I don't understand why the "<_sbrk>" is in such a bizarre place. (The list file also has the _sbrk function from the syscalls.c file). Is it an error?

Help appreciated.