FLASH.ld syntax error when upgrading to CubeMX v6.12.1

[OmidES]

Hello,

Since the latest release of CubeMX (6.12.1), I have been encountering syntax errors related to the "FLASH.ld" file. This issue only arises when I generate code while setting the Toolchain/IDE to CMake. I am using STM32H753IIKx. It seems that CubeMX does not specify which RAM to use when setting the Toolchain/IDE to CMake.

I have also included the FLASH.ld file that was generated for your reference.

 

Thanks for your help.

[STTwo-32]

Bonjour @OmidES 

Could you please attach you .ioc file (if possible for the two CubeMX versions).

Best Regards.

STTwo-32 

[OmidES]

Bonjour,

Yes, sure. I have attached the two versions.

Another issue that I also faced, in CubeMX 12.6.0, was when I set the Toolchain to CMake, the DTCMRAM is used. However, if I change the Toolchain to STM32CubeIDE, the RAM_D1 is being used. Is there a way to select which RAM to use in CubeMX?

Thanks again for your help.

[xingpeng]

it seem like a bug。 the same configuration,  6.12.0 works well. but  6.12.1 have ld error

[Anyone-else0]

F303 Generated .ld missing RAM symbol; won't compi... - STMicroelectronics Community

it's cool

[LLeva.1]

Confirmed with regular "make".

Missing "RAM" in .ld file. When I repair the file, next cubeMX code generation breaks it again:

 

 

ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
- _estack = ORIGIN(RAM) + LENGTH(RAM); /* end of RAM */
+ _estack = ORIGIN() + LENGTH(); /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x200; /* required amount of heap */
_Min_Stack_Size = 0x400; /* required amount of stack */


@@ -143,7 +143,7 @@ SECTIONS

 . = ALIGN(4);
 _edata = .; /* define a global symbol at data end */
- } >RAM AT> FLASH
+ } > AT> FLASH

 
 /* Uninitialized data section */

@@ -160,7 +160,7 @@ SECTIONS
 . = ALIGN(4);
 _ebss = .; /* define a global symbol at bss end */
 __bss_end__ = _ebss;
- } >RAM
+ } >

 /* User_heap_stack section, used to check that there is enough RAM left */
 ._user_heap_stack :

@@ -171,7 +171,7 @@ SECTIONS
 . = . + _Min_Heap_Size;
 . = . + _Min_Stack_Size;
 . = ALIGN(8);
- } >RAM
+ } >

 

c:/program files (x86)/gnu arm embedded toolchain/arm/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld.exe:STM32F446RCTx_FLASH.ld:56: syntax error
collect2.exe: error: ld returned 1 exit status

Adding "RAM" back to ld will fix it.

 

Thanks GITHUB for keeping proper version! Interesting, old bugs are still here? When we'll get hotfix? And I don't want to hear about "concerned team for investigation".

     

[OmidES]

I found a quick solution. You can generate the code by setting the Toolchain to STM32CubeIDE. Then make a copy of the .ld file and use it on your project. Becausae the .ld file generated when setting Toolchain to STM32CubeIDE is still correct.

I hope that helps.

[eduard0-claudi0]

In STM32CubeMX, just click on "TOOLS"  menu then select both:

Save project and re-generate it. The linker file will be correct

[eduard0-claudi0]

I WAS WRONG! Sorry ....

The correct action is to select FLASH (or RAM) in "Search an Application Region" :

Then save and re-generate project.

:(

[takis]

Well, this is not the solution either. In my case, for STM32F103C8Tx, CubeMX does not allow configuring it's memories (under tools).

CubeMX produces an .ld file completely different when exporting for Makefiles and exporting with build files for STM32CubeIDE. Strangely, the .ld file produced for using with STM32CubeIDE reports it is generated by STM32CubeIDE and not by MX.

FYI, I am attaching the two different linker files

[cyclebot]

Wow, this is so frustrating. I lost the better part of a day's work due to this bug. Not so much lost code, but lost time, trying to figure out what I'd done wrong in my project. To then finally discover it's not anything I did wrong, but rather it's a bug in CubeMX. Lame. 

For anyone experiencing this issue, here's what I did to resume productivity. 

1. Removed CubeMX 6.12.1
2. Restored from git to get my project prior to the point where 6.12.1 migrated my ioc file
3. Installed CubeMX 6.12.0
4. Somewhat painfully got my project back to where it was before 6.12.1 (despite frequent git commits)

The take away is: do frequent git commits, and never trust that letting CubeMX migrate your project isn't going to break something. The irony for me was, I'd updated CubeMX due to a bug in the version I'd been running (fields in the app would suddenly become non-responsive to keyboard input). 

 

 

 

 

[takis]

Another option (but not without risk), you can edit the IOC file and change the mininum cubemx required version, I am pretty sure they did not change anything between 6.12.0 and 6.12.1 they just broke the tool

[grzegorz]

CubeMX forgets about references to RAM

We have:

_estack = ORIGIN() + LENGTH();    /* end of RAM */

Should be

_estack = ORIGIN(RAM) + LENGTH(RAM);    /* end of RAM */

And at the end of .data section definition:

  } > AT> FLASH

Should be:

  } >RAM AT> FLASH

Also for .bss

  } >

Should be:

  } >RAM

And for ._user_heap_stack we have:

  } >

Should be:

  } >RAM

[karolalexandersecret]

Thanks a lot Grzegorz,

 

Your answer helped me on two separate project ! Hope the next version of cubeMX come soon

[YangZhang]

When the fixed version will be released

[Andrew Neil]

Now a recognised problem:

https://community.st.com/t5/stm32cubemx-mcus/issue-with-linker-script-in-stm32cubemx-6-12-1/td-p/733007

[RichardS1]

Certified ST software quality moment.

Imagine how trivial it is to test this thing before pushing it to thousands of users.

Please, increase you QA budget at least.

This is a nightmare...

[DBS06]

Exactly, they would have just needed an auto-build process in their build pipeline, but it seems they don't have any, otherwise this bug wouldn't have made it to the release...