• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 1997 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.

Compiler: TI ARM C/C++ Compiler v5.1.6

Jagadish Palle
Prodigy 130 points

Tool/software: TI C/C++ Compiler

Problem:

We are getting the following error message when we removed the library per our requirement (we should not use the libraries). Is there any linker flag will clear this flag. I can define the function in my code and do nothing but I am looking for linker option similar to --cinit_compression=off  which turn off __TI_decompress_rle24.

undefined                   first referenced
symbol                                  in file
---------                              ----------------
__TI_decompress_none

Compiler Information:

TI ARM C/C++ Compiler v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W

TI ARM C/C++ Parser v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM EABI C/C++ Parser v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM C/C++ File Merge v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM C/C++ Optimizer v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM C/C++ Codegen v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Assembler v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Embed Utility v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM C Source Interlister v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Linker v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Absolute Lister v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Strip Utility v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM XREF Utility v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM C++ Demangler v5.1.6
Tools Copyright (c) 1996-2014 Texas Instruments Incorporated
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Hex Converter v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Name Utility v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Object File Display v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W
TI ARM Archiver v5.1.6
Build Number 1OE9R-KDADEMDK-RTARQ-WAR-ZAZE_V_R_W

Command:

$(ARMCL) $(LFLAGS) --cinit_compression=off --output_file=$(OUT_FILE) $(S_OBJ_FILES) $(OBJ_FILES) $(ASM_OBJ_FILES) $(CMD_FILE)

where $(LFLAGS) := -mv7R4 --code_state=32 --float_support=VFPv3D16 --abi=eabi -Ooff --diag_warning=225 --display_error_number --enum_type=packed --preproc_with_compile --preproc_dependency --gen_aux_user_info

Error Message:

<Linking>
warning #10208-D: automatic RTS selection: attempt to automatically link in
index library "libc.a" failed; file not found
"OPS.cmd", line 112: warning #10068-D: no matching section
warning #10062-D: entry-point symbol "_c_int00" undefined

undefined first referenced
symbol in file
--------- ----------------
__TI_decompress_none

error #10234-D: unresolved symbols remain
warning #10202-D: no suitable entry-point found; setting to 0
error #10010: errors encountered during linking; "./Release/exe/OPS.out" not
built

  • 0
    TI__Guru**** 232700 points

    To understand my suggestion, I need to give a bit of background.  This entire explanation presumes you use the newer EABI, and not the older TI_ARM9_ABI.  

    The .data section contains global and static variables that are explicitly initialized.  While these variables are initialized before main starts, they are not constant throughout execution.  They can change value.  How does the initial value get set?

    That depends on whether you use --rom_model or --ram_model.  Your options do not explicitly show either --rom_model or --ram_model.  But since your code references the symbol __TI_decompress_none, I can tell you use --rom_model.  

    When --rom_model is used, here is how initialization works.  The .data input section, coming out of each object file, is an initialized section.  Each symbol corresponds to a bit of memory with a value in it.  The linker combines all the .data input sections into an output section also named .data.  But it is changed from an initialized section to an uninitialized section.  The initialization values are placed in another initialized output section named .cinit.  To save memory, the .cinit section is compressed.  You disable this compression with option --cinit_compression=off.  But the .cinit section is still present.  At runtime, the startup code does two things.  It decompresses .cinit (though not in your case) and copies the initialization values from .cinit to .data.  In your specific case, the routine __TI_decompress_none is used by the startup code.

    When --ram_model is used, here is how initialization works.  The .data section remains an initialized section.  The system must be able to load this .data section into memory that can written when the system runs.  In particular, you cannot simply burn .data into flash.

    So, if is it practical in your situation, one way to avoid the entire compression sequence is to change from --rom_model to --ram_model.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 130 points

    Thanks George. Yes, we are using --rom_model.

    changed  --rom_model to --rom_model per your suggestion. The software successfully compiled and linked. However the size of the binary file is 131MB whereas the same binary file size is 148KB when I use --rom_model. At the end, it added all zeros. In both cases, the .out file size is same (843KB). We are using the following bat/command to generate binary (.bin) file from .out file. 

    C:/TI/ccsv6/utils/tiobj2bin/tiobj2bin.bat ./Release/exe/OPS.out ./Release/exe/OPS.bin C:/TI/ccsv6/tools/compiler/arm_5.1.6/bin/armofd.exe C:/TI/ccsv6/tools/compiler/arm_5.1.6/bin/armhex.exe C:/TI/ccsv6/utils/tiobj2bin/mkhex4bin.exe

    These files are generated with --ram_model option:

    These files are generated with --rom_model option:

  • 0 in reply to Jagadish Palle
    TI__Guru* 84225 points
    In EABI, the linker creates tables to boot-time zero out some sections. It depends on library functions to perform the zeroing out. By forbidding the library, you must forgo this load-time footprint optimization, and thus the memory must be zero-initialized before boot time. That is to say, the zeros will show up in the "binary" file.
  • 0 in reply to Jagadish Palle
    TI__Guru**** 232700 points

    Jagadish Palle said:
    the size of the binary file is 131MB whereas the same binary file size is 148KB when I use --rom_model.

    The size of this binary file is given by

    highest initialized address - lowest initialized address

    Because you use --ram_model, the .data section changed from an uninitialized section to an initialized section.  It is probably at an address very far away from the other initialized sections.  Is it practical to change how sections are allocated to memory such that all of the initialized sections, including .data, are close together?

    Thanks and regards,

    -George

  • 0 in reply to Jagadish Palle
    Guru 92251 points

    Jagadish Palle said:
    However the size of the binary file is 131MB whereas the same binary file size is 148KB when I use --rom_model.

    What device are you using?

    Based upon your command line I am guessing a Hercules device. Hercules devices can have the start of flash and RAM 128MB apart which could explain the size of the binary file when --ram_model is used.

    For flash based devices use of the --ram_model isn't suitable for boot from flash, because you need start-up code in flash to copy the initialized data from flash to RAM at start up.

    I think you need to either:

    a) Keep --rom_model but add start-up code to copy the data section from flash to RAM.

    b) Change the code to remove initialized variables, to eliminate the data section, and then add code to initialize the variables as required.