cancel
Showing results for 
Search instead for 
Did you mean: 

Weird binary size growth

turboscrew
Senior III

Has anyone else stumblen on this?

I had a build configuration, and I needed to do another for a different memory area.

I made a new one with a different name based on the existing configuration, and when it compiled and linked, I removed the old one. Then I made another new one but with different linker script for the other memory area. The linker script file is the same for the original configuration and the first new one, and almost same for the second new one - only the memory areas changed.

But when the original configuration produced about 150 kB binary image, the new ones produce over 300 000 kB image.

Also, the binary image seems to have extension .binary (instead of .bin) and it doesn't seem to be changeable. Why? .bin is conventional, and even ST-link SW wants .bin, it doesn't accept .binary extensions.

4 REPLIES 4
S.Ma
Principal

BIN files are a contiguous block of data. No offset, no "holes".

If the new memory mapping configuration is changed, bin file size may as well.

S19 or HEX file size might remain similar as it's using multiple data fragment with absolute address information for each one of them.

For the file extension change, maybe something was incorrectly setup.

Yes, but as I mentioned, for the first new configuration, the linker script is the same. For the second new linker script file, only the memory area for the image was changed.

It was done in MEMORY-block. That is: for one image the FLASH was defined to be 0x08020000 and for the other 0x08080000. Both areas are of the same size (3x128kB = 3 sectors).

turboscrew
Senior III

Also one irritatin thing is that you can only browse for the the linker script file - and one file only. And the path become absolute starting from C:\. You can change that to relative by hand-editing the project files. I think you still can't use more than one linker script file.

turboscrew
Senior III

Reverting to previous version and redoing the last changes fixed the size problem, but another problem emerged. FreeRTOS reboots in its initialization. I haven't yet found out the nature of the problem.