Hi,

I searched the forum and see that others have asked this question but I can't see where it has ever been answered completely.  What is the amount of memory allocated to the heap on an LPC1768 mbed? 

I program the Philips LPC2138 using Keil in addition to working on the mbed.  In the LPC2138 program, there is a definition of HEAPSIZE in startup.s where the size is defined.  Is there a similar definition in the mbed startup file? 

Currently, it uses the shared heap/stack memory model, so your heap size is only limited by the RAM (32K) and the size of the stack.

That being said, there is an outstanding bug (which is currently being investigated) that malloc() is not reliably returning NULL if it cannot allocate space, and in these situations it is allocating on to the stack, which generates a Hard Fault. For more information have a look at this thread: http://mbed.org/forum/mbed/topic/433

Thanks Jon, that's helpful!  Does this mean that the heap size is dynamic - the available heap size varies as the stack grows and shrinks during program execution?

Also, would the malloc issue possibly be the reason that my serial channel will cause the mbed to lockup because I've implemented a tx message queue involving malloc?  Basically I've created attached functions to handle the serial data (rx and tx) using the *.putc/*.getc functions that get called at interrupt time.

It's more that there is no defined maxiumum heap size, rather than it being a dynamic limit.

As for your issue, I can only say "it is possible", as I do not know much about your system. Three things you could try:

1. Create a fixed-size ring buffer instead of dynamic allocation
2. Create a hard fault handler as seen in that thread I linked to - if it does trigger blue lights of death, then the chances are that you have a heap/stack collision (not for certain, but likely).
3. Create a watchdog which can reset you if you do get locked up - again an example of this is in that thread 433.

Something that may assist understanding is does it lock up almost immediately, or does it run for a bit then fall over? Also, are you allocating a big chunk 'o memory at/near the beginning, or just bits as and when needed? If you are allocating lots of little bits, the more of these you have being used (and not being freed), the less efficient in memory the malloc()s become, as it allocates larger chunks.

Another possibility that I cannot ignore is that the Serial transmit interrupt attach is new, and although I have tested it quite a bit, it is possible there is a bug in it.

Thanks again Jon. 

To your last point about the serial Tx interrupt, I have tried both approaches (timer based and interrupt based) and both suffer from the same issue so I think your interrupt implementation is solid.  I do not allocate a big chunk of memory anywhere.  However I do create 50 - 100 smaller chunks (2 - 50 bytes each) in bursts with sprintf's intermingled as part of my message queueing functionality. 

I send one byte to the Tx module using a putc() and let the interrupt fill the remaining 15 bytes of the Tx hardware FIFO.  I feel the problem happens if I don't complete allocating the 50 - 100 chunks before the Tx FIFO is emptied (at 57.6K).  This port is essentially painting a HyperTerm window with ANSI commands.  Much of the window is painted prior to the lockup.

My latest experiment to cure this is to avoid my Tx queuing mechanism and use the printf() for each of the 50 - 100 messages.  This works and does not generate the lockup however it does stall my kernel during the printf() execution.  This is not my desired behavior since I have the two other serial ports (P9/10 and USBRX/Tx) active too though currently not active when the lockup occurs and I worry about loosing Rx data on these ports.

Given the time (for some reason they want me to be productive here :-) ), I want to try to implement your good suggestions to get at the root cause.