Error when building relating to .elf and flash overflow data

[matthewtng]

I did the steps below:

1. Use Motor Control WorkBench to create and configure my eval board with motor characteristics with its HAL sensors

2. Used CubeMX to generate the project

3. Opened the generated project in CubeIDE and tried to build

I have not touched the code or anything just wanted to see if I could build the code then I am getting an error stating:

C:/ST/STM32CubeIDE_1.13.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: Dribbler Motor.elf section `.data' will not fit in region `FLASH'

C:/ST/STM32CubeIDE_1.13.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 160 bytes

I tried looking into the build analyzer and nothing is showing up in the build analyzer

I was wondering where I could possibly remove code/data being stored into the flash? Is the HAL sensor drivers too large?

[TDK]

There is bound to be an optimization setting you can enable that will free up 160 bytes.

Or consider using the Release configuration to build, which will get rid of large amounts of unused code and optimize the rest. The default Debug configuration keeps everything in there to aid with debugging.

 

[matthewtng]

Hi,

Thank you so much for the fast reply. I tried using the Release build configuration but it still gets the same error

 

[matthewtng]

I optimized for size and it fixed the issue but what implications could this cause? Performance issues ? I am in the early stage of development trying to just evaluate design and investigation

[TDK]

Optimizing for size will favor small code size over fast code. However, the effect is typically very minimal. I wouldn't spend time thinking about it until you are in the final stages of the project, if even then.

[Pavel A.]

>nothing is showing up in the build analyzer

IIRC the build analyzer needs the .map and list files. Check that these files are generated.  (why the elf file doesn't contain enough info?)

 

[Tesla DeLorean]

Evaluate what you're actual foot-print is likely to be and pick a part with enough head-room to accommodate current and future code expectations, and mission creep.

Pick parts which have immediate families members in the same form and fit as the current part you buy, but with larger RAM/FLASH sizes. Often price stratification is achieved by selling the same die tested to different levels of capacity, ie die might have 512 KB, and options to get 128 and 256 KB versions, where time on tester is a significant contributor to throughput / cost.

Most products use firmwares that have optimization turned on, as this is most efficient. The compiler can fold the code, pull code that doesn't change out of loops, etc, and change ordering, use registers instead of memory to hold transient values. Without optimization you can debug code in a linear 1:1 relationship between what you wrote, and what the MCU executes. Lines of C code typically translate to multiple machine instructions, these can be a linear blob, or be mixed up somewhat for the sake of efficiency, the former is a lot easier for most humans to visualize.