cancel
Showing results for 
Search instead for 
Did you mean: 

Hello, I am using the STM32CubeG4 SDK to create a new project. The problem is that while there are some linker scripts provided for the IAR compiler, I cant find any for the GCC. The same applies to other SDKs Where can I find these linker scripts?

PChat.2
Associate
 
3 REPLIES 3
TDK
Guru

There are some linker scripts available in the examples. Here is one at random:

https://github.com/STMicroelectronics/STM32CubeG4/blob/master/Projects/NUCLEO-G431KB/Examples/GPIO/GPIO_IOToggle/STM32CubeIDE/STM32G431KBTX_FLASH.ld

If you feel a post has answered your question, please click "Accept as Solution".
PChat.2
Associate

TDK Thank you so much your answer.

I already know that the linker scripts can be found in the examples or generated with the CubeMX but it not the kind of solution I really want.

You see what I am trying to setup a project to use either GCC or IAR.

To solve this I figured out that, depending on the compiler, the project could "point" and use the appropriate SDK files (including the linker script).

The problem is that the absence of these linker scripts for GCC makes this solution inconsistent and leaves me with two choices

  1. Either add files to the SDK which I don't really like because I would have to maintain this "modified version" of the SDK and add updates from the ST manually with every new release
  2. Or add explicitly the linker scripts to the project making it inconsistent and misleading as the linker script should be or should not be a part of the project. It should not be depending on the compiler
  3. Add both linker script to the project

I guess that the best solution would be for ST to have the linker script in a separate folder just like it has been done for the IAR compiler.

I don't expect it to be this hard so I can't find a good cause for this inconsistency in an otherwise really good SDK

TDK
Guru

Much time can be wasted trying to make a project compiler-agnostic. Unless you have a compelling reason ($$$) for testing and maintaining multiple toolchains, choosing one and sticking with it will be a far more efficient route. Save brainpower and productivity for programming tasks.

It's not like there is a single linker script for each chip, anyway. They will need to be customized for each project unless you are doing the bare-bones minimum.

If you feel a post has answered your question, please click "Accept as Solution".