STM32N6570-DK: HardFault (__LL_ATON_RT_IrqErr, BUSIF_1) during NPU inference with Getting Started Object Detection (STEdgeAI 4.0.1)

[Ryutarou]

Hi ST Support Team,

We encountered a reproducible HardFault when running an object detection model on the STM32N6570-DK, and have completed extensive isolation testing. We believe this points to an issue in the STEdgeAI 4.0.1 / Neural-ART toolchain combined with the Getting Started reference application (concurrent camera/display/NPU usage), rather than a configuration mistake on our side.

[Environment]
- Board: STM32N6570-DK (with IMX335 camera)
- Project: Getting Started Object Detection App (stm32ai-modelzoo-services)
- Model: st_yoloxn (1 class, 416x416), Quantized (input: uint8 / output: int8)
- Toolchain: STEdgeAI Developer Cloud v4.0.1 (forced by cloud; v4.0.0 is no longer offered, though the project's own README states the shipped model files were generated with v4.0.0)

[Symptom]
Build, flash, and boot-from-flash all complete without error, but the LCD stays black. Debugging via STM32CubeIDE shows a HardFault during NPU inference:

HardFault_Handler()
__LL_ATON_RT_IrqErr(irqs)   // ll_aton_runtime.c
LL_ATON_RT_RunEpochBlock()

'irqs' is consistently 0x44000000 (bit26 = BUSIF_1 bus interface error, bit30 = EPOCHCTRL_0_2, the 3rd Epoch Controller block).

[Isolation Testing — all excluded]
1. Not model-specific: identical irqs/crash location reproduced with our fine-tuned model AND ST's own unmodified st_yoloxn_d033_w025_416 model (re-quantized ourselves with the same int8 settings).
2. Model/compiler sanity: OK. The same quantized model runs successfully via STEdgeAI Developer Cloud's `benchmarking` feature on a real STM32N6570-DK (no camera/LCD) — 21.03ms inference, no error.
3. NPU memory capacity: within limits per compile report (up to 100%, never exceeded); changing `optimization` (balanced/time) made no difference.
4. ecblob / weight data integrity: re-flashing fresh copies did not change the symptom.
5. Library/runtime version mismatch: excluded. The entire `stedgeai-lib` folder (Lib, Inc, Npu/ll_aton) is verified to be freshly synced on every deploy (confirmed via file timestamps matching the latest build), and no compile-time error ("Possible mismatch in ll_aton library used") has ever occurred.
6. Memory overlap: excluded. NPU buffers reside in AXISRAM; LCD framebuffers reside in external PSRAM via XSPI1 — physically separate (verified in linker script).
7. NPU execution mode: already STAI_MODE_SYNC (polling), not interrupt-driven.
8. NPU clock frequency: halved (IC6 divider 1→2, 1000MHz→500MHz) — same irqs=0x44000000, crash persists.
9. D-Cache: disabled entirely — same irqs=0x44000000, crash persists.
10. Power-up / boot-mode procedure: verified correct (full power-cycle after switching boot mode).

[Our Hypothesis]
The Getting Started app runs camera capture (DCMIPP) and LCD display (LTDC) DMA concurrently with NPU inference, all sharing the AXI bus. We suspect STEdgeAI 4.0.1's Neural-ART code generation (Epoch/bus access scheduling) is not tolerant of this concurrent bus load, whereas the reference app's bus/RIF/cache configuration was validated against v4.0.0.

[Related Community Reports]
We found the following threads describing very similar or related symptoms, without confirmed resolution:
- https://community.st.com/edge-ai-134/stm32n6-gfx-cubeai-161998 — Same __LL_ATON_RT_IrqErr HardFault when enabling TouchGFX + CubeAI simultaneously; XSPI2 bus contention suspected. ST moderator indicated a concurrent TouchGFX+CubeAI tutorial was in development (pending camera driver updates), no solution given yet.
- https://community.st.com/edge-ai-134/stm32n6-ltdc-goes-black-when-calling-ll-aton-rt-init-network-160449 — LTDC display goes black specifically when LL_ATON_RT_Init_Network() is called, with camera + display + NPU running together (each works fine individually, based on a YOLOv8 instance-segmentation project derived from the peopleDetection example). No replies, unresolved.
- https://community.st.com/edge-ai-134/issue-with-npu-operation-on-discovery-n657-167289 — Non-deterministic NPU inference results on STM32N657 with STEdgeAI 4.0.1 (unresolved).
- https://community.st.com/edge-ai-134/st-ssd-mobilenet-v1-return-an-irq-error-151511 — Same BUSIF + __LL_ATON_RT_IrqErr pattern, previously caused by a library/generated-code version mismatch (not our case, since we've verified version consistency).

[Questions]
1. Is there a known compatibility issue between STEdgeAI 4.0.1-generated Neural-ART code and reference apps that run DCMIPP/LTDC/NPU concurrently (both this Getting Started app and other camera+display+NPU projects, per the threads above)?
2. Is the TouchGFX+CubeAI tutorial mentioned in thread 161998 also applicable to this LTDC-based (non-TouchGFX) Getting Started app? Is it available yet?
3. Are there recommended bus master priority (QoS/RIF) settings to prioritize NPU access during concurrent DMA activity?
4. Is STEdgeAI Core v4.0.0 (the version this project's shipped artifacts were generated with) available for download anywhere, to allow a direct A/B comparison?

Thank you for your help.

[lemnslth]

Im seeing the exact same thing on my STM32N6570-DK.  Im using the Getting Started Object Detection app, STEdgeAI 4.0.1, HardFault in __LL_ATON_RT_IrqErr with irqs = 0x44000000 (BUSIF_1 + EPOCHCTRL_0_2). I came looking for help, and saw that you were experiencing the exact same issue. Just wanted to bring more attention to this thread

[Ryutarou]

Thanks for confirming — glad (well, not glad, but reassured) to know it's not just our setup. 
Since we're seeing the exact same irqs value on independent hardware/models, this really does look 
like a toolchain/reference-app issue rather than a configuration mistake on either of our ends.

Have you tried anything specific yet, or run into this with a different model too? 
We've ruled out memory capacity, library version mismatch, D-Cache, and NPU clock speed on our side 
(all detailed above) — same crash persists regardless. Would be good to compare notes if you've tried 
anything we haven't.

Also flagging this to ST support directly, so hopefully having two independent reports helps get 
traction.

[lemnslth]

Apologies for the late response. I ended changing my STM32CubeIDE version to 1.17.0, editing the YAML to reflect the new path, and it resolved the issue for me.

[Ryutarou]

Thank you so much for coming back with this — no apology needed, this is genuinely the most actionable lead we've gotten on this issue.

We've been using STM32CubeIDE 2.1.1 this whole time, without realizing the project's own default YAML template actually points to 1.17.0. We'll install 1.17.0, update the path_to_cubeIDE in our config, and test on our board.

One question if you have a moment: did you only need to change the CubeIDE path, or did you also need to adjust anything else (e.g. a specific GCC toolchain version bundled with 1.17.0, or the .cproject file)? Just want to make sure we replicate your fix exactly.

Will report back once we've tested — thanks again, this could save a lot of people a lot of time.

[lemnslth]

I only needed the update the CubeIDE path to 1.17.0 after its installation. Nothing else was adjusted. It was installed with the default options. I hope this resolves your issue as well!

[Ryutarou]

Perfect, thanks for the clarification — that's exactly what we needed to know. 
Installing 1.17.0 now and will update our path_to_cubeIDE accordingly. 
Will report back with results. Really appreciate you taking the time!