malloc from a ucos-iii task

malloc from a ucos-iii task

Home Forums Real-Time Kernels malloc from a ucos-iii task

This topic contains 2 replies, has 3 voices, and was last updated by  Bryan Pape 3 years, 4 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #15866

    Farhad Gholami

    We are finding that malloc works fine when called before the OS is started. When called from a thread it fails and return a NULL pointer. I suspect this is due to a check against the stack which is of course not valid when running in a thread which can have an arbitrarily placed stack.
    I can see in the map file that the library is referring to an ADI specific sbrk (lib_a-sbrk.o)function and I cant find any source for that function.
    It is commonly known that the default GNU sbrk function will check against the current stack pointer to see if the current break is beyond the SP and fail.

    Unfortunately we have to rely on malloc as we are using a complex C++ library, as we have megabytes of memory we are not concerned about fragmentation, we just want malloc to work. We are actually not even concerned about re-entrancy as we are only using malloc in a single thread.


    Matt Gordon

    It’s certainly the case that the stack pointer will lie outside of the bounds of the C stack while a µC/OS-II (or µC/OS-III) task is executing. If this is influencing the behavior of a library function within CrossCore Embedded Studio, then Analog Devices would be the best source of support. The porting and integration work needed for Micrium’s kernels to run in CrossCore was undertaken by Analog Devices engineers, so any requests for source code or for modifications would need to be directed to that team.

    • This reply was modified 3 years, 5 months ago by  Matt Gordon.
    • This reply was modified 3 years, 5 months ago by  Matt Gordon.

    Bryan Pape

    Hi Farad,

    I’m successfully instantiating C++ objects from a class from within a uC/OS-III task in a “mostly C” project. I should state that instead of “malloc” I’m using “new” (through a wrapper).

    I was initially getting null pointers as well until I set up my sections in accordance with what was required for sbrk, which was to create one section in the linker called “BHEAP” (which should probably just follow all the other statically assigned ranges in RAM) and “BSDRAMEND”, which is really just a marker to identify the last usable address that “new” or “malloc” can use. (Of course I figure that the your section names might be different, but it sounds like you’ve found them in the .o file already.)


Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

View the complete site map