Generated Binary file size is too large(~2.3GB)

Split it into multiple sections?

Use a .HEX, these can represent sparse files better. The .BIN is trying to be a linear representation of memory, and the two regions have a lot of distance between them.​

Normally, an ELF file is a lot smaller than a bin file, since the ELF avoids huge amounts of zeroes that are usually in the bin. The fact that in your DEBUG case it's the opposite means that you have a huge ELF, with a lot of debug information (not uploaded to the target) added. Which implies to me that the ELF has a LOT of zeroes in it (although I don't know that).

Normally, variables with starting values (like addresses, or counters, or other values) are assigned to the `.data` linker section, stored in the code (thus the ELF), and copied to RAM at system startup. These are notably all non-zero, so the only possible way they can be initialised is by copying them from Flash.

All other variables don't need to be stored in Flash, since their value is usually set at runtime by putting them in the `.bss` section. These are variables that start at zero, so the linker doesn't allocate them in Flash (thus they take no space in Flash), but in RAM--and at startup they are zeroed by the "Zero the BSS RAM section now" function in the C runtime library.

If you write the following code, the results for `begin` and `end` MUST be stored in the `.data` (and therefore Flash) section, since it otherwise has no way of knowing the values. But note that `buffer` does NOT have any initialisation data, so it just needs to be zeroed, so can be stored in the `.bss` section. (C and C++ both guarantee that a variable starts with the value zero unless it's initialised to something different).

char buffer[0x2000];
 
char *begin = buffer;
char *end = buffer + sizeof(buffer);

Thus the `.data` section has two pointers (2x four bytes, which need to be in Flash), while the RAM section has 8192+4+4=8200 bytes: 4 bytes each for `start` and `end` (originally copied from Flash), plus 8192 bytes for the actual buffer (which is zeroed, so not stored in Flash).

Even if you write the following code, `buffer` will not take any extra Flash: the compiler realises that all the values are zero, so still puts them in the `.bss` section:

char buffer[0x2000] = { 0, 0, 0, 0, 0, 0, 0 };

However, if somehow your code is the following, you've got a problem:

char buffer[0x2000] = { 0x08, 0x18, 0x7C, 0xFF, 0x7C, 0x18, 0x08 };

This is an initialised array, so needs to be stored in Flash before it can be copied to RAM. (Note that there are better ways of doing this: for example, if the bitmap is fixed, it should be declared as `const`, so (usually) won't be copied from Flash to RAM at all.)

If your code has bitmaps or other graphic elements stored in Flash, then no amount of improving the code will fix the sheer amount of space in Flash that they're taking. One mechanism to improve this is not to store the raw graphics in Flash, but to store compressed versions of the data in Flash, and during boot to decompress them into RAM (this assumes there's more RAM than Flash - not always the case). Please look at your linker compression options to decide if this will help.

Personally, I think that your environment has declared huge amounts of zeroed buffers, but somehow told the linker that they need to be copied from Flash rather than initialised at startup.

>>Personally, I think that your environment has declared huge amounts of zeroed buffers, but somehow told the linker that they need to be copied from Flash rather than initialised at startup.

No, he has TWO ROM regions, one at 0x08000000 (code) and another at 0x90000000 (graphic data)

0x90000000-0x08000000 = 2,281,701,376

There is a large void which has no representation

Keil's FromELF tool would split the output into multiple binaries describing the individual regions, not try to output a single monolithic binary.

I completely missed that! Thank you! That explains why the executable is so large.

@Community member​ You need to understand that the resulting binary will include everything that you've defined. Therefore it will include everything: more than the code that you're trying to burn into Flash. You need to separate what goes into (code) Flash versus what goes into (data) Flash, and organise to burn the data Flash separately. Or use @Community member​'s solution.

I have the same problem. I don't know how to solve it.