GNU Arm Embedded Toolchain

Issues with dynamic memory allocation on bare metal cortex-m4 using rdimon

Asked by Mayuresh Kankekar

In the course of setting up TDD environment, I am trying to have dynamic memory allocation & semihosting for my bare-metal cortex-m4 based platform. Semihosting is enabled by linking -lrdimon and using initialise_monitor_handles() call.

Now, when I use malloc, initially it gave an error as "undefined reference to 'end'"

In my linker script, I defined 'end' which marks beginning of heap section.

After this, compilation was successful, but malloc always returns NULL. As _sbrk defined in syscalls.c in newlib nano source only uses end symbol from linker script, I am not sure why malloc fails. I could access 'end' from other files in the project and it seemed okay.

Am I missing something very basic here? I would really appreciate some help.

Also, a more general question, when I use nosys.specs, system calls are not at all used?

Thanks.

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Tejas Belagod
Solved:
Last query:
Last reply:
Revision history for this message
Best Tejas Belagod (belagod-tejas) said : 		#1

Hi,

You have to make sure your linker script is in sync with what _sbrk expects. If you're using rdimon.specs to link, that means you're using the newlib-provided syscall implementation. _sbrk in newlib/libgloss/arm/syscalls.c does some limit-checking and returns ENOMEM if there's a clash with the stack.

I'd double-check your linker script to make sure you have the limits of the heap and stack symbols defined in the right place.

OTOH, if you use nosys.specs, _sbrk does not do any checking. nosys in general only provides stub implementations of syscalls - you'd have to override them with your implementation.

Thanks.

Revision history for this message
Mayuresh Kankekar (mayuresh-kankekar) said : 		#2

Hello Tejas,

Thank you for the quick response & you pointed out the exact cause of the problem, the limit checking.

As the memory layout is custom made, stack was actually defined above below heap because of which limit checking was failing.
Corrected this just now & malloc is working great.

About nosys, so I understand that with just nosys.specs, I cannot expect any functionality that involves these syscalls. Please correct me if I am wrong.

Regards,
Mayuresh

Revision history for this message
Mayuresh Kankekar (mayuresh-kankekar) said : 		#3

Thanks Tejas Belagod, that solved my question.