STM32N6570-DK: HardFault when ANY peripheral is enabled with ThreadX or FreeRTOS

[JaiGanesh]

Issue Summary

On STM32N6570-DK, enabling ANY peripheral together with ThreadX or FreeRTOS causes an immediate HardFault, even in a minimal CubeMX-generated project with no user code.

This includes peripherals such as:

• DCMIPP

• LTDC

• SDMMC

• USB

• UART

• I2C

• SPI

• GPIO with interrupts

• DMA

• Anything beyond simple GPIO output

The issue is NOT limited to the camera/display pipeline.

---

Environment

• Board: STM32N6570-DK

• IDE: STM32CubeIDE (latest)

• CubeMX: latest version

• Firmware: STM32N6 HAL/BSP (latest)

• Security Modes Tested:

  • FSBL + Application (secure/non-secure)

  • Non-secure Application only (no FSBL)

Both show the same problem.

---

What Works

✔ RTOS disabled → All peripherals work
✔ Camera + display pipeline works bare-metal
✔ GPIO output works with RTOS (LED blink, simple logic)

---

What Fails

:cross_mark:ThreadX + ANY peripheral init → HardFault
:cross_mark:FreeRTOS + ANY peripheral init → HardFault
:cross_mark:Even minimal projects with zero user code crash before scheduler start
:cross_mark:Commenting a peripheral moves the crash to the next peripheral init call

This happens even if RTOS is never started.

Example minimal code that crashes:

int main(void) 
{ 
HAL_Init(); 
SystemClock_Config(); // OK 
MX_GPIO_Init(); // OK 
MX_USART1_UART_Init(); // HardFault here 
MX_FREERTOS_Init(); // never reached 
vTaskStartScheduler(); // never reached }

Replacing UART with LTDC, DCMIPP, SDMMC, USB, SPI, etc. produces the same HardFault.

---

Minimal Reproduction Setup

Fresh CubeMX project → STM32N6570-DK → Non-secure application only

Enable:

1. FreeRTOS OR ThreadX

2. ONE peripheral (any peripheral except simple GPIO output)

Compile → Run → HardFault before entering user code.

---

Behavior Observed

• HardFault occurs inside HAL init for the first peripheral that uses:

  • DMA

  • Interrupts

  • Clocks beyond basic GPIO

  • NVIC

  • Cache-sensitive memory

  • Peripheral register access

• If DCMIPP is commented → LTDC crashes

• If LTDC is commented → SDMMC crashes

• If SDMMC is commented → UART crashes

This makes it clear that the RTOS + STM32N6 low-level HAL interaction is broken.

---

Tests Already Performed

• Verified with both ThreadX and FreeRTOS

• Repeated under FSBL+Application and standalone Application

• Removed all user code

• Removed all camera/display code

• Moved buffers to different RAM regions

• Disabled MPU

• Disabled ICACHE/DCACHE

• Disabled SysTick

• Increased stacks and heaps

• Checked TrustZone/NSC configuration

• Checked RIF/Security attributes

• Confirmed same behavior on multiple freshly created projects

---

Conclusion

This appears to be a system-level issue in STM32N6 RTOS integration.
CubeMX-generated startup, memory layout, low-level drivers, or TrustZone/RIF configuration may not be correctly handling RTOS environments.

The critical point is:

Any RTOS + any peripheral (beyond GPIO) = HardFault, even before scheduler start.

This is not normal, and seems like a HAL, BSP, or CubeMX integration bug specific to STM32N6.

---

What I Request From ST

1. Confirm whether ThreadX and FreeRTOS are currently supported for STM32N6570 peripherals in CubeMX.

2. Provide a working minimal example (blinky + UART) using RTOS on N6.

3. Clarify:

   • Required MPU configuration

   • Required security / RIF / TrustZone setup

   • Required memory placement

   • Required cache settings

4. Identify whether this is a known issue on STM32N6 with RTOS.

5. Provide workaround or patch if available.