CCS/TMS320F28335: Minimum allowable heap size in compiler 18.12 for C28x device

I am unable to reproduce this result.

Please rebuild the entire project.  Right click on the name of the project and select Rebuild Project.  In the Console (not Problems) view, save all the build messages and diagnostics to a text file.  Use the Copy Build Log icon.  When you name the file, please use the extension .txt.  Attach that text file to your next post.

Thanks and regards,

-George

Thanks for your response, George. Since posting the original question, I have moved on and the question has changed. I did discover that the compiler prefers "-heap 0" to "-heap=0", and that seems to give the desired result of allocating zero heap space.

I am now getting only one fault from the link, which is UNDEFED __SYSMEM_SIZE. When I compare map files from the 6.2.0 compiler vs. v18.12.4.LTS, all the major memory categories consumed less RAM under the new compiler than the older compiler. It is not clear to me where the resources of the target DSP are being exceeded. I have reviewed several existing forum threads related to UNDEFED __SYSMEM_SIZE, but those circumstances don't seem to directly apply, e.g. linking printf, which we do not do.

Unfortunately, this is a secure project, and I cannot share map files with you for fear of the information reaching unauthorized eyes. In case it will help, here are some expurgated snippets that show the link results.

Link results in the Console panel:

Building target: "XXXXXXXX.out"
Invoking: C2000 Linker
"C:/ti/ccs930/ccs/tools/compiler/ti-cgt-c2000_18.12.4.LTS/bin/cl2000" -v28 -ml -mt --float_support=fpu32 -O1 --opt_for_speed=2 --define=... --define=__EVALUATE_STACK_USAGE__=0 --diag_suppress=10063 --diag_suppress=16002 --diag_warning=225 --display_error_number --auto_inline=0 --asm_listing --src_interlist --gen_opt_info=2 -z -m"XXXXXXXX.map" --stack_size=0x300 --warn_sections -i"C:/..." --reread_libs --display_error_number --xml_link_info="XXXXXXXX_linkInfo.xml" --entry_point=CsciCodeStart_Asm --rom_model -o "./XXXXXXXX.out" ... "./Xxxxxxxx.obj"

"C:/.../rts2800_fpu32.lib" "C:/.../rts2800_fpu32_fast_supplement.lib" -lrts2800_fpu32.lib 
<Linking>

undefined first referenced 
symbol in file 
--------- ---------------- 
__SYSMEM_SIZE C:/.../rts2800_fpu32.lib<memory.obj>

error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "XXXXXXXX.out" not built

>> Compilation failure
makefile:210: recipe for target 'XXXXXXXX.out' failed
gmake: *** [XXXXXXXX.out] Error 1
gmake: Target 'all' not remade because of errors.

**** Build Finished ****

Snippets from the map file produced by the above link process:

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
PAGE 0:
  PROG_RAM_L0           00008000   00000600  000004f6  0000010a  RWIX
  PROG_RAM              00008600   00005a00  00005702  000002fe  RWIX
  PDIF_RAM              0000fc00   00000300  000002b2  0000004e  RWIX
  FLASH_H_BU1           00300000   00008000  00000000  00008000  RWIX
  FLASH_DEFG            00308000   00020000  00000000  00020000  RWIX
  FLASH_C_BU2           00328000   00008000  00000000  00008000  RWIX
  FLASH_B               00330000   00008000  00000000  00008000  RWIX
  FLASH_A_PRIMARY       00338000   00007f00  00000000  00007f00  RWIX
  FLASH_A_LOADER        0033ff00   000000f1  00000046  000000ab  RWIX
  FLASH_A_CRCS          0033fff1   00000005  00000000  00000005  RWIX
  START_PROGRAM         0033fff6   00000002  00000002  00000000  RWIX
  PASSWORDS             0033fff8   00000008  00000008  00000000  RWIX
  ADC_CAL               00380080   00000009  00000000  00000009  RWIX
  OTP                   00380400   00000400  00000000  00000400  RWIX
  IQTABLES              003fe000   00000b50  00000000  00000b50  RWIX
  IQTABLES2             003feb50   0000008c  00000000  0000008c  RWIX
  FPUTABLES             003febdc   000006a0  000006a0  00000000  RWIX
  BOOTROM               003ff27c   00000d44  00000000  00000d44  RWIX
  RESET                 003fffc0   00000002  00000000  00000002  RWIX

PAGE 1:
  M0M1SYSTM             00000000   00000140  00000115  0000002b  RWIX
  M0M1SARAM             00000140   000006c0  00000680  00000040  RWIX
  DATA_RAM              0000e000   00001c00  00001425  000007db  RWIX
  EXTERNALSRAM          00200000   00040000  00000000  00040000  RWIX

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.zerowaits
*          0    00008000    000004f6    
                  00008000    00000043     rts2800_fpu32_fast_supplement.lib : sincos_f32.obj (.text)
                  00008043    00000019                                       : div_f32.obj (.text)
                  0000805c    00000200     rts2800_fpu32.lib : vec_newdel.obj (.text)
                  0000825c    000001d3                       : memory.obj (.text)
                  0000842f    00000046                       : boot.obj (.text)
                  00008475    00000020                       : new_.obj (.text)
                  00008495    00000019                       : args_main.obj (.text)
                  000084ae    00000019                       : exit.obj (.text)
                  000084c7    0000000c                       : memset.obj (.text)
                  000084d3    00000009                       : _lock.obj (.text)
                  000084dc    00000005                       : delete.obj (.text)
                  000084e1    00000004                       : memzero.obj (.text)
                  000084e5    00000004                       : pure_virt.obj (.text)
                  000084e9    00000003                       : array_del.obj (.text)
                  000084ec    00000003                       : array_new.obj (.text)
                  000084ef    00000003                       : error.obj (.text)
                  000084f2    00000003                       : memcpy.obj (.text)
                  000084f5    00000001                       : newhandler.obj (.text)

...

.stack     1    00000000    00000100     UNINITIALIZED
                  00000000    00000100     --HOLE--

.sysmem    1    00000114    00000001     UNINITIALIZED
                  00000114    00000001     rts2800_fpu32.lib : memory.obj (.sysmem)

.fpusysmem
*          1    00000100    00000014     UNINITIALIZED
                  00000100    00000008     rts2800_fpu32.lib : memory.obj (.ebss)
                  00000108    00000004                       : _lock.obj (.ebss)
                  0000010c    00000004                       : exit.obj (.ebss)
                  00000110    00000002                       : vars.obj (.ebss)
                  00000112    00000002                       : vec_newdel.obj (.ebss)

.osstacks
*          1    00000140    00000680     UNINITIALIZED
                  00000140    00000480     bit.obj (.osstacks)
                  000005c0    00000200     watchdog.obj (.osstacks)

...

n/a   UNDEFED   __SYSMEM_SIZE    

If there is an additional section of the map that you'd like to see, please let me know.

Thanks!

You say you use ...

Thomas Cox said:

the compiler prefers "-heap 0" to "-heap=0", and that seems to give the desired result of allocating zero heap space.

However, when I look at your linker options ...

Thomas Cox said:

-z -m"XXXXXXXX.map" --stack_size=0x300 --warn_sections -i"C:/..." --reread_libs --display_error_number --xml_link_info="XXXXXXXX_linkInfo.xml" --entry_point=CsciCodeStart_Asm --rom_model -o "./XXXXXXXX.out" ... "./Xxxxxxxx.obj"

I don't see -heap.  Using this option causes the linker to define the symbol __SYSMEM_SIZE.  For more details, please search the C28x assembly tools manual for the sub-chapter titled Define Heap Size.  Note that all of these options are equivalent: --heap_size,-heap,--heap

Please let me know if this suggestion resolves the problem.

Thanks and regards,

-George

I checked project properties for both the CCSv7 and CCSv8 projects. Under C2000 Linker / Basic options, heap size had not been set, but it is set in the link cmd file for both CCSv7 and CCSv9. The build from compiler v6.2.0 under CCSv7 succeeds in defining __SYSMEM_SIZE. Compiler v18.12.4.LTS under CCSv9 fails. For the CCv9 project, I set heap size to zero in Project properties / C2000 linker / Basic Options. The build still fails to define __SYSMEM_SIZE.

In project properties under CCS General properties for both CCSv7 and CCSv9 projects, --abi is set to Legacy COFF, so the memory segment conventions should be following COFF. Interestingly, both compilers produce .econst and .ebss sections, and both produce .sysmem sections. You can see the .sysmem section produced by v18.12.4.LTS in my map file extract above. Under COFF the Assembly Tools manual says that that memory section should be named .esysmem. Could that be what is failing under v18.12.LTS? It appears that v6.2.0 produces .sysmem, but is happy with that, while v18.12.4.LTS is producing .sysmem, which fails at link time. Could v18.12.4.LTS be expecting to define .esysmem?

How would it be possible for the linker to follow COFF conventions for .bss/.ebss and .const/.econst, but use the EABI convention for .sysmem/.esysmem?

Unfortunately, the only way I see forward is for me to reproduce the problem.  I understand your reluctance to submit the project.  Are you able to send the project just to me?  If so, zip up the project by following the directions in the article Sharing projects.  Hover your mouse over my screen name or avatar. A box will pop up. Click on Send a private message. In the message compose interface which comes up, use the paper clip icon to attach the zip file.

If that is not practical, perhaps you could reproduce the problem in a smaller test project that you are able to send me?

Thanks and regards,

-George

I searched for a simpler existing project for our TMS320F28335 which I could send to you. I found a relatively simple RS485 and CAN communications project that has no proprietary code. When I build it under CCS9 and compiler v18.12.4.LTS, it produces .esysmem, not .sysmem, and it builds cleanly. 

It appears that the problem with the recently ported larger project not defining __SYSMEM_SIZE is related to the fact that it creates .sysmem instead of .esysmem, although both the compiler and linker options specify --abi=coffabi.

Are there any known compiler or link options that can produce .sysmem in spite of Legacy COFF being set in project General properties? 

Are there any known compiler bugs that could have that effect?

Thomas Cox said:

Are there any known compiler or link options that can produce .sysmem in spite of Legacy COFF being set in project General properties? 

No.  In a normal map file for a COFF build with version 18.12.4.LTS, there should be a lines in the linker map file similar to these ...

.esysmem   1    00000000    00000400     UNINITIALIZED
                  00000000    00000004     rts2800_ml.lib : memory.c.obj (.esysmem)
                  00000004    000003fc     --HOLE--

In your build which fails, you should see similar lines in the map file, for an output section named .sysmem, .esysmem, or maybe both.  Please copy-n-paste those lines into your next post.

Thomas Cox said:

Are there any known compiler bugs that could have that effect?

No.

Thanks and regards,

-George

George - 

The map file produced by CcSv7 and compiler version 6.2.0 produces the following in its map file, and it builds without error:

I think I know the cause of the problem.  I'm sorry I didn't notice it earlier.  In your second post, in the linker invocation, is the following ...

Thomas Cox said:

"C:/.../rts2800_fpu32.lib" "C:/.../rts2800_fpu32_fast_supplement.lib" -lrts2800_fpu32.lib

Link against the compiler RTS library only one time.  And be certain the linker, and the RTS library, come from the same version of the compiler.  In this case, I suspect that first mention of the RTS library is from an earlier version of the compiler.  Please remove it.

The best practice is to make the last argument in the linker invocation ...

-l libc.a

This tells the linker to automatically determine which RTS library is the best one.  Putting it last means any functions meant to replace standard RTS functions from rts2800_fpu32_fast_supplement.lib will be chosen over those in the compiler RTS library.

Please let me know if this change resolves the problem.

Thanks and regards,

-George

George:

Thanks for noticing the duplicate entry in the linked list of rts2800_fpu32.lib

I removed the copy of rts2800_fpu32.lib that was being carried along with the project. In project Properties/CCS General, rts2800_fpu32.lib is specified in the drop-down under Runtime support library, which I think lets the linker use the copy from the compiler. It had also been specified in C2000 Linker/FileSearchPath as an explicitly included library, which seemed redundant. I removed that and, per your suggestion, added libc.a in its place.

Here are the results in the Console from the link portion of the build:

Building target: "SEU.out"
Invoking: C2000 Linker
"C:/ti/ccs930/ccs/tools/compiler/ti-cgt-c2000_18.12.4.LTS/bin/cl2000" -v28 -ml -mt --float_support=fpu32 -O1 --opt_for_speed=2 --define=__ACE__ --define=__nNO_ACTUATORS__ --define=__GLOVES__=OFF --define=__nSAUSAGE__ --define=__nTOP_ONLY__ --define=__SEU_MC__ --define=__USE_CAN_MSG_ID_FILTERING__ --define=__REPORT_ACTUATOR_POSITION__ --define=__ENABLE_RDC_CLK_DIVIDER__ --define=__USE_SCI_POLLING__ --define=__USE_APP_SPECIFIC_RECEPTION_HANDLER__ --define=__TWO_MOTORS__ --define=__REPORT_ACTUATOR_VELOCITY__ --define=__nDEBUG__ --define=__OUTPUT_INTERPOLATED_POSITION__=1 --define=__SIL_HW__=0 --define=__EVALUATE_STACK_USAGE__=0 --diag_suppress=10063 --diag_suppress=16002 --diag_warning=225 --display_error_number --abi=coffabi --auto_inline=0 --asm_listing --src_interlist --gen_opt_info=2 -z -m"SEU.map" --heap_size=0 --stack_size=0x300 --warn_sections -i"C:/_svn/CodeBase/branches/NGJ_MC_01_10_CCS9/DSP/DSP" --reread_libs --display_error_number --xml_link_info="SEU_linkInfo.xml" --entry_point=CsciCodeStart_Asm --rom_model -o "XXXXXXXX.out"
...
"C:/_svn/CodeBase/branches/NGJ_MC_01_10_CCS9/DSP/DSP/rts2800_fpu32_fast_supplement.lib" -llibc.a
<Linking>
error #10008-D: cannot find file "libc.a"

There was no noticeable change in the map file produced. The build still defines .sysmem instead of .esysmem, and the link error undefined symbol __SYSMEM_SIZE is still occurring.

Focus on fixing ...

Thomas Cox said:

error #10008-D: cannot find file "libc.a"

Your linker options do not show the setting of the option --search_path.  This option indicates the location of the compiler RTS libraries.  The screen shot below shows a typical setting.

Thanks and regards,

-George

Did you fix this issue?

Thomas Cox said:

error #10008-D: cannot find file "libc.a"

Does the build work now?

Thanks and regards,

-George

George:

Thanks for the tip. I added the search paths as shown in your screen shot. The build now finds libc.a. But the link failure undefined symbol __SYSMEM_SIZE still occurs.

Thomas Cox

I'll contact you privately.  

Thanks and regards,

-George

George -

This afternoon I was able to move things along a little farther. I examined project properties and found that it was still loading library rts2800_fpu32.lib from the project dev. path. I changed it to use rts2800_fpu32.lib from C:/ti/ccs930/tools/compiler/ti-cgt-c2000_18.12.4.LTS/lib. The error now states "fatal error #16000: object files have incompatible formats". I get the same result if I try rts2800_fpu32_eabi.lib. It produces the same error message. 

Thomas Cox

Thomas Cox said:

I examined project properties and found that it was still loading library rts2800_fpu32.lib from the project dev. path.

That should not happen.  The details of how that happened are probably important.  This method for obtaining the library should be undone, and changes made so the library always comes from the compiler used to build the project.  I suggest we continue to work the details through private messaging.

Thanks and regards,

-George