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.

[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.