• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1491 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.

DSP/BIOS heap on C6713

Todd Anderson78572
Guru 14640 points

All:

The product I am working with uses C6713 and DSP/BIOS.

In the BIOS definition of IRAM, we create a Heap, with size 0x5400. I was told that this would override the heapsize in the project options (under the linker tab).

With the linker tab, a heapsize of 0x8000 was defined.

When the project is built, it appears that the tools create a heap in IRAM of size 0x5400, AND a .sysmem section in IRAM of size 0x8000. It also appears that the IRAM "heap" is not being used for dynamically created memory, but instead .sysmem is being used.

Is there a way to make sure that the heap created by DSP/BIOS in the IRAM section will be used for dynamically created memory? (In C++, a "new" causes creation in dynamic memory.)

I have been searching for definitive answers on this, and I have been unable to find anything.

This is built with CGT 7.4.6, BIOS 5.42, CCS 5.5 - anything else needed to help with this problem?

 

 

  • 0
    Guru 14640 points

    All:

    CCS5.5, DSP/BIOS 5.42, CGT 7.4.6

    I am not sure what the DSP/BIOS "create heap in this memory" does, but the real heap is defined by the linker tab, and it is placed into the .sysmem section. I am not able to uncheck the "create heap in this memory" box, so I have decreased the size to a small number of words.

    Our project monitors the usage of the defined heap by initializing a known value prior to loading the code from flash. It uses global labels __sys_memory (location) and __SYSMEM_SIZE (size) for the initialization routine.

    This is a difference when moving from CCS3.3, where different global labels defined the heap.

     

  • 0 in reply to Todd Anderson78572
    TI__Mastermind 20805 points

    Hi Todd --

    DSP/BIOS provides its' own version of the malloc/free() code that takes precedence over those functions in the compiler's RTS library.  The memory section that malloc/free uses is controlled by the "MEM" module in the configuration tool.

    malloc() and free() internally use the MEM_alloc()/free() APIs to do memory allocation.

    Are you doing something special in your setup to bypass this?


    Thanks,
    -Karl-

  • 0 in reply to Karl Wechsler
    Guru 14640 points

    Karl:

    Here are my CCS5.5 settings:

    Compiler Summary of Flags

    -mv6700 --abi=coffabi -O3 --symdebug:skeletal --optimize_with_debug=on --include_path="C:/ccs5/ccsv5/tools/compiler/c6000_7.4.6/include" --include_path="C:/1000NX/Application/7450010/Source/DSP_CCS5/release" --include_path="C:/1000NX/Application/7450010/Source/DSP_CCS5/release" --include_path="C:/ccs5/bios_5_42_01_09/packages/ti/bios/include" --include_path="C:/ccs5/bios_5_42_01_09/packages/ti/rtdx/include/c6000" --include_path="C:/ccs5/xdais_7_21_01_07/packages/ti/xdais" --define=c6713 --define=CCS5 --quiet --display_error_number --gen_func_subsections=on --mem_model:data=far --use_const_for_alias_analysis --single_inline --std_lib_func_defined -k --output_all_syms

     

    Linker Summary of Flags

    -mv6700 --abi=coffabi -O3 --symdebug:skeletal --optimize_with_debug=on --define=c6713 --define=CCS5 --quiet --display_error_number --gen_func_subsections=on --mem_model:data=far --use_const_for_alias_analysis --single_inline --std_lib_func_defined -k --output_all_syms -z --stack_size=0x4000 -m"7450010.map" --heap_size=0x6000 -i"C:/ccs5/c67xmathlib_2_01_00_00/lib" -i"C:/ccs5/ccsv5/tools/compiler/c6000_7.4.6/lib" -i"C:/ccs5/bios_5_42_01_09/packages/ti/rtdx/lib/c6000" -i"C:/ccs5/bios_5_42_01_09/packages/ti/bios/lib" --reread_libs --verbose_diagnostics --warn_sections --display_error_number --issue_remarks --xml_link_info="7450010_linkInfo.xml" --absolute_exe --rom_model --trampolines=on

     

    TConf Summary of Flags

    Dconfig.importPath="C:/ccs5/bios_5_42_01_09/packages;C:/1000NX/Application/7450010/Source/DSP_CCS5;" -Dconfig.compilerOpts="-ml" -Dconfig.compilerOpts="--memory_model=huge" -Dconfig.compilerOpts="-mf" -Dver=Release

     

    Do you see anything special in the above settings?

    I have tried to migrate from CCS3.3 to CCS5.5 - so far, DSP/BIOS has worked well with the newer IDE, newer CGT. I have been able to have a very high level interrupt (at roughly 50 usec rate) that will be a higher priority than 3 other external interrupts.

    I have also been able to create several periodic functions that run at 10 msec, 100 msec, 500 msec, and 1 second rates with the priority being the 10 msec periodic.

    Several Software Interrupts have also been created that run at a lower priority than the periodic functions - mostly UART traffic.

    Also, the DSP/BIOS-defined stack has taken precedence over the Linker-defined stack.

    So, I was a bit baffled when I saw that the DSP/BIOS-defined heap was being bypassed in favor of .sysmem - and I am still baffled. However, it looks like the Linker-defined heap works - if you know what I need to change in the settings to make sure that I am doing the right thing and will not get bit by a future change in CGT, DSP/BIOS or CCS, let me know!