Csolution template for STM32 CubeMX: Linker Scatter File - Missing Conditional Compilation and Duplicate Stack Definition

[W-MINE]

Type: Bug Report

Describe the bug

• OS and Version:Windows 11
• VS Code Version:1.107.1
• Extension Version:1.64.1
• Target Device:STM32F4 Series

Create new solution with "CubeMX Basic solution" Template, The Default Generated Linker Scatter File, Missing Conditional Compilation and Duplicate Stack Definition.

ac6_linker_script.sct.src

#if __HEAP_SIZE > 0
  ARM_LIB_HEAP  (AlignExpr(+0, 8)) EMPTY __HEAP_SIZE  {   ; Reserve empty region for heap
  }
#endif

  ARM_LIB_STACK (__RAM0_BASE + __RAM0_SIZE - __STACKSEAL_SIZE) EMPTY -__STACK_SIZE {   ; Reserve empty region for stack
  }

Regions Header File

// <h> Stack / Heap Configuration
//   <o0> Stack Size (in Bytes) <0x0-0xFFFFFFFF:8>
//   <o1> Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>
#define __STACK_SIZE 0x00000200
#define __HEAP_SIZE 0x00000C00
// </h>

Expected behavior

Because CubeMX automatically generates assembler startup file, the stack and heap definition should be disabled in the Regions Header File by setting __STACK_SIZE and __HEAP_SIZE to 0

ac6_linker_script.sct.src

#if __HEAP_SIZE > 0
  ARM_LIB_HEAP  (AlignExpr(+0, 8)) EMPTY __HEAP_SIZE  {   ; Reserve empty region for heap
  }
#endif

#if __STACK_SIZE > 0
  ARM_LIB_STACK (__RAM0_BASE + __RAM0_SIZE - __STACKSEAL_SIZE) EMPTY -__STACK_SIZE {   ; Reserve empty region for stack
  }
#endif

Regions Header File

// <h> Stack / Heap Configuration
//   <o0> Stack Size (in Bytes) <0x0-0xFFFFFFFF:8>
//   <o1> Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>
#define __STACK_SIZE 0x00000000
#define __HEAP_SIZE 0x00000000
// </h>

[DavidLesnjak]

@W-MINE,thanks for reporting — we’re aware of this behavior and it’s consistent with how STM32CubeMX works.

This is already documented in the CMSIS-Toolbox CubeMX guide (Linker Script section):
https://open-cmsis-pack.github.io/cmsis-toolbox/CubeMX/

CubeMX always generates a startup file that defines stack/heap, but for “simple/basic” configurations it often does not generate an AC6 linker script (scatter file). In that case, it’s fine to use the default CMSIS-Toolbox linker templates (regions + ac6_linker_script.sct.src), but you must avoid defining stack/heap twice (once in startup and again in linker templates).

What we do in our examples (and what we recommend documenting more clearly):

In the regions header, remove the Stack/Heap config section so __STACK_SIZE / __HEAP_SIZE aren’t defined there (CubeMX startup already provides them).

In the AC6 scatter template, default __STACK_SIZE and __HEAP_SIZE to 0 and ensure ARM_LIB_STACK is guarded with #if __STACK_SIZE > 0 (heap is already conditional in the template).

This prevents reserving extra stack/heap regions in the linker script when they’re already accounted for by the CubeMX startup file.

We’ll follow up with a documentation improvement.

[W-MINE]

@W-MINE,thanks for reporting — we’re aware of this behavior and it’s consistent with how STM32CubeMX works.

This is already documented in the CMSIS-Toolbox CubeMX guide (Linker Script section): https://open-cmsis-pack.github.io/cmsis-toolbox/CubeMX/

CubeMX always generates a startup file that defines stack/heap, but for “simple/basic” configurations it often does not generate an AC6 linker script (scatter file). In that case, it’s fine to use the default CMSIS-Toolbox linker templates (regions + ac6_linker_script.sct.src), but you must avoid defining stack/heap twice (once in startup and again in linker templates).

What we do in our examples (and what we recommend documenting more clearly):

In the regions header, remove the Stack/Heap config section so __STACK_SIZE / __HEAP_SIZE aren’t defined there (CubeMX startup already provides them).

In the AC6 scatter template, default __STACK_SIZE and __HEAP_SIZE to 0 and ensure ARM_LIB_STACK is guarded with #if __STACK_SIZE > 0 (heap is already conditional in the template).

This prevents reserving extra stack/heap regions in the linker script when they’re already accounted for by the CubeMX startup file.

We’ll follow up with a documentation improvement.

Thank you, I understand.

However, there's a problem: without manual modifications, the compilation process doesn't display any errors. This is risky because not every developer will carefully read the documentation, especially when there are no compilation errors.

It would be even better if the extension could be modified automatically in the future, as this would lower the barrier to entry and make it easier for more people to get started.