CCS/TMS320C6747: TMS320C6747

Part Number: TMS320C6747

Tool/software: Code Composer Studio

We deployed TI DSP 6.2.0 code Composer with our project. The previous CC version was 3.3.

We are seeing issues with malloc and heap allocation.  For example, malloc call was not able to get memory allocation because the heap was all reserved. We know that heap was not over allocated.

Is there a flag or an option with new CC 6.2.0 that affects malloc and heap allocation and release.

For some reason if the malloc fails and reloads dsp sw, why dsp gets into same reload loop even with fresh sw reload.

3 Replies

  • Khaldun Karazoun
    Is there a flag or an option with new CC 6.2.0 that affects malloc and heap allocation and release.

    You can change the size of the heap with the option --heap_size.  In CCS, right-click on the name of the project and choose Show build settings.  In the tree like structure on the left, browse to Build | C6000 Linker | Basic Options.  On the right there is a text box where you can enter a value for --heap_size.

    Thanks and regards,

    -George


    TI C/C++ Compiler Forum Moderator
    Please click Verify Answer on the best reply to your question
    The CCS Youtube Channel
     has short how-to videos
    The 
    Compiler Wiki answers most common questions
    Track an issue with SDOWP. Enter your bug id in the Search box.

  • There is no option which controls the allocation strategy, just the one option to control the size that George mentions.

    If malloc fails, and the program writes through the returned NULL pointer without checking it, that is undefined behavior. Depending on what is actually at address 0, this could have unpredictable effects on the program. I could not even begin to guess why a "fresh sw reload" would be affected.
  • In reply to Archaeologist:

    Archaeologist

    I could not even begin to guess why a "fresh sw reload" would be affected.

    I'll venture a guess. A typical bug that would show erroneous behavior across a clean reload is accessing unitialized memory (usually on the stack). If the device is left powered-down for a while, the memory contents will be quite predictable, but if the program is reloaded and/or the device is only briefly turned off, the memory will retain its current content, and if your program depends on some uninitialized value it might immediately crash again.

    That is just a guess, though.

    Markus