Skip to main content
DatTran
Associate
September 5, 2026
Question

X-CUBE-AI 10.2.1 / ST Edge AI Core 2.2.0 — ONNX importer ignores Conv dilations (output length wrong)

  • September 5, 2026
  • 1 reply
  • 37 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,

1 reply

Julian E.
ST Technical Moderator
September 14, 2026

Hi ​@DatTran,

 

Thank you for your detailed report, I will share it to the dev team as I reproduce it even in newer core versions.

 

Please not that X Cube AI is “Not recommended for new design”.

ST Edge AI Core 2.2 is pretty old. We advise you to now use the new tool replacing it STM32Cube AI Studio

https://www.st.com/content/st_com/en/campaigns/edge-ai-toolchain-for-mcus-z14.html

 

Have a good day,

Julian

​In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.