• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 80 subscribers
  • Views 727 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.

Setting heap area

Sam Strohl
Prodigy 130 points
Other Parts Discussed in Thread: MSP430F5510

I'm using CCS5 and my target is MSP430F5510.  Normally the heap area is part of the 4 kb RAM space that is also stack space. Linker is telling me 800 bytes are available for heap.  I'd like to get more space by using the 2 kb USB buffer area for dynamic memory allocation.

Is it possible to separately set the heap area to be within the 2 kb of RAM normally used for USB buffer?

I'm not hopeful. 

Thanks.

- Sam

  • 0
    Expert 1010 points

    Sam,

    You post is not clear, so I am assuming you are not using the USB peripheral in your application.  If this is the case then you will need to change the linker file (lnk_msp4305510.cmd) to add the USB buffer as memory location.  In the 5510 the USB buffer starts at 0x1C00 and is 0x800 bytes long.

    In the memory section of the linker file you can add the line below to the MEMORY area.

    USB                     : origin = 0x1C00, length = 0x0800

    The modify the SECTIONS entry  

    .sysmem     : {} > RAM from this to .sysmem :{} > USB

    This tells the linker the location of the dynamic memory in the memory map, you also need to tell the linker how much of this to use in your build settings.

    Cheers,

    Darren

  • 0 in reply to Darren Beckwith
    Guru 227245 points

    Since the USB buffer ram is located directly beneath the normal ram, you can just change the starting address and size of the normal ram section. No further changes required and the linker then will assume a consecutive 18k ram area.

  • 0
    Prodigy 130 points

    Thanks for the help Darren and Jens-Michael.  You've both taught me something new, and I'm sure I will find it useful.

    After more thought, I decided managing the USB RAM area myself instead of using alloc/free would work better for the application.  I realized what I needed could be handled by a large array hosted in the USB RAM area, with a simple managed in-use flag for each row of the array.  I'd not need to worry about garbage collection and memory fragmentation.

    As you suggest, Jens, I could simply add the USB RAM area to the RAM pool and then use alloc to grab the space required.  Seems like a philosophical question as to whether doing this - adding it to the pool and using alloc - would be better than directly reading and writing into this area.

    Thanks again!

    - Sam

  • 0 in reply to Sam Strohl
    Guru 227245 points

    Well, malloc does prettymuch the same as any own space management woud do,. It is, however, more generic. So if you have fixed use patterns, allocating a fixed memory location (may be a large gobal array, allocated at linktime, or a memory segment outside linker usage that is accessed using a applicaiton-defined pointer) and managing its content may be more efficient than usign malloc. Also both method can be stacked: allocating a bug chunk oncew and then managing its use by application.

    Personally, I don't like the usage of 'external' memory, as it is difficult to understand (especially if not properly and well documented) and rises problems when re-using the code in other projects (e.g. where memory is at a different location). Adding any available ram to the pool and allocating storage space either with malloc or (better, because known at linktime, so on lack of memory, you get linker errors and not unexpected program crashes) a globally allocated array is more transparent and straightforward, as long as there are no hardware restrictions to the placement.

**Attention** This is a public forum