STM32N6570-DK: HardFault when ANY peripheral is enabled with ThreadX or FreeRTOS
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:
FreeRTOS OR ThreadX
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
Confirm whether ThreadX and FreeRTOS are currently supported for STM32N6570 peripherals in CubeMX.
Provide a working minimal example (blinky + UART) using RTOS on N6.
Clarify:
Required MPU configuration
Required security / RIF / TrustZone setup
Required memory placement
Required cache settings
Identify whether this is a known issue on STM32N6 with RTOS.
Provide workaround or patch if available.