• Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 905 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/TMS320C6747: TMS320C6747

Khaldun Karazoun
Prodigy 10 points
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.

  • TI__Guru**** 232880 points

    Khaldun Karazoun said:
    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__Guru* 84225 points
    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
    Expert 1820 points

    Archaeologist said:

    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