[X-CUBE-AI 10.2.0] error E010 (InvalidCustomLayerImplementation) from stedgeai.exe

[Ziel]

Hello ST Community,

I am encountering an issue with X-CUBE-AI v10.2.0 (embedded in STM32CubeMX 6.14.0) when trying to deploy a PyTorch model with a custom layer to an STM32H7.

I have enabled "Custom layer support" in the X-CUBE-AI settings. I am required to provide a JSON configuration file to map my custom ONNX node to my C implementation. However, I am unable to pass the Analyze step due to a JSON schema validation error.

Environment:

• STM32CubeMX: 6.14.0

• X-CUBE-AI: 10.2.0

• Target: STM32H7

• Backend: ST Edge AI Core v2.2.0-20266

My Goal: I need to map the following custom operator to a C function prefix:

• Operator Name: SpectralConv

• Domain: MyCustom

• Implementation Prefix: spectral_conv

• Header: custom_spectral_conv.h

The Issue: I keep receiving the error E010(InvalidCustomLayerImplementation) from stedgeai.exe. It appears the JSON format I am using is incorrect for this specific version of the core.

Attempts:

1. Using the "prefix" key (Standard Key-Value format):

JSON

 

{
 "MyCustom::SpectralConv": {
 "prefix": "spectral_conv",
 "header": "custom_spectral_conv.h"
 }
}

Error: E010(InvalidCustomLayerImplementation): Malformed remap_layers_filename - Found unexpected nested key prefix

2. Using the "generators" list format:

JSON

 

{
 "generators": [
 {
 "name": "SpectralConv",
 "domain": "MyCustom",
 "prefix": "spectral_conv",
 "header": "custom_spectral_conv.h"
 }
 ]
}

Error: E010(InvalidCustomLayerImplementation): Malformed remap_layers_filename - Found unexpected nested key {'name': ...}

Question: Could anyone please provide the correct JSON schema/syntax for defining custom layers in X-CUBE-AI v10.2.0? It seems the parser does not recognize the prefix key inside the mapping object, nor does it accept the generators list structure.

Any working example for version 10.2.0 would be greatly appreciated.

Thank you in advance.

[Julian E.]

Hi @Ziel ,

 

We do not support custom ONNX (because is much less straightforward with respect to keras).

 

This is not a commonly used feature; I think it needs to be checked internally to understand what to do with it.

Thank you for the remark.

 

Have a good day,

Julian