cancel
Showing results for 
Search instead for 
Did you mean: 

stm32ai generate error

ManuZhu
Associate II

The error occurs when I try to run the code generated for model squeezenetv1.1_xxx_tfs_int8.tflite 

The command I used to generate code is stm32ai generate -m squeezenetv1.1_128_tfs_int8.tflite -O ram
And I follow the guide "How to run locally a c-model" in the X-CUBE-AI Documentation to get the executable.
When I run the elf, it returns an assertion failed which like this.

Assertion failed: (((ai_size)(ai_array_get_byte_size(((ai_array_format)(((ai_array*)(p_tensor_scratch->data))->format)), (((ai_array*)(p_tensor_scratch->data))->size)))) == scratch_size), function ai_layer_check_scratch_size, file layers.c, line 289.

To figure it out, I observe the intermediate output per layer following the guide "Platform Observer API" in the X-CUBE-AI Documentation.
And I find out that stm32ai generates the wrong size for the scratch data of one Conv2D layer.

屏幕截图 2024-04-08 160837.png屏幕截图 2024-04-08 160855.png

 

 

 

 

 

 

 

 

 

 

The correct shape should be (1, 63, 63, 64), but the generated scratch size is (1, 3, 63, 64).
Since the stm32ai is a blackbox, I cannot move on to find the real problem.
b.t.w. My device is mac m1, and I first find this problem when I run the command stm32ai validate -m squeezenetv1.1_128_tfs_int8.tflite -O ram.

1 ACCEPTED SOLUTION

Accepted Solutions
jean-michel.d
ST Employee

Hi ManuZhu,

Thanks for this feedback. I suppose that you use the 8.1 version of X-CUBE-AI. I have reproduced an issue with the "-O ram" and this model. I have not observed the assertion, however generated code seems effectively not correct. With X-CUBE-AI 9.0, validation is now OK with the "squeezenetv1.1_128_tfs_int8.tflite" model and -O ram option.

However,

  • First, is it possible to share your C-project (if simple test-case) to try to reproduce on my side your experimentation?
  • Secondly, in your analyze, you indicate through Netron the output tensor of the Conv2D operator (1x63x63x64), this is not the internal scrtach buffer which can be used by the c-implementation of the operator. Datatype, shape and/or shape of the requested scratch buffer are fully dependent of the generated implementation (or used c-kernel) but not from the original model.

Br,

Jean-Michel

View solution in original post

2 REPLIES 2
jean-michel.d
ST Employee

Hi ManuZhu,

Thanks for this feedback. I suppose that you use the 8.1 version of X-CUBE-AI. I have reproduced an issue with the "-O ram" and this model. I have not observed the assertion, however generated code seems effectively not correct. With X-CUBE-AI 9.0, validation is now OK with the "squeezenetv1.1_128_tfs_int8.tflite" model and -O ram option.

However,

  • First, is it possible to share your C-project (if simple test-case) to try to reproduce on my side your experimentation?
  • Secondly, in your analyze, you indicate through Netron the output tensor of the Conv2D operator (1x63x63x64), this is not the internal scrtach buffer which can be used by the c-implementation of the operator. Datatype, shape and/or shape of the requested scratch buffer are fully dependent of the generated implementation (or used c-kernel) but not from the original model.

Br,

Jean-Michel

Hi Jean-Michel

  1. "First, is it possible to share your C-project (if simple test-case) to try to reproduce on my side your experimentation?":I guess the error may only occur in macarm? I put the model file and validation data in the "files.tar"
  2. "Secondly, in your analyze, you indicate through Netron the output tensor of the Conv2D operator (1x63x63x64), this is not the internal scrtach buffer which can be used by the c-implementation of the operator. Datatype, shape and/or shape of the requested scratch buffer are fully dependent of the generated implementation (or used c-kernel) but not from the original model.": I think it's right because in both 8.1.0 and 9.0.0 the generated scratch size is (1, 3, 63, 64).