.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

[dmitry baranov]

Posted on March 01, 2018 at 11:47

You may consider adding an attribute (NOLOAD) to the section of your additional RAM block, like this:

   .ram2 (NOLOAD) :

  {    _sram2 = .;    *(.ram2)        KEEP(*(.ram2))     . = ALIGN(4);    _eram2 = .;  } >RAM2 

It will explain the linker, that the NOLOAD-region is a part of .bss.

[Andrew Neil]

Posted on March 01, 2018 at 12:12

After very nearly a year, it's probably a bit late to be suggesting 'solutions' to this old problem!

But the proposed 'solution' will not help - as already described, you cannot have gaps in a BIN file!

[Andrew Neil]

Posted on March 01, 2018 at 12:13

No, that is an entirely different problem - see:

https://community.st.com/0D50X00009XkYIPSA3

[dmitry baranov]

Posted on March 01, 2018 at 14:15

Concerning the gaps in a BIN you are absolutely right.

However if one do not need to pre-allocate memory in RAM2 region at the compilation time this solution works prefectly.

Using (NOLOAD) directive prevents program loader to load the section into memory and thus there is no nessecity to attach it to a binary file.

[Andrew Neil]

Posted on March 01, 2018 at 14:23

But it was exactly the gaps in the bin file that were the subject of this thread!

Hence the 

proposed 'solution' will not help to resolve the problem this thread is about.

[One&Zero]

I have the same problem, I agree that this problem is due to the linker forgot to put a NOLOAD attribute for the ethernet buffers.