STM32CubeMX file => linker script file not generated properly

[RAltm]

Hi,

I'm using STM32CubeIDE with a former Atollic TrueStudio project. The import itself succeeded, but it's neccessary to fine tune the settings. Also, when using the STM32CubeMX files, it seems that STM32CubeIDE uses different file names for several source files, resulting in redefinition of several functions (e.g. _sbrk, etc.).

My current problem is that with the former STM32CubeMX file, changing heap/stack size is not reflected in the linker script file. I'm on a STM32L011F4P6 device. I verified it with a new project, there's the same problem. So it can't be related to the old STM32CubeMX file.

Regards

[RAltm]

Hi,

more than four weeks without a response... is this the right place to get attention of the CubeIDE developers? Or where should I place this issue?

Regards

[Pavel A.]

Perhaps because the subject line of your post looks confusing. You wrote that the heap/stack size is not reflected in the linker script, but neither it was in the previous (Atollic) script. So maybe this is not a problem at all? Did the program work before update to CubeIDE?

Then you mention another issue with redefinition of _sbrk and different file names.

Have you tried to remove the old file which contains _sbrk? (syscalls.c?)

Unrelated issues are better to describe in separate questions.

Regards,

-- pa

[RAltm]

Hi Pavel,

okay, I agree that the subject might be confusing. Yes, the problem with _sbrk, etc. is gone by handling with the syscalls files.

But what do you mean by this:

You wrote that the heap/stack size is not reflected in the linker script, but neither it was in the previous (Atollic) script.

Changing the heap/stack setting in the CubeMX tool was reflected in the linker script using Atollic. It wouldn't make sense to have a heap/stack size setting in the configuration tool if changing the settings wouldn't be reflected when re-generating code.

I did a test: it seems that the used device (STM32L011F4P6) is affected, using another device (STM32L462) with CubeIDE will update the linker script settings when changing them in the configuration tool.

Regards

[Cartu38 OpenDev]

I' thinking I've faced same issue as Ralf but maybe found a trick about.

Based on STM32L011F4P6 device I'm getting:

1) Let's define small stack & heap sizes within device configuration editor

2) Generate related code (Alt+K or Project > Generate Code) => I'm getting expected result i.e. linker script in sync. with my setup

3) Have a new try. Let's define large stack & heap sizes within device configuration editor

4) Generate related code (Alt+K or Project > Generate Code) => I'm NOT getting expected result i.e. linker script not in sync. with my setup ???

5) Doing some extra trial I confirm not able to face same issue if some more high end devices (F7, …) => is CubeIDE doing some automated stack & heap size clamp depending on target capbilities ? Looking back at STM32L011F4P6 device such one is very low end one (very few Embedded memories) …. maybe that's why ?

[RAltm]

Hello Cartu38,

thank you for verification. Based on your description, I did some further tests. Changing the heap/stack size in lower area works, the change is always reflected when rebuilding. Bigger values are not recognized. In my old setup (Atollic + CubeMX 5.x), the changes where always reflected, that's why I assume it's a bug. Now, how to point the IDE developers to this?

Regards

[Cartu38 OpenDev]

Let's hope STM guys tracking such forum exchanges … to get bug fixed thanks next release.

By the way yes sounds disturbing behavior but does not such makes sense ? i.e. not allowing a stack & heap sizes which may overflow hardware capabilities ? First guess would be happy about except UI issue here as if clamp process may be ok such is not reflected within UI ….

[RAltm]

I agree that it would make sense that the IDE takes care of values which overflow the capacity of the device. In my case, I use 512 Bytes for stack/heap in total, so it's within the limits of the device, but those values are not accepted. And if the IDE monitors the values and skip them because of overflow, an error message should be shown.