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/CC3220MODA: .data section showing up in *.bin file with '0' padding in between

Part Number: CC3220MODA
Other Parts Discussed in Thread: CC3220SF

Tool/software: TI C/C++ Compiler

I'm working with a customer who is creating a two binary project.  One binary is the main application and the other binary is compiled C-code from Matlab.

In the Matlab application has a known entry vector address and a jump table for successive function calls into the Matlab library code.  To the vector address they pass a jump table offset.  This operates similar to how a system call would.

All of this works just fine, however, they want to now generate a *.bin file for the Matlab portion to be used for firmware updates in the field.  The issue is that they have two initialized data variables (4-byte value from RTS, 1-byte value from their Matlab application), and these are being retained in the binary file generation with '0' values padded in between.  This results in a binary that is significantly larger than it should be taking up extra time and data storage in their firmware update procedure.

We cannot figure out why this is happening.  Here is the command line commands we are using (*.out/*.bin represents customer specific file names):

C:/ti7.3.0/ccsv7/utils/tiobj2bin/tiobj2bin *.out *.bin C:/ti7.3.0/ccsv7/tools/compiler/ti-cgt-arm_16.9.4.LTS/bin/armofd C:/ti7.3.0/ccsv7/tools/compiler/ti-cgt-arm_16.9.4.LTS/bin/armhex C:/ti7.3.0/ccsv7/utils/tiobj2bin/mkhex4bin

Here is an "objdump -h" of the starting *.out file:

Sections:

Idx Name          Size      VMA       LMA       File off  Algn

  0 .magicnum     00000004  010e6800  010e6800  00000034  2**2

                  CONTENTS, ALLOC, LOAD, READONLY, DATA

  1 .dgbhdr       00000000  00000000  00000000  00000000  2**0

                  READONLY

  2 .app_entry    00000086  010e6804  010e6804  00000038  2**1

                  CONTENTS, ALLOC, LOAD, READONLY, CODE

  3 .text         00006348  010e6c00  010e6c00  000000c0  2**1

                  CONTENTS, ALLOC, LOAD, READONLY, CODE

  4 .const        00000748  010ecf48  010ecf48  00006408  2**2

                  CONTENTS, ALLOC, LOAD, READONLY, DATA

  5 .cinit        00000000  00000000  00000000  00000000  2**0

                  READONLY

  6 .pinit        00000000  00000000  00000000  00000000  2**0

                  READONLY

  7 .data         00000005  2003f5d0  2003f5d0  00006b50  2**2

                  CONTENTS, ALLOC, LOAD, DATA

  8 .bss          000005d0  2003f000  2003f000  00006b50  2**3

                  ALLOC

  9 .sysmem       00000000  00000000  00000000  00000000  2**0

                  READONLY

10 .stack        00000000  00000000  00000000  00000000  2**0

                  READONLY

11 .TI.noinit    00000000  00000000  00000000  00000000  2**0

                  READONLY

12 .TI.persistent 00000000  00000000  00000000  00000000  2**0

                  READONLY

13 .debug_info   0001c5af  00000000  00000000  00006b55  2**0

                  CONTENTS, READONLY, DEBUGGING

14 .debug_line   000045a7  00000000  00000000  00023104  2**0

                  CONTENTS, READONLY, DEBUGGING

15 .debug_frame  00000c45  00000000  00000000  000276ab  2**0

                  CONTENTS, READONLY, DEBUGGING

16 .debug_abbrev 00002fe4  00000000  00000000  000282f0  2**0

                  CONTENTS, READONLY, DEBUGGING

17 .debug_str    000050bc  00000000  00000000  0002b2d4  2**0

                  CONTENTS, READONLY, DEBUGGING

18 .debug_aranges 000006d0  00000000  00000000  00030390  2**0

                  CONTENTS, READONLY, DEBUGGING

19 .debug_pubnames 000017d2  00000000  00000000  00030a60  2**0

                  CONTENTS, READONLY, DEBUGGING

20 .debug_pubtypes 00000e5d  00000000  00000000  00032232  2**0

                  CONTENTS, READONLY, DEBUGGING

21 .ARM.attributes 00000052  00000000  00000000  0003308f  2**0

                  CONTENTS, READONLY

22 .TI.section.flags 0000001c  00000000  00000000  000393a4  2**0

                  CONTENTS, READONLY

 

Here is the linker command file:

//*****************************************************************************
// cc3220FS.cmd
//
// CCS linker configuration file for CC3220SF production device, where
// it has 256kB of RAM (where bootloader uses 16kB of RAM) and 1024 KB of
// on-chip Flash memory.
//
// Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
//
//
//  Redistribution and use in source and binary forms, with or without
//  modification, are permitted provided that the following conditions
//  are met:
//
//    Redistributions of source code must retain the above copyright
//    notice, this list of conditions and the following disclaimer.
//
//    Redistributions in binary form must reproduce the above copyright
//    notice, this list of conditions and the following disclaimer in the
//    documentation and/or other materials provided with the
//    distribution.
//
//    Neither the name of Texas Instruments Incorporated nor the names of
//    its contributors may be used to endorse or promote products derived
//    from this software without specific prior written permission.
//
//  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
//  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
//  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
//  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
//  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
//  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
//  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
//  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
//  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
//  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
//  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
//
//*****************************************************************************


--retain=g_pfnVectors
--retain=ulDebugHeader

//*****************************************************************************
// The following command line options are set as part of the CCS project.
// If you are building using the command line, or for some reason want to
// define them here, you can uncomment and modify these lines as needed.
// If you are using CCS for building, it is probably better to make any such
// modifications in your CCS project and leave this file alone.
//*****************************************************************************


//*****************************************************************************
// The starting address of the application.  Normally the interrupt vectors
// must be located at the beginning of the application.
//*****************************************************************************
#define FLHDR_BASE 0x010EBF80
#define FLASH_BASE 0x010EC780


/* System memory map */

MEMORY
{
    /* Application uses internal RAM for program and data */
    FLASH_HDR	(RX)  : origin = 0x01000000, length = 0x0007FF /* 2 KB */
    MAGIC_NUM   (R)   : origin = 0x010E6800, length = 0x000004 /* 4 B */
    APP_ENTRY   (RX)  : origin = 0x010E6804, length = 0x0003FC /* 1 KB */
    FLASH_CODE  (RX)  : origin = 0x010E6C00, length = 0x0193FF /* 101 KB */
    // Total of 102 KB for Matlab Application
    SRAM_DATA   (RWX) : origin = 0x2003C000, length = 0x004000 /* 16 KB */
}

/* Section allocation in memory */

SECTIONS
{
	.magicnum             : > MAGIC_NUM
	.dgbhdr     	      : > FLHDR_BASE
	.app_entry            : > APP_ENTRY
    .text                 : > FLASH_CODE
    .const                : > FLASH_CODE
    .cinit                : > FLASH_CODE
    .pinit                : > FLASH_CODE
    .data                 : > SRAM_DATA
    .bss                  : > SRAM_DATA
    .sysmem               : > SRAM_DATA
    .stack                : > SRAM_DATA(HIGH)
}


 

Thoughts?

Thanks,

Stuart

  • I'm not completely certain, but I am very confident that changing the linker option --ram_model to --rom_model will solve your problem.

    Stuart Baker said:
    This results in a binary that is significantly larger than it should be taking up extra time and data storage in their firmware update procedure.

    The size of a binary file is given by the expression ...

    highest initialized address - lowest initialized address

    The highest initialized address is 0x2003f5d5.  That is for the section .data.  The lowest initialized address is 0x01e6800, for the section .magic_num.  The difference between those numbers is pretty large.  And there is a big hole between the sections .const and .data.  The only way a .bin file can represent such a hole is by filling it with 0.  As you've seen, that can cause problems.

    I suspect you link with --ram_model, which causes the .data section to be an initialized section.  An initialized section typically gets from the executable .out file to the final system by programming it into flash.  But that doesn't make sense for .data.  Yes, it is initialized just like .text.  But it also changes during system execution.  If you change --ram_model to --rom_model, the linker will create a compressed .cinit section out of the initialized values in .data.  Then the .data section is treated as an uninitialized section, like .bss.  Startup code, provided in the compiler RTS library, decompresses .cinit, and initializes .data.  In the linker command file you provided, the .cinit section is allocated to the memory range FLASH_CODE just like .text.  So, you can program .cinit into flash just like .text.

    Thanks and regards,

    -George

  • George,

    Thank you for your suggestion. I had already suggested to the customer to try the --rom_model and the customer claims to have tried this without the resulting binary changing in any way. I myself am skeptical of their result, so I've reached back out to the customer, pasting to them your reply. I'll keep you posted.

    Thanks,
    Stuart
  • George,

    It seems as though the linker is ignoring the option.  Are we getting the link line syntax wrong?

    c:/ti/compiler/bin//armcl -mv7M4 --code_state=16 --rom_model --float_support=vfplib -me -g --define=CC3220sf --define=TIRTOS --define=__ARMCORTEXM4F__ --diag_warning=225 --display_error_number --diag_wrap=off --gen_data_subsections=off --common=off --abi=eabi --embedded_constants=off -z -m"*.map" --stack_size=0x512 --heap_size=0x0 -i"C:/ti/compiler/lib" --reread_libs --issue_remarks --display_error_number --warn_sections --diag_wrap=off --absolute_exe --unused_section_elimination=on --entry_point=MatlabAccessorFunc "*/CC3220sf.cmd" -o *.obj *.obj *.obj *.obj *.obj *.obj *.obj *.obj *.obj *.lib .*.lib -llibc.a
    [15:48:59]W: [Step 1/2] <Linking>
    [15:48:59]W: [Step 1/2] >> WARNING: invalid compiler option --rom_model (ignored)

    I replaced any customer specific file names with '*' in the linker line for anonymity.

    Thanks,

    Stuart

  • You must place the option --rom_model after the option -z
    It is a linker option, not a compiler option
  • This resolved the issue. I knew it had to be something simple.