malloc causes hard fault

[lpcware]

Content originally posted in LPCWare by xander.houtman on Fri Jan 23 07:10:51 MST 2015
Hello LPC community,

While debugging I stumbled on a rather stange bug: at seemingly random moments, a hardfault would be generated.
After three days of debugging I narrowed at least one of the causes down to the following code:

#include "stdlib.h"
int main(void) {
volatile void* mem[64];
int blocksize = 1024;
for (int i = 0; i < 64; i++) {
mem = malloc(blocksize);
if (mem == NULL) {
break;
}
}
volatile static int i = 0;
while (1) {
i++;
}
return 0;
}

The above code generates a hard fault before breaking the first loop.

Im running the code on the Keil MCB1700 debug boards, which uses the LPC1758.

I thought this was related to the malloc bug that was supposedly fixed in LPCXpresso 7.5.0.
However, I installed the new version, created a new workspace, a new project and pasted the above code into it, and the bug was still present.

The hard fault is generated after allocating about 32kb. Even though, if I understand the datasheet correctly, the 1758 should support 64kb RAM. And more importantly, malloc should simply return NULL if it runs out of memory.

Does anyone know what is going on here?

edit: made the include html friendly.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Sat Jan 24 09:19:32 MST 2015
As described in the FAQ, you can do this without needing to modify the linker scripts - just use defines in the linker properties.

The next LPCXpresso release (due in the near future) will make this  easier by providing symbols for the start and end of all the RAM regions too (as discussed in http://www.lpcware.com/content/forum/using-userheapbase-doesnt-change-map-file#comment-1141866). The Heap allocation FAQ will be updated shortly to reflect this.

With regards to defaults for heap limits and checking, up until recently, again as described in the FAQ, LPCXpresso defaulted to having the heap checked against the stack pointer. However this was disabled because of the number of customers for whom this simple check actually triggered further problems (e.g when task switching was taking place).

It is fair to say that this whole area is one that we are actively investigating, so you may see further changes in the documentation and ability to modify the settings in future LPCXpresso releases.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by xander.houtman on Sat Jan 24 04:03:20 MST 2015
Many many many thanks!

I had no idea I would have to fiddle with linker scripts!

I replaced the last lines of the template file with the following:

PROVIDE(${heap_symbol} = DEFINED(__user_heap_base) ? __user_heap_base : ADDR(.data_RAM2));
PROVIDE(_pvHeapLimit = DEFINED(__user_heap_base) ? __user_heap_base + 0x8000: ADDR(.data_RAM2) + 0x8000);
PROVIDE(_vStackTop = DEFINED(__user_stack_top) ? __user_stack_top : __top_${DATA} - ${STACK_OFFSET});

With great succes!

This leaves me with one question:
Why are these values not set by the MCU specific configuration?
Setting these values automatically ensures that malloc confirms to C specs by default, without the user having to fiddle with linker scripts.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Jan 23 08:37:16 MST 2015
You have of course already read the FAQ on heap setup and checking ?  ;-)

http://www.lpcware.com/content/faq/lpcxpresso/heap-checking-redlib

Anyway, I don't believe this is a bug - you simply haven't set the heap up correctly. In order to investigate further, please can you confirm:

[list]
  [*]Where is the base of your heap defined to be?
  [*]Where is the end of your heap defined to be?
  [*]Have you provided your own __check_heap_overflow() function?
[/list]

It would also be helpful to see your linker map file.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Jan 23 07:36:00 MST 2015
It looks like you MAY have found a bug here, that we will investigate. However.
- Only a single, contiguous, heap is supported
- The LPC1758 has a TOTAL of 64k of RAM, split across two (non contiguous) 32k areas
- Therefore, the MAXIMUM size of the heap will be 32k.
BUT
- each memory allocation also has to allocate enough space for the heap admin data (size of the block, pointer to next free block etc etc), meaning that each malloc adds about 14 bytes to each allocation
- the default heap is placed at the end of the data (RAM) area for your code, reducing the maximum amount that can be allocated
- the default stack is placed at the end of that same RAM area, further reducing the amount available to your application.

See this FAQ on the heap, especially the section on checking for heap overflow
http://www.lpcware.com/content/faq/lpcxpresso/heap-checking-redlib

[lpcware]

Content originally posted in LPCWare by R2D2 on Fri Jan 23 07:30:51 MST 2015

---

Quote: xander.houtman
...The hard fault is generated after allocating about 32kb. Even though, if I understand the datasheet correctly, the 1758 should support 64kb RAM.

---

64kB is the Total RAM  :O

UM:

---

Quote:
Devices containing more than 32 kB SRAM have two additional 16 kB SRAM blocks,

---