CMSE stub error & flash loader failure after CubeAI Studio update

[qldrh]

Hello,

I am experiencing two issues that started after updating STM32CubeAI Studio. Both worked correctly before the update.

---

Environment
- Board: NUCLEO-N657X0-Q
- STM32CubeAI Studio: latest update (STEdgeAI Core v4.0.0)
- STM32CubeIDE: 2.1.1
- STM32CubeProgrammer: v2.22.0
- ST-LINK FW: V3J17M10
- Model: MobileNetV3-based custom model (ONNX), int8 quantized and float variants

---

Issue 1: Build failure – CMSE stub too far (float model)

When using a float ONNX model (~19 MB weights), the Appli build fails with:

ERROR: CMSE stub (.gnu.sgstubs section) too far (0x135e520) from destination (0x52f0)
collect2.exe: error: ld returned 1 exit status

Additionally, the linker reports multiple memory regions not declared in the generated `STM32N657X0HXQ_LRUN.ld`:

warning: memory region 'AXISRAM2' not declared
warning: memory region 'AXISRAM3' not declared
... (AXISRAM4, AXISRAM5, AXISRAM6, XSPI1, XSPI2, ROM)

This build succeeded before the update with the same model.

---

Issue 2: Flash failure – flash loader cannot be loaded (int8 model)

When using the int8 quantized model (~4.9 MB weights), the build succeeds (0 errors) but flashing fails:

```
Error: flash loader cannot be loaded.
Error: failed to download Sector[0]
Error: failed to download the File
Run failed: Error: STM32CubeProgrammer exited with code 1
```

The programmer attempts to flash `run-2_Appli.elf` to address `0x00000000`, which appears incorrect for STM32N6 (should target OctoSPI flash via external loader). This also worked before the update.

---

Additional observation

During the generate step, `stedgeai` reports a shell execution failure:
```
error: implicit declaration of function '__DSB' [-Wimplicit-function-declaration]
```
This occurs in `ll_aton_cipher.c` when compiled with `LL_ATON_PLATFORM=LL_ATON_PLAT_SWEMUL` (missing CMSIS header). This error appears in both cases.

---

Question

1. Is the generated `STM32N657X0HXQ_LRUN.ld` missing memory region declarations (AXISRAM2–6, XSPI1/2, ROM) a known regression in the latest update?
2. What is the correct flash procedure for STM32N6 after AI Studio generates the project? Does the tool now require manual flashing with an external loader?
3. Is there a known fix or workaround for the CMSE stub placement error with larger float models?

I will attach the full build logs and model file.

Thank you.

[hamitiya]

Hello @qldrh 

Thanks for your feedback. 

For your issue number 1, it is a "known regression" based on a feature we introduced which permits to load weights as C code instead of binary (raw files). In order to retrieve the same behavior as before, for large models, you need to tick "Export weights as bin" in the "Memory pool" options:

However, linker script should not be LRUN, but ROMXSPI2 since we are using eXecute-In-Place projects. Which version of STM32CubeMX are you using ? 

I also see in the logs "Generating project for board undefined...", which seems incorrect to me. I will look at it. Could you try to create a new project to see if it is reproductible ?

For the issue with __DSB, is it a known issue but can be ignored. It is due to the new version of GCC introduced in STM32CubeIDE. It has no functional impact.

Best regards,

Yanis

[qldrh]

Hello Yanis,

Thank you for your suggestions.

I tested again with:

• a completely new project/workspace

• “Export weights as bin” enabled in Memory Pool

• STM32CubeMX v6.17.0

However, the exact same issues still occur.

Environment:

• STM32CubeAI Studio (latest)

• STEdgeAI Core v4.0.0

• MCU: STM32N657X0H3Q

• Board: NUCLEO-N657X0-Q

Observations:

• The generated linker script is still:
  STM32N657X0HXQ_LRUN.ld
  instead of ROMXSPI2

• The logs still contain:
  Generating project for board undefined...

• Flashing still targets address 0x00000000

• The float model still fails with:
  CMSE stub (.gnu.sgstubs section) too far

• The int8 model still builds successfully but flashing fails with:
  flash loader cannot be loaded

This seems reproducible even on a clean project generation.

From the behavior, it appears that the STM32N6 project may not be generated as a proper XIP / XSPI configuration, possibly due to incorrect board detection or memory mapping during generation.

Best regards