STM32N6570-DK – Deployment stops when ST-LINK is not connected

[Vic_Ch]

Dear ST

Environment

Item Version / Details

Board	STM32N6570-DK
OS	Ubuntu 24.04 LTS
Python	Conda, Python 3.10
STM32AI Model Zoo	stm32ai-modelzoo-services/object_detection
Operation mode	deployment
Model	yolov8n_256_quant_pc_uf_od_coco-person-st.tflite
STM32CubeIDE	1.19.0
ST Edge AI Core / STM32CubeAI	10.2.0
Local tool	/opt/ST/STEdgeAI/2.2/Utilities/linux/stedgeai

---

Description

I am using the STM32AI Model Zoo deployment workflow on Linux to deploy a YOLOv8 object detection model to the STM32N6570-DK.

The deployment pipeline reaches the final flashing stage and aborts because no ST-LINK device is connected, even though all previous steps (Neural-Art, code generation, project patching) completed successfully.

---

Console log excerpt

building.. Debug flashing.. Debug STM32N6570-DK board programming is SKIPPED! -> No valid STM32 development board is connected (ST-LINK/swd port).. ... raise STMAICToolsError('Board programming failed!') E400: Board programming failed!

---

Expected behavior

Even when the board is not connected, deployment should still:

• Finish building the STM32CubeIDE project

• Export the final firmware (network_data.hex / *.bin)
  This is necessary for CI pipelines and automated batch deployments.

---

Actual behavior

Because board programming fails due to no ST-LINK detected, the deployment pipeline terminates with an error, and no network_data.hex is produced, even though the Neural-Art and code-gen outputs are valid.

C-project patching is confirmed to be correct:

network.c network_ecblobs.h network_atonbuf.xSPI2.raw AI_Runtime/

→ Deployment stops right before final firmware generation.

---

Current workaround

I manually generate a hex file from network_atonbuf.xSPI2.raw:

arm-none-eabi-objcopy \ -I binary network_atonbuf.xSPI2.raw \ --change-addresses 0x70380000 \ -O ihex network_data.hex

Flashing the resulting hex succeeds, but the display stays completely black (no UI, no bounding boxes, no inference output).
This suggests the manual hex only contains the model blob, not the complete firmware built by the deployment process.

---

Hypothesis

Deployment performs more than just packing network_atonbuf.xSPI2.raw:

Component Required for successful firmware?

AToN compiled blob	✔
application C patching	✔
app_config.h update	✔
complete CubeIDE project rebuild	✔
UI overlay + inference loop	✔
ST-LINK programming	should be optional

Since the deployment aborts before the final firmware build, only the raw model blob is flashed, resulting in a black screen.

---

Questions for ST

1. How can we complete the deployment and generate the final firmware (.hex/.bin) without connecting the STM32N6570-DK?

2. Is there a configuration flag available, e.g.:

   • skip_flasher: true

   • build_only: true

   • generate_hex_without_flashing: true

3. If the current toolchain does not support this yet, what is the recommended CI-friendly workflow for offline firmware generation?

4. If the intended solution is “build manually in CubeIDE”, could ST provide documentation on how to:

   • update the project after Neural-Art output

   • trigger a full firmware rebuild

   • avoid black-screen output after flashing

[Julian E.]

Hello @Vic_Ch,

Thank you for your detailed post.

It is probably badly explained and not really thought to be used like this, but I think that everything you need in what you describe is present.

First, the firmware modified by model zoo services scripts is this package usable as standalone. If you look at the documentation coming with it, it should solve most of your interrogations:

STMicroelectronics/STM32N6-GettingStarted-ObjectDetection: An AI software application package demonstrating simple implementation of object detection use case on STM32N6 product.​

If we go back to your situation, even if the deployement is not complete, based on what is being done, you should be able to deploy everything by doing the following:

1. The default application (the getting started firmware) is in stm32ai-modelzoo-services\application_code\object_detection\STM32N6
2. in \Model\STM32N6570-DK you should find an updated network_atonbuf.xSPI2.bin, you can either run the command to create the .hex file or directly flash it with CubeProgrammer at this adress: 0x70380000 
   With this, the weights of the model are flashed.
3. Regarding the app, you need 2 things:
   1. The FSBL, in \binary: ai_fsbl.hex (the source of this is STM32Cube_FW_N6\Projects\STM32N6570-DK\Templates\Template_FSBL_LRUN)
   2. The application with the updated pre and post processing (app_config.h), which you can find in \Application\STM32N6570-DK\STM32CubeIDE\Debug. You can flash STM32N6570-DK_GettingStarted_ObjectDetection_signed.bin at this address: 0x70100000 (found in the doc of the getting started)
4. If you flash the fsbl, the app and the weights as I described, by restarting the N6 in boot mode, you should have everything functioning correctly.

Have a good day,

Julian

[Vic_Ch]

Hi Julia,
I followed the link below and successfully completed the update using the Prebuilt Binaries approach:
https://github.com/STMicroelectronics/STM32N6-GettingStarted-ObjectDetection?tab=readme-ov-file

Question 1
From the following path:
/stm32ai-modelzoo-services/object_detection/src/experiments_outputs/2025_11_17_21_55_57/generated
Can I directly create STM32N6570-DK/network_data.hex to replace the current model and proceed with flashing?

Question 2
Is it possible to package the model solely using the following shell script?
https://github.com/STMicroelectronics/stm32ai-modelzoo-services/blob/main/application_code/object_detection/STM32N6/Model/generate-n6-model_STM32N6570-DK.sh

Question 3
If I want a single project to include multiple models, is that feasible?

Question 4
Ultimately, I would like to separate model generation and firmware development into two independent workflows (traditional development flow).
Is this achievable?

[Julian E.]

Hi @Vic_Ch,

1) I don't remember exactly what is replaced, but yes, it takes files from the experiment_outputs and replace them in the application being flashed. Look at the files date in /application_code to know what is from the default getting started and what was replaced.

2) The getting started application were designed to be use as standalone (manually or with the .sh scripts) or via the model zoo. In the end it is the same thing, so yes, you can just use the shell scripts.

3) yes, you can, I believe that the hand landmark package uses one model for the detection of the hand on the image, then a second one for the landmarks: STM32N6-AI | Software - STMicroelectronics

This document should also be helpful: ST Neural-ART NPU concepts

4) These documents present what to take into considaration, but as long as you have that in mind and keep in mind the memory needed for the activations and weights of the model (result of the generate command, using the st edge ai core), then, yes I think it answers your needs.

STM32N6 Example projects & tips for creating new projects

Session - ST Edge AI Developer Cloud

Have a good day,

Julian

[Vic_Ch]

Hi Juliae,

I have a question regarding the model flashing result.

I manually converted and flashed the network_data.hex, but the application on the STM32N6570-DK booted to a black screen.
To clarify the situation, I prepared two comparison cases.

Case 1: Customized network_data.hex
I followed the manual flow (model generation, raw to hex conversion, flashing).
The model files were generated using the deployment configuration, and the raw file was converted to hex to replace the default network_data.hex.
The full flashing sequence (FSBL, network_data, application) completed successfully without any error messages.
However, after reboot, the display remained black.

Case 2: Pre-built network_data.hex
The original default network_data.hex was flashed without modification.
Under exactly the same flashing procedure and environment, the application executed normally and the display worked as expected.

Summary of the observation:
Both flashing logs reported successful completion.
The pre-built network_data.hex (about 1.28 MB) works correctly.
The customized network_data.hex (about 2.48 MB) results in a black screen.

This suggests that although the flashing procedure is correct, the format or memory layout of the manually generated network_data.hex may not match what the application expects.

If needed, I can provide additional information such as the generated directory structure, YAML configuration used for model generation, or the xSPI memory address layout.

Let me know what information would be most helpful for further debugging.

[Julian E.]

Hello @Vic_Ch,

I think your issue is that you did not edit the app_config.h and postprocessing.

When using model zoo, it is done automatically, but not if you do the manual flow.

If you look at the doc: 

STM32N6-GettingStarted-ObjectDetection/Doc/Deploy-your-tflite-Model-STM32N6570-DK.md at main · STMicroelectronics/STM32N6-GettingStarted-ObjectDetection

You will see that the generation of the hex file is not the only thing to do, then you need to adapt app_config.h for the kind of model you use.

This is probably what explains why the default .hex works and not your .hex. The app_config is aligned with the model used.

When you use the deployment in model zoo, it is done automatically.

I attached the yaml I used to deploy yolov8n_256_quant_pc_uf_od_coco-person-st.tflite and the app_config generated in /application_code

Have a good day,

Julian

[Vic_Ch]

Hi Juliae,
I have fully grasped the model generation procedure and configuration recommendations you previously shared.
Regarding the deployment_n6_yolov8_config.yaml file from the STMicroelectronics/stm32ai-modelzoo-services project: I have successfully followed this configuration to perform Model Validation, Firmware Flashing, and verify the Demonstration Functionality.
Core Challenge: Manual construction/merging of the final HEX file for flashing. Since my STM32 Application Development Environment is decoupled from the AI ​​Model Training/Conversion Platform, despite deployment_n6_yolov8_config.yaml providing an end-to-end flow, I am encountering difficulties in the phase of Customized Deployment.
My question is: Given the generated Project Compilation Artifacts, is there a feasible method and a set of standard steps to manually link or integrate the independently produced Model Binary (data blob) into the final firmware within the STM32 IDE (e.g., STM32CubeIDE) project?

[Julian E.]

Hello @Vic_Ch,

I am not sure to understand your question.

If you mean that you want to deploy your model without the ST Model Zoo, then you need to follow this:

STM32N6-GettingStarted-ObjectDetection/Doc/Deploy-your-tflite-Model-STM32N6570-DK.md at main · STMicroelectronics/STM32N6-GettingStarted-ObjectDetection

Basically:

1. Generate the .hex
2. Edit the app_config.h
3. Potentially create new pre/post process (but here you use a st model)
4. flash the .hex weights and open the cubeIDE project from the getting started, for build and run (in dev mode)
5. to create an application in boot mode, look at this: STM32N6-GettingStarted-ObjectDetection/README.md at main · STMicroelectronics/STM32N6-GettingStarted-ObjectDetection

If you want to create your own application and not use the example package we provide, these documents should provide you help:

https://stedgeai-dc.st.com/assets/embedded-docs/stneuralart_stm32n6_projects.html and the hello world application found in local install of the ST Edge AI core

https://stedgeai-dc.st.com/assets/embedded-docs/stneuralart_api_and_stack.html

Have a good day,

Julian