Why bin file is so big?

[xillion]

I have compiled my project with latest mbed-ce and got huge bin file and missed prettyprint about bin file.
Where I should dig ?

[JohnK1987]

Hello,

maybe stupid question but for sure, did you perform clean build (delete build folder) and check correct compiler is called?

BR, Jan

[JohnK1987]

I created new empty project and size of .bin file is OK = 60KB. But I also do not see the memory report @multiplemonomials

[xillion]

I did this many times - totally delete build folder and restart compilation. I can use the elf file for flashing with stm32cubeprogremmer and everything works.

[JohnK1987]

Hmm, I tried to build a blinky for regular Nucleo-L432KC and result still OK.

[multiplemonomials]

@xillion What mbed target are you building for? Are you able to link your code? If not, can you post your mbed_app.json?

[multiplemonomials]

I have seen these issues with giant .bin files before and it usually turns out to be a linker script problem

[xillion]

I build for custom target based on stm32l433ccu
Here is custom target definitions in archives below. One with and another without modification of cmsis_mcu_descriptions.json5
pt-logger.zip (with)
custom_targets.zip (without)

I have added missing part to cmsis_mcu_descriptions.json5

    "STM32L433CCUx": {
        "algorithms": [
            {
                "default": true,
                "file_name": "CMSIS/Flash/STM32L4xx_256.FLM",
                "ram_size": null,
                "ram_start": null,
                "size": 262144,
                "start": 134217728
            },
            {
                "default": false,
                "file_name": "CMSIS/Flash/STM32L4xx_SB_OPT.FLM",
                "ram_size": null,
                "ram_start": null,
                "size": 20,
                "start": 536836096
            }
        ],
        "family": "STM32L4 Series",
        "from_pack": {
            "pack": "STM32L4xx_DFP",
            "url": "http://www.keil.com/pack",
            "vendor": "Keil",
            "version": "2.2.0"
        },
        "memories": {
            "IRAM1": {
                "access": {
                    "execute": false,
                    "non_secure": false,
                    "non_secure_callable": false,
                    "peripheral": false,
                    "read": true,
                    "secure": false,
                    "write": true
                },
                "default": true,
                "size": 49152,
                "start": 536870912,
                "startup": false
            },
            "IRAM2": {
                "access": {
                    "execute": false,
                    "non_secure": false,
                    "non_secure_callable": false,
                    "peripheral": false,
                    "read": true,
                    "secure": false,
                    "write": true
                },
                "default": false,
                "size": 16384,
                "start": 268435456,
                "startup": false
            },
            "IROM1": {
                "access": {
                    "execute": true,
                    "non_secure": false,
                    "non_secure_callable": false,
                    "peripheral": false,
                    "read": true,
                    "secure": false,
                    "write": false
                },
                "default": true,
                "size": 262144,
                "start": 134217728,
                "startup": true
            }
        },
        "name": "STM32L433CCUx",
        "processor": {
            "Symmetric": {
                "core": "CortexM4",
                "fpu": "SinglePrecision",
                "mpu": "Present",
                "units": 1
            }
        },
        "sectors": [
            [
                134217728,
                2048
            ]
        ],
        "sub_family": "STM32L433",
        "vendor": "STMicroelectronics:13"
    }

[xillion]

I have conducted an investigation into the issue. As @multiplemonomials suggested, the linker script (LD script) may be the root cause. Before the unification of LD scripts, the build worked correctly, but afterward, it began generating an excessively large binary file. A comparison of the startup assembly files confirmed that they are identical in both versions. Next, I analyzed the mbed-target-config.h files: The analysis revealed a change in the configuration method, but the current implementation and its usage remain unclear.

[multiplemonomials]

Hmm. The most likely cause of an issue like this would be if the linker is including a section located in one of the RAM banks in the bin file. This is determined by the "load commands", aka PHDRS, associated with the section in the elf file.

Would you be able to post the output of running

$ readelf -Wl

on your program elf file? That will dump the sections in the elf file and their load commands.