Microchip XC32 compiler, malloc call returns 0, writing to pointer throws Unimplemented RAM

Question

I'm coding on MPLAB, using the XC32 compiler, and trying to get the hang of using dynamic memory, so I created a basic example program:

#include <stdlib.h>
#include <plib.h>

char x;
char y;



char main(void)
{
    Nop();
    char *pLocation = (char *)malloc(16);
    if(pLocation == 0x00)
    {
        return 0;
    }

    for(x = 0;x<=7;x++)
    {
        *pLocation = x;
        pLocation++;

    }
    while(1)
    {

        Nop();
    }
}

Problems:

When the pointer gets to the malloc call line, the value of pLocation is forced to 0x00 meaning that it somehow managed to fail to pass me pointer information from the heap.
When the pointer gets to assigning the value of x to the location of the pointer pLocation I get a Bus Exception saying Unimplemented RAM memory access. I suspect this is because I tried to write to 0x00.

Am I doing something wrong in the code?

Additional Information:

I have already assigned a heap of 16 bytes.
I get the same error for memory requests of even size 2.
I am using the MPLAB SIM debugger.
MPLAB Version 8.87.00.00.
Building with the XC32 compiler.

When you have a NULL pointer you shouldn't lament about umimplemented RAM access errors. What do you mead with "have assigned a heap of 16? If this means you have reserved 16 bytes for heap you should consider the necessary heap management. You will always have to reserve more memory than you want to malloc successfully. — harper
possible duplicate of Is there a need to check for NULL after allocating memory, when kernel uses overcommit memory — osgx
Thank you for your response harper, I agree that I will have to consider memory management however I need to get the malloc working first then I will play with the Free function. and I get the same error for malloc(2) — user1167219
What is sizeof(char) in your system? 1? 2? As mentioned above: A heap size of 16 might not be sufficient to handle malloc(16). Add a few bytes for overhead. — Axel Kemper
@osgx: That may be the case, but the problem in the first instance comes from allocating too small a heap. This is tagged embedded and refers to a system with no OS to provide memory management. It is a developer requirement to allocate space for a heap in this case. So it is not a duplicate. — Clifford

Clifford Clifford · Accepted Answer · 2013-01-10T13:51:00

I have already assigned a heap of 16

That is insufficient heap space to support an allocation of 16 bytes. An amount of space is required for heap management, and each allocation will have guaranteed alignment of typically 8 bytes to ensure alignment of 64 bit data types.

You should allocate far more heap than necessary, and certainly more than 16 bytes - for that you may as well use the stack or static allocation.

Typically you would want to allocate all available memory not used for other purposes (stack-space, statics, DMA pools etc.) to the heap since it will be unused otherwise (you might allow a little headroom so that in maintenance small changes to static allocation don't require you to change the heap size) ; but you can test my hypothesis simply by increasing the heap allocation to 1024 bytes for example. If you don't have that much available, then your system really is not suited to supporting a heap at all perhaps.

Microchip XC32 compiler, malloc call returns 0, writing to pointer throws Unimplemented RAM

2 Answers