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]

Would you be able to post the pt-logger-l433-test.elf.map file so I can look what symbol is being located at that address? Wondering if there's something in your code that has .m_crash_data_ram as its section.

[JohnK1987]

I tried to googling this behavior and the solution usually was add a NOLOAD keyword to a section of RAM of linker. But I am not so experienced with linker so I do not know this is the case.
And strange also is the behavior is not same every time.

[xillion]

Here is map file
pt-logger-l433-fw.elf.zip

[multiplemonomials]

OK looks like there is something in your code that's putting itself in .crash_data_ram:

 .crash_data_ram
                0x10000290        0x4 Libs/bsp/libbsp.a(ptl_device.cpp.obj)

You may wish to check ptl_device.cpp for any code that is trying to use this section. Currently Mbed OS is not set up to have user data in the crash data RAM section (and that's likely a bug, but oh well). If you would like to put this data in the crash data ram section:

• I'd have to release a patch for the linker script
• The data needs to be zero-initialized instead of initialized with a value (which it currently seems to be).

[xillion]

Yes, You are Sherlock Holmes , Bravo !!!

This code was a temporary stopgap while I was writing my bootloader and it was working in mbed-os before it switched to unified ld scripts.

Could you explain why this string of code creates such effect? Honestly I can't understand.
static volatile std::uint32_t boot_selector __attribute__((section(".crash_data_ram")));
And what I should use to preserve data while soft reboot?

static volatile std::uint32_t boot_selector __attribute__((section(".crash_data_ram")));
#define SYSTEM_BOOTLOADER_ADDRESS 0x1FFF0000

void reboot_into_dfu()
{
  boot_selector = 0xDECAFBAD;
  NVIC_SystemReset();
}
 
void SystemInit(void)
{
    std::uint32_t conBootloadAddress = SYSTEM_BOOTLOADER_ADDRESS;
    void (*SysMemBootJump)(void);
    if(boot_selector == 0xDECAFBAD){
        boot_selector = 0;
        SysMemBootJump = (void (*)(void)) (*((std::uint32_t *) (conBootloadAddress + 4)));
        __set_MSP(*(std::uint32_t *)conBootloadAddress);

        SYSCFG->MEMRMP = 0x01;

        SysMemBootJump();

        while (true) {
        }
    }

    #include "nvic_addr.h"                   // MBED
    //#include "ptl_device.h"
    SCB->VTOR = NVIC_FLASH_VECTOR_ADDRESS; // MBED

    #if defined(USER_VECT_TAB_ADDRESS)
    /* Configure the Vector Table location -------------------------------------*/
    SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;
    #endif

    /* FPU settings ------------------------------------------------------------*/
    #if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
    SCB->CPACR |= ((3UL << 20U)|(3UL << 22U));  /* set CP10 and CP11 Full Access */
    #endif

    /* Reset the RCC clock configuration to the default reset state ------------*/
    /* Set MSION bit */
    RCC->CR |= RCC_CR_MSION;

    /* Reset CFGR register */
    RCC->CFGR = 0x00000000U;

    /* Reset HSEON, CSSON , HSION, and PLLON bits */
    RCC->CR &= 0xEAF6FFFFU;

    /* Reset PLLCFGR register */
    RCC->PLLCFGR = 0x00001000U;

    /* Reset HSEBYP bit */
    RCC->CR &= 0xFFFBFFFFU;

    /* Disable all interrupts */
    RCC->CIER = 0x00000000U;
}

[multiplemonomials]

Well, what that __attribute__ does is put that variable into the crash data RAM section. Unfortunately it seems like the linker is deciding that it needs to manually initialize that variable with data, and the only way to do that is to make the bin file big enough so that it stretches all the way from the start of flash into the crash data ram section. I don't really understand why it's doing that though...

[multiplemonomials]

Let's see if we can get this to work.. try changing the crash data ram section in stm32l4_dual_flash_bank.ld to the following:

    .crash_data_ram (NOLOAD):
    {
        . = ALIGN(8);
        __CRASH_DATA_RAM__ = .;
        __CRASH_DATA_RAM_START__ = .; /* Create a global symbol at data start */
        . += M_CRASH_DATA_RAM_SIZE;
        . = ALIGN(8);
        KEEP(*(.keep.crash_data_ram))
        *(.m_crash_data_ram)     /* This is a user defined section */
        __CRASH_DATA_RAM_END__ = .; /* Define a global symbol at data end */
    } > SRAM2

This adds NOLOAD to hopefully prevent the linker from trying to load it. It also moves the *(.m_crash_data_ram) line so that it won't conflict with the actual crash data RAM.
Let me know if this works!