.bin file generated by GCC too large

[Mootaz Amr]

Posted on May 08, 2017 at 13:34

Hi ST community members

We are working on the optimization of a project's code running on STM32F429ZIT6 �C, in terms of speeding execution, or minimizing latencies due to memory access competition.

Our solution is to reorganize the code by assigning each AHB-bus-matrix's used master to the appropriate SRAM memory block.

To do that, our linker file is reorganized also, and buffers in our code are replaced in the appropriate sections.

But surprisingly, the .bin file generated is 384MB sized.

The gcc --version output is : (Sourcery CodeBench Lite 2014.05-28) 4.8.3 20140320 (prerelease)

Changes done are as follows:

* ucHeap[ TOTAL_HEAP_SIZE ] __attribute__((section('.bss_SRAM1'))); // FreeRTOS heap (

heap

4) placed in SRAM1.

* Our Ethernet driver's DMA descriptors, TX and RX buffers placed in SRAM2.

* Other miscellaneous critical buffers placed in CCM RAM.

* remaining data (.data and .bss) placed in SRAM3.

You can see attached the sections.ld, mem.ld and a simplified makefile (without projects includes and sources) in the ldscripts.rar.

The data sections sizes generated by the compilation process are as follows:

section                         size             addr

.isr_vector                   824             134217728._inits                          4                  134218552.flashtext                     0                  134218556.text                            273296        134218560.ARM.exidx 8                  134491856.data                          1916             0.data_CCMRAM       36                  268435456.bss_CCMRAM        7560              268435496.bss_SRAM1           10240             536870912.bss_SRAM2           12544             536985600.bss                          49552            1920.noinit                       0                     51472._check_stack        256                 51472.comment                70                   0.ARM.attributes       53                   0.debug_aranges      15592             0.debug_info             528968           0.debug_abbrev       56895              0.debug_line             234916            0.debug_frame         55916              0.debug_str              629362            0.debug_ranges      14184               0.debug_macro       186126             0Total                       2078318

Thanks for help.

#stm32f429 #gcc-linker

[AvaTar]

Posted on May 08, 2017 at 14:20

The gcc --version output is : (Sourcery CodeBench Lite 2014.05-28) 4.8.3 20140320 (prerelease)

Not quite a recent version, but might work.

But surprisingly, the .bin file generated is 384MB sized.

As a first step, I would check the map file, and identify the causal source of your problem.

[Tesla DeLorean]

Posted on May 08, 2017 at 14:34

CCM and SRAM are 256MB apart, .BIN files are NOT sparse and will thus describe all the memory between and including the two regions. If you want a sparse file, use a .HEX or .DFU

[S.Ma]

Posted on May 08, 2017 at 16:54

Fully agree with Clive, BIN is a contiguous block of data without any start address: Avoid it like pest !

Motorola S19 or Intel HEX text format will have only relevant bits of memories stored with their address location.

Tip: The HEX/S19 file can be used in STV Link Utility to have in a single file both the internal and external serial flash memory for example for some discovery boards.

[AvaTar]

Posted on May 08, 2017 at 19:35

Custom bootloaders like Arduino or mbed usually work with BIN files.

Full knowledge of the target's address space has then to be present in the loader.

[S.Ma]

Posted on May 08, 2017 at 19:56

Too bad it was not designed with futureproofing in mind.

[Mootaz Amr]

Posted on May 11, 2017 at 11:22

Hi guys, thanks for your help.   And sorry for last response

I generated the .hex output using the command

#@echo 'Creating Hex file : $@' @$(OBJCOPY) -O ihex $(EXE_DIR)/$(BINARYNAME).out $(EXE_DIR)/$(BINARYNAME).hexThe hex file doesn't work either when downloaded into the µC Flash, no execution, and debug doesn't work on our PC with ST-LINK/V2 (under eclipse) even after several trials and forum search ....

Actually we used a trick to overcome the issue, we've declared the '

ucHeap' and the '

Ethernet driver's DMA descriptors, TX and RX buffers' as they were ST Hardware registers, we used the same manner CMSIS declared the chip hardware registers.

Example for the RTC's SSR register:

#define PERIPH_BASE ((uint32_t)0x40000000) /*!< Peripheral base address in the alias region */

#define APB1PERIPH_BASE PERIPH_BASE

#define RTC_BASE (APB1PERIPH_BASE + 0x2800)

#define RTC ((RTC_TypeDef *) RTC_BASE)

typedef struct

{ __IO uint32_t WPR; /*!< RTC write protection register, Address offset: 0x24 */ __IO uint32_t SSR; /*!< RTC sub second register, Address offset: 0x28 */ __IO uint32_t SHIFTR; /*!< RTC shift control register, Address offset: 0x2C */} RTC_TypeDef;

xDevice[u8DvInd].u8DataRxSeq = (uint8)((RTC->SSR)&0xFF);

the linker file didn't change, just the amount of RAM were decreased to fit only SRAM3.

This comes unfortunately by sacrificing about 8k of RAM precious in future project expand or developments.

Does anyone have an idea to elegantly use the GCC linker file without the huge .bin generated ? we can as a consequence optimize the RAM used.

Thanks.

[waclawek.jan]

Posted on May 11, 2017 at 11:57

You don't have a SRAM3 memory region defined in mem.ld, so the linker fell back to default and assigned it to address 0, as witnessed by

section                        size             addr                                 .data                          1916                0

.bss                          49552             1920.noinit                           0            51472._check_stack                   256            51472

As the SRAM3 is not physically at that address, it can't work.

Furthermore, the compiler tags variables with explicitly assigned section as executable (don't ask me why), thus objcopy copies them out into hex/bin, unless explicitly told not to using the -R switch.

JW

[AvaTar]

Posted on May 11, 2017 at 12:13

@$(OBJCOPY) -O ihex $(EXE_DIR)/$(BINARYNAME).out $(EXE_DIR)/$(BINARYNAME).hex

The hex file doesn't work either ...

No wonder, this is a self-defeating approach.

Your bin file contains way too much data, for addresses not specified for the target. Converting that .bin file to a .hex file is not addressing the issue.

How did you create this bin file in the first place ?

I suggest to create the native format (probably ELF), and convert this to .Hex or .s19, instead of .bin. The objcopy command would do as well.

.. when downloaded into the µC Flash, no execution, and debug doesn't work on our PC with ST-LINK/V2 (under eclipse) even after several trials and forum search ....

I think we better try to address issues one at a time, the failure to debug can well be caused by your oversized .bin file.

[brianshankland9]

Posted on August 29, 2017 at 12:09

I had similar issue with the STM32F746G Discovery demo code for LwIP. I founf an error in the linker map supplied by ST which forgot to put a NOLOAD attribute for the ethernet buffers so the linker was placing data into the SRAM locations as well as FLASH so making the binary 393MB. 

If you have a linker script check for areas mapped to the SRAM and see if this may also the the case.