Linking with error: "cannot move location counter backwards"

Mbed OS
1

When compiling and linking I get the error:

:~/git/hmipanel/mbed-os$ mbed-tools compile -m HMC20 -t GCC_ARM
...
/home/sam/git/hmipanel/cmake_build/HMC20/develop/GCC_ARM/source/hmipanel.elf.map
/usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld:/home/sam/git/hmipanel/cmake_build/HMC20/develop/GCC_ARM/mbed-os/targets/TARGET_STM/TARGET_STM32U5/TARGET_STM32U575xG/mbed-stm32u575xg.link_script.ld:90 cannot move location counter backwards (from 0000000020005640 to 000000001ffffc00)
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
ERROR: CMake invocation failed!

I created my own device and updated pinning files as described in the howto’s.

custom_targets.json:

{
    "MCU_STM32U575xG": {
        "inherits": [
            "MCU_STM32U5"
        ],
        "public": false,
        "extra_labels_add": [
            "STM32U575xG"
        ],
        "macros_add": [
            "STM32U575xx"
        ],
        "device_has_remove": [
            "ANALOGOUT",
            "CAN",
            "CRC",
            "FLASH",
            "TRNG",
            "SERIAL_ASYNCH"
        ]
    },
    "HMC20": {
        "inherits": [
            "MCU_STM32U575xG"
        ],
        "clock_source": {
            "value": "USE_PLL_HSE_EXTC|USE_PLL_HSI"
        },
        "components" : ["SD", "SPIF"],
        "overrides": {
            "hse_value": 10000000
        },
        "detect_code": [
            "0000"
        ],
        "device_name": "HMC20"
    }
}
2

This looks like an error in your linker script. Can you share this file?

3

I’m still investigating, but I think that the reason is that MCU_STM32U5 is a family, start addresses are defined but not memory sizes. If you refine to MCU_STM32U575xG you must set memory ranges like:

“mbed_rom_size”: “0x100000”, → 1GB Flash
“mbed_ram_size”: “0xc0000”, → 786K RAM

It’s a pitty that relatively new processors are not already incorporated in Mbed.

4

Ah yes I was about to mention… I think this error is due to incorrectly configured ROM size (and arguably also due to a missing assertion in the linker script), If adding those lines fixes it, hopefully you should be good!

p.s. feel free to contribute your MCU_STM32U575xG target to Mbed CE! I’ve been trying to improve support for STM32U5 in the community fork.

5

That’s the reason. In TARGET_STM32U575xG there is a cmsis_nvic.h file that says:

#if !defined(MBED_ROM_START)
#define MBED_ROM_START 0x8000000
#endif

#if !defined(MBED_ROM_SIZE)
#define MBED_ROM_SIZE 0x0 // 0 B
#endif

#if !defined(MBED_RAM_START)
#define MBED_RAM_START 0x20000000
#endif

#if !defined(MBED_RAM_SIZE)
#define MBED_RAM_SIZE 0x0 // 0 B
#endif

I find it strange because why it is not filled in? The G type is always 1G/786K. The 575/585_I are correctly filled in in mbed-os.

Reference: https://www.st.com/resource/en/brochure/brstm32ulp.pdf

6

It was a probably a mistake. How you can see in the STM32U5 folder are just 3 variants and only two has assigned a dev board. That will be the reason why two are correctly filled and the last one not.

I do not see that like a tragedy, mistakes happen. And it could be filled via .json files (like you wrote above.) that is enough for custom target anyway.

BR, Jan