• Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 2900 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Trouble generating raw binary from .out file using CCS GCC

Sai Reddy
Mastermind 22580 points
Other Parts Discussed in Thread: TM4C129ENCPDT

I am trying to generate a .bin file (in raw binary format) from a .out file. The .out file is generated using Linaro GCC tool located in "<CCSv6_Install_Root>/tools/compiler/gcc-arm-none-eabi-4_8-2014q3".

To generate the .bin file, I used two different commands, as shown below.

"<CCSv6_Install_Root>/tools/compiler/gcc-arm-none-eabi-4_8-2014q3bin/arm-none-eabi-objcopy.exe" -O binary inputfile.out outputfile.bin
"<CCSv6_Install_Root>/utils/tiobj2bin/tiobj2bin" "inputfile.out" "outputfile.bin" "<CCSv6_Install_Root>/tools/compiler/gcc-arm-none-eabi-4_8-2014q3/bin/armofd" "<CCSv6_Install_Root>/tools/compiler/gcc-arm-none-eabi-4_8-2014q3/bin/armhex" "<CCSv6_Install_Root>}/utils/tiobj2bin/mkhex4bin"

With both the above commands, I get identical result. A .bin file that is more than 500MB is generated. This is clearly wrong, as the .out file is about 3MB. I have attached the .out file for reference.

The target device is TM4C129ENCPDT, which is a ARM Cortex-M4 based MCU. I have used both command line and CCS to build the project with identical result.

Please advice!

Sai

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/secure_5F00_iot.out

  • TI__Guru**** 250010 points

    I can explain why the bin file is so large.  I cannot tell you how to fix it.

    A binary file created by objcopy (or tiobj2bin, which is modeled on objcopy) contains what belongs in memory when the system starts up.  So, it only contains contents from initialized sections.  Uninitialized sections are ignored. 

    Here is the important point: there is no way to represent holes in memory.  Any hole in memory is filled with 0.  And you have some very large holes.  I created this dump by using the sectti utility in the cg_xml package ...

    $ armofd -x secure_iot.out | sectti
Reading from stdin ...

************************************************************
REPORT FOR FILE: secure_iot.out
************************************************************
                Name : Size (dec)  Size (hex)  Type   Load Addr   Run Addr
-------------------- : ----------  ----------  ----   ----------  ----------
            .intvecs :         60  0x0000003c  DATA   0x00000000  0x00000000
             .vtable :        864  0x00000360  DATA   0x20000000  0x20000000
               .text :     215156  0x00034874  CODE   0x00000040  0x00000040
            .c_int00 :         68  0x00000044  CODE   0x000348b4  0x000348b4
             .rodata :      38656  0x00009700  DATA   0x00034900  0x00034900
               .data :       3620  0x00000e24  DATA   0x0003e000  0x20000360
  .bss:NDK_PACKETMEM :      16128  0x00003f00  DATA   0x0003ee24  0x20001200
   .bss:NDK_MMBUFFER :      18600  0x000048a8  DATA   0x00042d24  0x20005100
                .bss :      87188  0x00015494  UDATA  0x200099c0  0x200099c0
              .stack :       2048  0x00000800  UDATA  0x2001ee58  0x2001ee58

------------------------------------------------------------
Totals by section type
------------------------------------------------------------
  Uninitialized Data :      89236  0x00015c94
    Initialized Data :      77928  0x00013068
                Code :     215224  0x000348b8

    Ignore the sections with type UDATA.  Also ignore the Run Addr column.  The binary file uses the load address.  Note the large range of addresses used.  It starts at 0, and goes all the way to 0x20000360.  The big hole is between the end of .bss:NDK_MMBUFFER and the start of .vtable.

    So, that is why the bin file is so large.  I can't tell you how to change your application to avoid the large holes.

    Thanks and regards,

    -George

  • in reply to George Mock
    TI__Mastermind 22580 points
    Hmmm...
    0x20000000 is the start of RAM address. 0x00000000 is the start of ROM (or Flash). Hence that difference is bound to be there. I would assume there should be a way to indicate this difference.

    I am running the same (or similar) source code using CCS's ARM compiler/Linker, which creates a .out file. I am using the "tiobj2bin" tool to convert the .out file to .bin file and don't see the same problem. I guess i will try to do a similar dump (using sectti utility) for the CCS .out file and see if I can spot anything.

    Thanks for the information!

    Sai
  • in reply to Sai Reddy
    Guru 92251 points

    Stellaris Sai said:
    Hmmm...
    0x20000000 is the start of RAM address. 0x00000000 is the start of ROM (or Flash). Hence that difference is bound to be there. I would assume there should be a way to indicate this difference.

    Your project appears to be based upon TI-RTOS. Which version are you using?

    With TI-RTOS for TivaC 2.00.01.23 when I import the tcpEcho_TivaTM4C1294NCPDT example:

    a) For the example for the GNU compiler, using gcc-arm-none-eabi-4_7-2013q3, the .vtable section for the RAM interrupt vectors is an initialized section, which will create a large binary file.

    b) For the example for the TI compiler, using v5.16, the .vecs section for the RAM interrupt vectors is an uninitialized section, which should produce a sensible size binary file.

    This problem looks to be explained by the thread https://e2e.ti.com/support/embedded/tirtos/f/355/p/415839/1487669, which suggests the solution is to either:

    - Update the TI-RTOS, and thus underlying SYS/BIOS version.

    - Modify the GNU linker script.

    [I haven't tried this myself]