Getting bin size as 400+MB after adding new flash(NOR flash) section in linker script

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Getting bin size as 400+MB after adding new flash(NOR flash) section in linker script

Jump to solution
1,658 Views
BhargaviA
Contributor I

Hi All,

I'm trying to use some part of spifi NOR flash memory to execute the program(XIP). To do that I have changed the linker script as below.

MEMORY
{
...
m_text (RX) : ORIGIN = 0x00010400, LENGTH = 0x0006FC00
m_text_xip (RX) : ORIGIN = 0x17FF7FFF, LENGTH = 0x00008000
...
}

SECTIONS
{

.text :
{
. = ALIGN(4);
*(EXCLUDE_FILE(*spifi_xipFun.o) .text*)
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
*(.glue_7) /* glue arm to thumb code */
*(.glue_7t) /* glue thumb to arm code */
*(.eh_frame)
KEEP (*(.init))
KEEP (*(.fini))
. = ALIGN(4);
} > m_text

 

.text_xip :
{
text_xip_start = .;
*spifi_xipFun.o(.text*)
KEEP (*(.text_2));
text_xip_end = .;
} > m_text_xip

}

 

With the above changes I'm getting bin size as normal and spifi_xipFun.o text is going to m_text only even after being excluded from m_text and included in m_text_xip.

Did I do anything wrong in the exclusion and inclusion of the file?

If I move the .text_2 section before the .text section I'm seeing spifi_xipFun.o text in expected memory that is in range of m_text_xip but the bin size is coming as 400+MB.

Please, let me know as soon as possible if I'm doing something wrong.

 

 

 

Labels (1)
0 Kudos
1 Solution
1,649 Views
frank_m
Senior Contributor III

Don't use BIN files.

This format has no meta information like target addresses, so this format needs to fill any "hole" in the memory range to program with default data.

View solution in original post

0 Kudos
7 Replies
1,631 Views
converse
Senior Contributor V

Regarding your EXCLUDE_FILE problem: Try removing the first wildcard from the line. e.g.

EXCLUDE_FILE(*spifi_xipFun.o) .text*

0 Kudos
1,629 Views
BhargaviA
Contributor I

I'm getting syntax error if I remove the wildcard.

0 Kudos
1,650 Views
frank_m
Senior Contributor III

Don't use BIN files.

This format has no meta information like target addresses, so this format needs to fill any "hole" in the memory range to program with default data.

0 Kudos
1,644 Views
BhargaviA
Contributor I

I'm not sure that I understand.

And I'm not using any BIN file names in the linker script.

If you don't mind. Can you please provide me with some examples?

0 Kudos
1,641 Views
frank_m
Senior Contributor III

> I'm not sure that I understand.

Check the difference between the lowest address (probably internal Flash) and the highest address to program (external Flash). This will explain your 400MB space.

> And I'm not using any BIN file names in the linker script.

The output file type and format is not part of the linker script.

Check your project settings, and choose a format like HEX or SREC (S19) instead of binary.

0 Kudos
1,629 Views
BhargaviA
Contributor I

I Agree that the difference between external flash and internal flash addresses is around 400MB, but, why the linker is taking that 400MB to link?

I try to generate a HEX file instead of BIN and saw the same issue but the size is 1MB this time (Without external flash sections the bin size is 350KB).

Tags (1)
0 Kudos
1,618 Views
frank_m
Senior Contributor III

>... but, why the linker is taking that 400MB to link?

This is not a problem with the linker, but with your choice of an inappropriate output file format.

The BIN format has no means of specifying different parts of code for different sections/addresse, so it fills up all the unused space.

0 Kudos