TM4C1294KCPDT: Generated bi file is too large

Hi,

  I will forward your question to our CCS experts. Please expect delay in response as it is a US public holiday. 

Please let me know if the article An Introduction to Binary Files is helpful.

Thanks and regards,

-George

I want to retain variable state even after watchdog reset, so I have done following changes in myProject.cmd file

Please check the content of the file below

#define NO_OF_BYTE_FOR_NOINIT 1000

#define START_ADD 0x20000000

#define LEN 0x00040000

#define MEMORY_RANGE_NAME (START_ADD + (LEN - NO_OF_BYTE_FOR_NOINIT))

//#define MEMORY_RANGE_NAME 0x2003FF9C//(0x0003FF9C) = 0x20000000 + (0x00040000 - 100)

MEMORY

{

FLASH (RX) : origin = 0x00000000, length = 0x00100000

// SRAM (RWX) : origin = BASE_ADDRESS, length = 0x00040000

SRAM (RWX) : origin = 0x20000000, length = 0x00040000

// MEMORY_RANGE_NAME : origin = BASE_ADDRESS, ...

}

/* Section allocation in memory */

SECTIONS

{

.text : > FLASH

.const : > FLASH

.cinit : > FLASH

.pinit : > FLASH

.init_array : > FLASH

.data : > SRAM

.bss : > SRAM

.sysmem : > SRAM

.stack : > SRAM

mysect:var > MEMORY_RANGE_NAME, type = NOINIT

}

I have defined noinit section in memory.

if I compiled the code and generate .bin file then size of the bin file is 528MB.

myProject.cmd file after commenting Noinit

If I comment the Noninit section and compile the code then size of bin file is 219kb.

#define NO_OF_BYTE_FOR_NOINIT 1000

#define START_ADD 0x20000000

#define LEN 0x00040000

#define MEMORY_RANGE_NAME (START_ADD + (LEN - NO_OF_BYTE_FOR_NOINIT))

//#define MEMORY_RANGE_NAME 0x2003FF9C//(0x0003FF9C) = 0x20000000 + (0x00040000 - 100)

MEMORY

{

FLASH (RX) : origin = 0x00000000, length = 0x00100000

// SRAM (RWX) : origin = BASE_ADDRESS, length = 0x00040000

SRAM (RWX) : origin = 0x20000000, length = 0x00040000

// MEMORY_RANGE_NAME : origin = BASE_ADDRESS, ...

}

/* Section allocation in memory */

SECTIONS

{

.text : > FLASH

.const : > FLASH

.cinit : > FLASH

.pinit : > FLASH

.init_array : > FLASH

.data : > SRAM

.bss : > SRAM

.sysmem : > SRAM

.stack : > SRAM

//mysect:var > MEMORY_RANGE_NAME, type = NOINIT

}

Please guide us as I want noinit section

George is out today but should be able to reply tomorrow.

Anushka Parab21 said:

I have defined noinit section in memory.

if I compiled the code and generate .bin file then size of the bin file is 528MB.

myProject.cmd file after commenting Noinit

If I comment the Noninit section and compile the code then size of bin file is 219kb

The only explanation is that there must be some initialized section very far away in memory from all the other initialized sections. The part of the binary files article titled Avoiding Holes discusses this situation.

Anushka Parab21 said:

I want to retain variable state even after watchdog reset

Unfortunately, I lack the expertise to help you do that.  I'll refer this thread to the device experts.

Thanks and regards,

-George

Hello Anushka,

Anushka Parab21 said:

I want to retain variable state even after watchdog reset, so I have done following changes in myProject.cmd file

I am not really familiar with this method you are trying to do. From what I see it works for some TI MCUs but I haven't seen it used for TM4C before personally so I am not sure how robust it is.

Usually to retain variable states across resets, customers will leverage the EEPROM memory instead. That is a much more robust and reliable way than trying to retain in SRAM. Is that an option you can consider?

Best Regards,

Ralph Jacobi

We had done this in our old system with LM3s6965 controller with keil compiler.

please check below linker scripting file

;
; Texas Instruments (TI) is supplying this software for use solely and
; exclusively on TI's microcontroller products. The software is owned by
; TI and/or its suppliers, and is protected under applicable copyright
; laws. You may not combine this software with "viral" open-source
; software in order to form a larger program.
;
; THIS SOFTWARE IS PROVIDED "AS IS" AND WITH ALL FAULTS.
; NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT
; NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
; A PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. TI SHALL NOT, UNDER ANY
; CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
; DAMAGES, FOR ANY REASON WHATSOEVER.
;
; This is part of revision 7611 of the EK-LM3S6965 Firmware Package.
;
;******************************************************************************

LR_IROM 0x00000000 0x00040000
{
    ;
    ; Specify the Execution Address of the code and the size.
    ;
    ER_IROM 0x00000000 0x00040000
    {
        *.o (RESET, +First)
        * (InRoot$$Sections, +RO)
    }

 RW_IRAM1 0x20000000 UNINIT 0x00000600
 { ;no init section
        *(NoInit)
    }

    ;
    ; Specify the Execution Address of the data area.
    ;
    RW_IRAM 0x20000600 0x0000FA00
    {
        ;
        ; Uncomment the following line in order to use IntRegister().
        ;
        ;* (vtable, +First)
        * (+RW, +ZI)
    }
}

If develops correct bin file

I do not understand what you are trying to accomplish.  When you write ...

Anushka Parab21 said:

mysect:var > MEMORY_RANGE_NAME, type = NOINIT

What do you want to happen to the section mysect:var during all phases of execution?  What should happen at startup?  During execution?  During a subsequent reset?  Please answer in as much detail as you can.

Thanks and regards,

-George

) i would like to have a global variable that will not be initialized and/or set to zero. if i am assigning the variable to a specific section (pragma DATA_SECTION) it still gets initialized to zero. 

the NOINIT option could/should be a solution but it forces the variable to a dedicated TI.NoInit section and i could not find a way to set a different section if using the #pragma NOINIT.

How can i do this?

It is not possible to apply both #pragma DATA_SECTION and #pragma NOINIT to the same variable.  There are few different ways you can achieve the same effect.  The one I suspect is most straightforward ... In C use DATA_SECTION, and in the linker command file apply NOINIT.  

/* C code */
#pragma DATA_SECTION(var, "mysect:var")
int var;

/* Linker command file - inside SECTIONS directive */
    mysect:var > MEMORY_RANGE_NAME, type = NOINIT

Guy Mardiks said:

2) when i have an initialized global variable (even set to a dedicated section - #pragma DATA_SECTION) the linker/compiler always set a .cinit entry for it and compresses the data. 

how can i prevent this from happening - i don't want this variable to be compressed as i want the initialized data to be loaded with the image (part of the binary) so it will be available BEFORE and C decompression functions?

The linker option --cinit_compression=none disables all compression of the .cinit section.  There is no method to disable cinit compression for just one variable.  Well, there might be a way to do it.  But I haven't thought of one so far.

Guy Mardiks said:

3) on the TI linker when will i need to use the -u flag (for example i noticed that the generated linker file from sysBios sets a -u _c_int00 --> why was this needed isnt it enough to have a .global / extern in the asm/C file ? when/how/why  this -u is used?

I don't know why SYS/BIOS uses -u _c_int00 .  

The use case for -u that I know ... When you want to force the linker to bring a function out of library, even though there are no calls to that function in the application, you use -u name_of_library_function.  

Guy Mardiks said:

4) If possible, can you emphasize of the difference between NOINIT and NOLOAD?

An explanation of NOLOAD, and other special section types like it, is in the article Linker Special Section Types.

The type NOINIT is not explained in that article.  A NOINIT section is an uninitialized section like .bss.  Normally, it would be subject to being initialized.  However, you can disable that default behavior by adding type = NOINIT on the linker command file line for that output section.

Guy Mardiks said:

5) is there a way, when assigning a section to a memory to tell the linker to allocate this section to the memory start / memory end (i could not find a "high" / "low" keywords and also i could not use symbols - the only way so far i could accomplish this is by writing the start address of the memory as a constant number but i would like to use the origin address of the memory)?

There is no method for doing that in C.  One method that comes to mind ... Write a header file that is shared between the C code and the linker command file.  Create #define names that are used in both.  Something like this ...

/* Shared header file */
#define BASE_ADDRESS 0x20000000

/* linker command file - MEMORY directive */
MEMORY_RANGE_NAME : origin = BASE_ADDRESS, ...

/* C code */
#pragma LOCATION(var, BASE_ADDRESS)
int var;

/* C code */
#pragma LOCATION(var, BASE_ADDRESS)
int var;

Please check the link

I want to retain variable 

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/680680/compiler-variable-initialization

it is working properly if I debug the program through CCS. but it is generating 528MB of bin file and I am not able to production program the IC

Thanks and Regards,

Anushka

Please attach the linker map file to your next post.  So the forum will accept it, add the file extension .txt to it.  While I doubt seeing the map file will allow me to resolve the problem, I do expect it will allow me to ask better questions.

Thanks and regards,

-George

AGM_CAM_V1_5.txt

Please check the attached MAP file of the Project.

Thank you for the map file.  I have a good guess as to the problem, and a suggestion for how to fix it.

The most interesting lines in the map file are ...

mysect:var 
*          0    2003fc18    000002ef     
                  2003fc18    00000228     run_avg.obj (mysect:var) [fill = 0]
                  2003fe40    00000060     Application.obj (mysect:var:uninit) [fill = 0]
                  2003fea0    0000001a     ADC_Task.obj (mysect:var) [fill = 0]
                  2003feba    00000002     check_overRange.obj (mysect:var) [fill = 0]
                  2003febc    00000014     ADC_module.obj (mysect:var) [fill = 0]
                  2003fed0    0000000d     checkDetector.obj (mysect:var) [fill = 0]
                  2003fedd    00000001     display.obj (mysect:var) [fill = 0]
                  2003fede    0000000a     alarmHandler.obj (mysect:var) [fill = 0]
                  2003fee8    00000008     output.obj (mysect:var) [fill = 0]
                  2003fef0    00000007     Application.obj (mysect:var:init)
                  2003fef7    00000006     Keyboard.obj (mysect:var) [fill = 0]
                  2003fefd    00000005     seven_segment.obj (mysect:var) [fill = 0]
                  2003ff02    00000003     mb_coils.obj (mysect:var) [fill = 0]
                  2003ff05    00000002     multiApplication.obj (mysect:var) [fill = 0]

This means mysect:var is an initialized section in SRAM, which you do not want.  Notice how every line says fill=0 except the one for Application.obj.  There must be something different about the contents of mysect:var in Application.c.  My guess is that it is something like this ...

#pragma DATA_SECTION(const_variable, "mysect:var")
const int const_variable = 25;

It might be structure or array instead of a single variable.  But it is probably in mysect:var, const, and initialized.  

The answer is to change it to an uninitialized variable.  

#pragma DATA_SECTION(const_variable, "mysect:var")
int const_variable;

Initialize it by adding some code elsewhere ...

const_variable = 25;

... and running that as needed.  It may make sense to put it in a dedicated function, then call that function from one of the boot hook functions.  For more information about the boot hook functions, please search the TI ARM compiler manual for the sub-chapter titled Boot Hook Functions for System Pre-Initialization.

Please let me know if this suggestion resolves the problem.

Thanks and regards,

-George