X-CUBE-AI 10.2.1 / ST Edge AI Core 2.2.0 — ONNX importer ignores Conv dilations (output length wrong)
- September 5, 2026
- 0 replies
- 8 views
Hi,
Summary. The ONNX importer in ST Edge AI Core 2.2.0 (X-CUBE-AI 10.2.1) ignores the
dilations attribute of Conv. It applies the padding but convolves as if dilation = 1,
so the output length is L + 2*pad - (k-1) instead of L. The TFLite importer handles
the same operator correctly.
Minimal reproducer (attached, 51 KB): a single Conv1d(64->64, kernel 3, dilation 4,
padding 4), input 1x64x80. The ONNX node is Conv {pads:[4,4], strides:[1], dilations:[4]}.
Per the ONNX spec the output is (80 + 4 + 4 - ((3-1)*4 + 1)) / 1 + 1 = 80.
PyTorch and onnxruntime both produce 1x64x80.
stedgeai analyze --model dil_f32.onnx --target stm32u5
| model handed to stedgeai | reported output | expected |
|------------------------------------------------------|-------------------------|--------------|
| ONNX float32 | f32(1x64x86) | 1x64x80 |
| ONNX int8 QDQ (per-channel) | int8(1x64x86) | 1x64x80 |
| TFLite float32 (same graph via onnx2tf) | f32(1x1x80x64) | correct |
| TFLite int8 full-integer | int8(1x1x80x64) | correct |
So the defect is in the ONNX front end, and it is not specific to the quantized/QDQ
path - plain float32 ONNX fails identically. Reported MACs are inflated accordingly
(1,062,144 vs the correct 983,040).
Why it matters / how it surfaces. The report shows the layer as Pad_/Conv2D: the Pad
is inserted correctly (+/- d), but the following Conv2D drops the dilation. In a network
with stacked dilated layers the error compounds. In our real model (5 TCN layers,
dilations 1,2,4,8,16) the temporal length grows 80 -> 82 -> 88 -> 102 -> 132, the
average-pool output becomes 16 instead of 10, and the final head emits 1x4x86 instead
of 1x4x80 - a different receptive field and a different network. The only visible
symptom is the output shape; every other number in the report looks plausible.
Environment: ST Edge AI Core v2.2.0-20266 2adc00962 / STM32CubeAI 10.2.0-RC1,
stedgeai macarm build, target stm32u5, macOS (Apple silicon), model exported from
PyTorch 2.9, opset 17, ir_version lowered to 9.
Two smaller issues found along the way, in case they are useful:
1. Utilities/macarm/stedgeai is delivered without the executable bit - it must be
chmod +x before it can run.
2. analyze raises EOFError from build/utilities/stats.py (_ask_user_tracking.get_input)
when stdin is not a TTY. It is non-fatal but noisy in CI.
Happy to provide the full model or run any variant you would like tested.
Best regards,
