In consistence btw generated model files and CLI command parameter
- August 11, 2026
- 0 replies
- 18 views
Dear ST Edge AI Support Team,
We are deploying a YOLO11n person-detection model on the STM32N6 NPU using the relocatable
(LRUN) generation flow. While decoding the generated runtime buffer descriptors on-target, we
found that the top-level *input* user-IO buffer's channel-position metadata disagrees with its
own reported memory shape, and does not change when explicitly requesting a channel-last input
layout.
Configuration
Target: STM32N6
ST Edge AI Core v4.0.1-20581 7ed50de05
Model: yolo11n_256_quant_pc_uf_od_coco-person-st.tflite (quantized, uint8 input, 256x256x3)
stedgeai cli command (as echoed by network_generate_report.txt):
"stedgeai generate --model yolo11n_256_quant_pc_uf_od_coco-person-st.tflite --relocatable
split --target stm32n6 --no-inputs-allocation --no-outputs-allocation --optimization
balanced --st-neural-art user_profile@profile-neural-art.json --name network --verbosity 1
--c-api st-ai --inputs-ch-position chlast --workspace ./workspace --output ./outputs"
Issue
The generated network_generate_report.txt confirms `--inputs-ch-position chlast` was received
and correctly resolved at the IR level - the layer table shows the model input as
`[b:1,h:256,w:256,c:3]` (line 9), i.e. NHWC as requested.
However, the generated runtime buffer descriptor for the same input tensor is
self-contradictory, and this is unchanged whether or not `--inputs-ch-position chlast` is
passed:
In outputs/network.c, LL_ATON_Input_Buffers_Info_network():
static const uint32_t buff_info__mem_shape_F_1_256_256_3[] = { 1, 256, 256, 3 };
...
.mem_shape = buff_info__mem_shape_F_1_256_256_3,
.mem_ndims = 4,
.chpos = CHPos_First, /* <- inconsistent with mem_shape below */
Per ll_aton_NN_interface.h, `chpos` is documented as "Position of channels dimension in mem
shape". `mem_shape = {1, 256, 256, 3}` unambiguously has the channel dimension (3) at index 3
(last), matching the buffer's own byte size (196608 = 256*256*3*1 byte) and the IR table above.
A `chpos` of `CHPos_First` implies the channel dimension is at index 1 (value 256), which is
wrong on its face.
The same contradiction appears independently in outputs/network_c_info.json, buffer
"Input_5_out_0":
"shape": [1, 256, 256, 3],
"channel_first": true,
"channel_last": false,
i.e. the shape field is NHWC while channel_first/channel_last flags say the opposite.
For comparison, the *output* buffer's equivalent fields are internally consistent
(mem_shape={1,5,1344}, chpos=CHPos_First, with the channel-like dim of 5 genuinely at index 1),
so this appears isolated to the top-level *input* user-IO buffer under this particular
combination of options.
What we have tried
Regenerated the model from scratch with `--inputs-ch-position chlast` added - the IR-level
shape resolves correctly (see report line 9), but the emitted chpos/channel_first value for the
input buffer descriptor in network.c and network_c_info.json does not change.
Cross-checked byte size (196608 bytes = 256*256*3) and camera pipeline layout (DCMIPP/ISP always
hands frames over as interleaved NHWC) against both mem_shape and shape - both agree with NHWC,
only chpos/channel_first disagree.
Worked around this on our side by no longer branching on chpos/channel_first for the input
buffer and instead reading mem_shape directly, with a byte-size sanity check
(H*W*C*bytes_per_element == buffer length) as a guard against a genuine future layout change.
Request
Can you confirm whether chpos/channel_first for the top-level input buffer is expected to
reflect the buffer's own mem_shape/shape (as documented), or whether there is a known
discrepancy for `--relocatable split --no-inputs-allocation --c-api st-ai` output?
Is `--inputs-ch-position chlast` expected to affect this specific generated field, or only the
model's internal/IR-level layout?
Is there a more authoritative field or API (rather than chpos/channel_first) we should use at
runtime to determine the true memory layout of a `LL_Buffer_InfoTypeDef` user-IO buffer?
Attachments
model_files/outputs/network_generate_report.txt (generation log, includes CLI args and IR
layer table)
model_files/outputs/network.c (LL_ATON_Input_Buffers_Info_network / LL_ATON_Output_Buffers_Info_network)
model_files/outputs/network_c_info.json (buffers[] entries for Input_5_out_0 / Transpose_1177_out_0)
