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.

tiobj2bin file size

Other Parts Discussed in Thread: LM3S3634, LM3S3748, SYSBIOS


I'm not sure if this is the right forum, but I am developing with an LM3S3634 using Code Composer Studio 4.2 and I have set up a post build step to create a .bin file output.  Here is the command:

"${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin.bat" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd470.exe" "${CG_TOOL_ROOT}/bin/hex470.exe" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin.exe"

It seems to be working correctly, except that the .bin file is 524MB in size.  The first 700K is the correct data, and the rest is all 0s.  Does anyone know what I might do to get rid of all the 0s?  Thank you.


  • Peter,

    The command seems ok - at least the sequence matches what it is shown in the <tiobj2bin.bat> file.

    The large size indicates you may be initializing a memory region with zeros - therefore the .HEX file would forcefully contain the value of each byte that must be written to the flash memory device.

    I would then inspect the linker command file (.CMD) for any memory fill directives - check sections 7.4.12 and of the TMS470 Assembly Language Tools User's Guide (link here).

    If you are not using this, could you send your linker command file and the console output of the linker step? (no need to send all console output). 



  • Rafael,

    Thanks for the help.  I am not using the memory fill directive, but I am using the MEMORY directive.  It seems correct to me.  My linker command file references another file and I have placed them both below.  The linker output is also below.  Thanks,






    * Do not modify this file; it is automatically generated from the template

    * linkcmd.xdt in the ti.targets.elf package and will be overwritten.



    * put '"'s around paths because, without this, the linker

    * considers '-' as minus operator, not a file name character.
















    /* C6x Elf symbols */

    --symbol_map __TI_STACK_SIZE=__STACK_SIZE

    --symbol_map __TI_STACK_BASE=__stack

    --symbol_map _stack=__stack




    --args 0x200

    -heap 0x1000

    -stack 0x1000



    IRAM (RWX) : org = 0x20000000, len = 0x8000

    FRAM (RWX) : org = 0x0, len = 0x20000



    * Linker command file contributions from all loaded packages:


    /* Content from (null): */

    /* Content from xdc (null): */

    /* Content from xdc.corevers (null): */

    /* Content from xdc.shelf (null): */

    /* Content from (null): */

    /* Content from (null): */

    /* Content from (null): */

    /* Content from (null): */

    /* Content from xdc.rov (null): */

    /* Content from ti.catalog.arm.cortexm3 (null): */

    /* Content from ti.catalog.peripherals.hdvicp2 (null): */

    /* Content from ti.catalog (null): */

    /* Content from ti.catalog.arm.peripherals.timers (null): */

    /* Content from xdc.platform (null): */

    /* Content from xdc.cfg (null): */

    /* Content from ti.platforms.generic (null): */

    /* Content from LM3S3634 (null): */

    /* Content from ti.targets.arm.rtsarm (null): */

    /* Content from (null): */

    /* Content from ti.sysbios.interfaces (null): */

    /* Content from (ti/sysbios/family/arm/m3/linkcmd.xdt): */

    --retain "*(.resetVecs)"

    /* Content from ti.sysbios (null): */

    /* Content from ti.sysbios.xdcruntime (null): */

    /* Content from xdc.runtime.knl (null): */

    /* Content from ti.sysbios.gates (null): */

    /* Content from ti.sysbios.knl (null): */

    /* Content from (null): */

    /* Content from (ti/sysbios/family/arm/linkcmd.xdt): */

    --retain "*(.vecs)"

    /* Content from ti.sysbios.hal (null): */

    /* Content from xdc.runtime (null): */

    /* Content from configPkg (null): */



    * symbolic aliases for static instance objects


    xdc_runtime_Startup__EXECFXN__C = 1;

    xdc_runtime_Startup__RESETFXN__C = 1;

    TSK_idle = ti_sysbios_knl_Task_Object__table__V + 68;



    .cio: load >> IRAM

    GROUP: load > IRAM






    xdc.meta: load >> FRAM, type = COPY

    .text: load >> FRAM

    .far: load >> IRAM

    .taskStackSection: load >> IRAM

    .sysmem: load > IRAM

    .pinit: load > FRAM

    .cinit: load > FRAM

    .resetVecs: load > 0x0

    .args: load > IRAM align = 0x4, fill = 0 {_argsize = 0x200; }

    .bootVecs: type = NOLOAD

    .switch: load >> IRAM

    .data: load >> IRAM

    .stack: load > IRAM

    .vecs: load > 0x20000000

    .fardata: load >> IRAM

    .const: load >> FRAM




    'Invoking: Linker'

    'Flags: -mv7M3 -g -O2 --opt_for_speed=0 --gcc --define=ccs --define=PART_LM3S3748 --define=TARGET_IS_DUSTDEVIL_RA0 --diag_warning=225 -me --gen_func_subsections --abi=eabi --code_state=16 --ual -z -m"" --stack_size=256 --heap_size=0 --verbose_diagnostics --warn_sections -i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/tms470/lib" -i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/tms470/include" --reread_libs --rom_model'

    "C:/Program Files/Texas Instruments/ccsv4/tools/compiler/tms470/bin/cl470" -@"ccsLinker.opt" -o "LM3S3634_Demo_Project.out"


    'Finished building target: LM3S3634_Demo_Project.out'

    ' '

    Build complete for project LM3S3748_Demo_Project




  • Peter,

    I ran tiobj2bin in a BIOS6 project here and it also created a massive .bin file. However, further investigation revealed that the .vecs memory section is the culprit, as it is initialized memory but stored in RAM (starting at address 0x20000000). All the other initialized memory sections are located in flash (starting at 0x0).

    The reason of the file size is because the .bin file is an extremely simple binary format. There is no mechanism by which you can compactly represent holes in memory and filling them with zero is the only option.

    Therefore, to get a small .bin file all of the initialized sections must be close to each other in memory. Any gaps between them are filled with zeros.

    I am not sure why exactly the .vecs is being placed in RAM, but it may be a question for the BIOS experts to answer.

    Best regards,



  • Thank you for helping me narrow this down.  I have created a post in the BIOS forum to try and get this resolved (see link below).


  • Peter,

    Thank you for reporting this. I am working with some people from the BIOS team. To avoid duplicate efforts, I will reference this thread at the other thread as well.