gcc heapsize check

[Youqun Sun]

Hello, 

In SDK14.2, select an armgcc project, for example, pin_change_int.

For nRF52840, the heapsize is defined in /components/toolchain/gcc/gcc_startup_nrf52840.S, and the default value is 8192.

In the code, I try to allocate a memory of 8193 bytes with below code:

uint8_t *p = NULL;
p = (uint8_t *)malloc(8193);
if (p != NULL) {
    nrf_drv_gpiote_out_set(PIN_OUT);  // LED off
}
else {
    nrf_drv_gpiote_out_clear(PIN_OUT);  // LED on
}

A NULL is expected as the reture of malloc function, but actually it never happens no matter how big the malloc parameter is.

In Keil/SES, the program behavior is correct with the same code.

What's wrong with it? Can we make the malloc return a NULL when hitting the boundary of the heap space?

(Yes, I have read this link, but there is not a valid workaround)

Best Regards,

Youqun

[Håkon Alseth]

Hi Youqun,

 

The dynamic memory allocation is handled by libnosys, and it is a very simple implementation that does not check for overflow:

https://github.com/eblot/newlib/blob/master/libgloss/libnosys/sbrk.c

This has been discussed in the launchpad bug register for arm-none-eabi as well:

https://answers.launchpad.net/gcc-arm-embedded/+question/218972

Cheers,

Håkon

[Youqun Sun]

Hello Hakon,

Thanks for your information.

In the end of the second link, some one said the issue is resolved, but our arm-none-abi version(4.9 2015-q3) is much newer than what they were discussed in the thread, and it is still here now.

So what we can do to avoid this issue? Do you have a good suggesiton?

Best Regards,

Youqun

[Håkon Alseth]

Standard malloc/calloc is something that we do not use in our SDK, and we therefore do not have much experience in that field.

This is a feature of newlib and libnosys (which does not seem to be patched, even though the bug report states it was!), which are libraries that GCC is told to use by the build system (Makefile). Based on the comments in that thread, it looks like -lrdimon checks for overflow. You can use that implementation instead and see if this works better. Note that this is very likely to produce a larger binary.

Best regards,

Håkon