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

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:

$ ~/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

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:

**** 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"
Invoking: Arm Hex Utility
"/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/bin/armhex" --diag_wrap=off --binary -o "TM4C1294NCPDT_fixed_checksum.armhex_bin"  "TM4C1294NCPDT_fixed_checksum.out" 
Translating to Binary format...
   "TM4C1294NCPDT_fixed_checksum.out" .intvecs ==> .intvecs
   "TM4C1294NCPDT_fixed_checksum.out" .text ==> .text
   "TM4C1294NCPDT_fixed_checksum.out" .TI.bound:CHECKSUM ==> .TI.bound:CHECKSUM
Finished building: "TM4C1294NCPDT_fixed_checksum.out"
 
Create binary file
/home/mr_halfword/ti/ccs1020/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/bin/armobjcopy -O binary TM4C1294NCPDT_fixed_checksum.out TM4C1294NCPDT_fixed_checksum.objcopy_bin
 

**** Build Finished ****

The size of the generated binary files are:

$ 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

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

  • 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.

    MEMORY
    {
        FLASH (RX) : origin = 0x00000000, length = 0x00100000, fill = 0xffffffff
        SRAM (RWX) : origin = 0x20000000, length = 0x00040000
    }