• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 834 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C1294XL: Heap Size Fails At 2K+ Despite Much More SRAM Available

Terence D
Intellectual 755 points

Part Number: EK-TM4C1294XL

Hi, I'm attempting to use the heap on a EK-TM4C1294XL.  I'm developing using CCS 8.0.  Setting the heap to 2048 bytes and calling new() works fine.  However, once I get above 2368 bytes or so the new() ends up throwing me into the FaultISR() when malloc() calls minit() in memory.c.  I'm not sure why this is, but my guess is because total data is very close to 64K.

The grand totals in the "module summary":

Code: 54945  RO Data: 2727   RW Data: 5837  = 63,509 

Plus BSS: 464 bytes

However, I thought I have 256K of SRAM on this board.  Anyone know why I'm being limited to 64K?

 

  • 0
    TI__Guru**** 191886 points

    Hi Terence,

     Have you first tried to increase the heap size to the desired size you need?

    In the below post Chester suggested another method to reserve the remaining RAM for heap size that you might find helpful.

  • 0 in reply to Charles Tsai
    Intellectual 755 points

    Hi Charles - Thanks for the reply.  My replies to your question/comment:

    Charles Tsai said:

     Have you first tried to increase the heap size to the desired size you need?

    Yes, this is exactly how I set the heap size.  My problem is that anything less than 2368 bytes or less works fine, and 2432 bytes or more causes a the fault when using new().  And yes, I need more than 2,432 bytes of dynamic memory allocation...  Much more (like 64K) would be nice.

    Charles Tsai said:

    In the below post Chester suggested another method to reserve the remaining RAM for heap size that you might find helpful.

    Interesting...  I'm looking at this right now.... 

  • 0 in reply to Terence D
    Guru 92251 points

    Terence D said:
    Yes, this is exactly how I set the heap size.  My problem is that anything less than 2368 bytes or less works fine, and 2432 bytes or more causes a the fault when using new().  And yes, I need more than 2,432 bytes of dynamic memory allocation...  Much more (like 64K) would be nice.

    The following attached C++ program for a EK-TM4C1294XL makes use of the auto-heap sizing in Compiler/DK-TM4C129X: any way to maximize the heap size?

    This is a minimal program using TI ARM compiler v18.1.1, in which the debugger is used to view the maximum allocation which can be allocated by new(). It keeps calling new() with increasing sizes until gets a failure.

    The linker allocated 261608 bytes for the heap, and the maximum allocation by new() was 261596 bytes.

    TM4C129_max_heap_size.zip

  • 0 in reply to Chester Gillon
    Intellectual 755 points
    Thank you, Chester. Very helpful. One question: Any idea why this is not the default behavior for the compiler when giving it the --heap_size option?
  • 0 in reply to Terence D
    Guru 92251 points

    Terence D said:
    One question: Any idea why this is not the default behavior for the compiler when giving it the --heap_size option?

    I don't know the history behind the --heap_size option. Currently, the allocation of the heap size is distributed between:

    a) The memory.c source file in the run time library, which expects a special section .sysmem and the linker symbol __SYSMEM_SIZE for base address and size of the heap.

    b) The linker which creates a .sysmem section of the size specified by the --heap_size option, and sets the __SYSMEM_SIZE symbol to the heap size.

    c) The device specific linker command file which has to place the .sysmem section in a suitable writeable memory region.

    CODEGEN-4635 has been raised an enhancement request, but don't yet know which of a), b) or c) will be changed in a way which doesn't break backward compatibility with existing projects.