• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 603 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.

Original question:

TM4C1294NCPDT: Placing Variables in Specific Memory Location - TM4C1294NCPDT with CCS

armhex from v20.2.4 can create incorrect binary output, without filling holes, if just the --binary option is used

Chester Gillon
Guru 92251 points
Other Parts Discussed in Thread: TM4C1294NCPDT

The attached example for a TM4C1294NCPDT creates initialised sections which contain holes, due use of a section placed at a specific address:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ ~/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/bin/armofd --xml TM4C1294NCPDT_fixed_checksum.out | ~/ti/ti-processor-sdk-rtos-am335x-evm-05.01.00.11/cg_xml/bin/sectti
Reading from stdin ...
************************************************************
REPORT FOR FILE: TM4C1294NCPDT_fixed_checksum.out
************************************************************
Name : Size (dec) Size (hex) Type Load Addr Run Addr
-------------------- : ---------- ---------- ---- ---------- ----------
.intvecs : 520 0x00000208 DATA 0x00000000 0x00000000
.text : 68 0x00000044 CODE 0x00000208 0x00000208
.stack : 512 0x00000200 UDATA 0x20000000 0x20000000
.TI.bound:CHECKSUM : 2 0x00000002 DATA 0x000f0000 0x000f0000
------------------------------------------------------------
Totals by section type
------------------------------------------------------------
Uninitialized Data : 512 0x00000200
Initialized Data : 522 0x0000020a
Code : 68 0x00000044
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Due to the holes the expected binary file size is 0xF0002 = 983042.

The attached example has two ways of generating a binary output file:

  1. A post-build rule using armobjcopy from the TI ARM v20.2.4 compiler
  2. armhex from the TI ARM v20.2.4 compiler, configured using the CCS project properties under CCS Build -> Arm Hex Utility. The only options set were the output format (set to --binary) and the output filename (--outfile).

The complete output from the CCS build console, including the two methods to create binary output files:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
**** Build of configuration Debug for project TM4C1294NCPDT_fixed_checksum ****
/home/mr_halfword/ti/ccs1020/ccs/utils/bin/gmake -k -j 12 all -O
Building file: "../main.c"
Invoking: Arm Compiler
"/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --include_path="/home/mr_halfword/workspace_v10/TM4C1294NCPDT_fixed_checksum" --include_path="/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/include" --define=ccs="ccs" --define=PART_TM4C1294NCPDT -g --gcc --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --asm_listing --preproc_with_compile --preproc_dependency="main.d_raw" "../main.c"
Finished building: "../main.c"
Building file: "../tm4c1294ncpdt_startup_ccs.c"
Invoking: Arm Compiler
"/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --include_path="/home/mr_halfword/workspace_v10/TM4C1294NCPDT_fixed_checksum" --include_path="/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/include" --define=ccs="ccs" --define=PART_TM4C1294NCPDT -g --gcc --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --asm_listing --preproc_with_compile --preproc_dependency="tm4c1294ncpdt_startup_ccs.d_raw" "../tm4c1294ncpdt_startup_ccs.c"
Finished building: "../tm4c1294ncpdt_startup_ccs.c"
Building target: "TM4C1294NCPDT_fixed_checksum.out"
Invoking: Arm Linker
"/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --define=ccs="ccs" --define=PART_TM4C1294NCPDT -g --gcc --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --asm_listing -z -m"TM4C1294NCPDT_fixed_checksum.map" --heap_size=0 --stack_size=512 -i"/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/lib" -i"/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/include" --reread_libs --diag_wrap=off --display_error_number --warn_sections --xml_link_info="TM4C1294NCPDT_fixed_checksum_linkInfo.xml" --rom_model -o "TM4C1294NCPDT_fixed_checksum.out" "./main.obj" "./tm4c1294ncpdt_startup_ccs.obj" "../tm4c1294ncpdt.cmd" -llibc.a
<Linking>
Finished building target: "TM4C1294NCPDT_fixed_checksum.out"
Building files: "TM4C1294NCPDT_fixed_checksum.out"
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The size of the generated binary files are:

Fullscreen
1
2
3
$ ls -l *bin*
-rw-rw-r-- 1 mr_halfword mr_halfword 590 Apr 2 10:15 TM4C1294NCPDT_fixed_checksum.armhex_bin
-rw-rw-r-- 1 mr_halfword mr_halfword 983042 Apr 2 10:15 TM4C1294NCPDT_fixed_checksum.objcopy_bin
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The binary file created by armobjcopy has the expected size.

However, the binary file created by armhex is just the total size of all the initialised sections. I.e. not a valid binary file since has excluded the holes between the initialised sections. Looking at the ARM Assembly Language Tools v20.2.0.LTS User's Guide using a combination of --binary and --image along with a ROMS directive would allow a valid binary file to be created in this case.

Is it a bug in armhex that just using the --binary option can cause the output file to not contain the holes between the initialised sections?

TM4C1294NCPDT_fixed_checksum.zip

  • 0
    TI__Guru 72500 points

    Hi Chester,

    You are correct in that armhex does not automatically fill the holes in the memory space. The simple solution is to fill the space with the linker by adding a "fill" to the MEMORY specification. This will also make the .out file large. The more complex solution is as you cited, using -mage withe a ROMS directive.

    Fullscreen
    1
    2
    3
    4
    5
    MEMORY
    {
    FLASH (RX) : origin = 0x00000000, length = 0x00100000, fill = 0xffffffff
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX