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