While following along on this guide (https://docs.edgeimpulse.com/docs/using-cubeai) to confirm ML model runs on an STM32WL, I cannot successfully build my project because of some undefined references to some forward declarations in trained_model_compiled.cpp, namely the ones shown here:
If I were to comment these declarations out, the project builds and runs, but the processor runs into a hard fault when it tries to call these undefined functions. So I think they need to be defined either somewhere in a missing part of the library (pack), or by myself. I think that the invalid project path warning may be the source of the issue, but I don’t know why that path ( \EI_SingleCPU_test\MachineLearning) was not generated during the import of the pack file, or during CubeMX’s code generation.
These are the boxes I’ve checked:
both CRC and the impulse are checked and activated in CubeMX
generated code from CubeMX
renamed main.c to main.cpp
confirmed it is a C++ project
this is a single core project, although it is a dual core board
I’ve attempted to follow this guide on a dual core project on the same board. When I did this, a separate “Middlewares” folder was generated, that I assume is meant for topmost hierarchical level (general project directory as opposed to the directories for the individual cores). For the dual core project, the “machine learning” folder appears under the CM4 directory, but that is not the case in a single core project, which still targets the same core (M4).
Has anyone from the community faced an issue similar to this or understand the tflite registration process? I’ve been struggling with this for too long and would like to move past it already.
Hi All, I have just followed again a similar process with our standard tutorial: https://studio.edgeimpulse.com/public/14299/latest and seeing a similar issue.
In my case I’m not seeing as many errors but it is probably the same issue.
Will check this with our team and let you know.
While we work out what’s going on with the PACK import, if you want a workaround, manually add all the files under this folder: edgeimpulse/edge-impulse-sdk/tensorflow/lite/micro/kernels/ to your project
Ok! The workaround allowed me to at least compile and run the impulse, so thank you!
I was confused because the only files that were in the folder @AlexE specified were header files, and they were already part of my project, so I wasn’t sure what you meant by “add all the files” under that folder.
I eventually compared directories between the C++ Library export and the CMSIS-pack export, and every source file (.cc) was missing. I added them to my project from the C++ Library export version. The tflite registration-related functions were now defined, however, I had 55 new errors. After further investigation I found that, in fact, for every subdirectory under edgeimpulse/edge-impulse-sdk/tensorflow/lite/, every source file was omitted by the CMSIS-Pack export. I manually added the rest from the C++ Library version, and now the project finally runs, albeit, with very poor performance. It’s taking 17000 ms to run DSP and 10000 ms to make the inference (This is only 8-bit, 8kHz sampled audio).
Is there a CMSIS related optimization that I’m missing out on by using the C++ source files? Or is everything under edgeimpulse/edge-impulse-sdk/tensorflow/lite/ identical among C++ and CMSIS versions?
Good afternoon to everyone!
I’m facing the same problem about:
undefined reference tflite::Register_FULLY_CONNECTED()
undefined reference to tflite::Register_SOFTMAX()
I hope that a solution would be find out for!
Anyway i’m not understanding your workaround @Markrubianes may you explain better? Do I need to include paths on project properties -> path and symbols on c++ general settings?
This is what I did at least (because I didn’t know where else to get the files from):
Go to the deployment page of your project and export as C++ library instead of Cube MX CMSIS-PACK
Unzip and navigate to edgeimpulse/edge-impulse-sdk/tensorflow/lite/
From there, go into each subdirectory (c, core/api, kernels, kernels/internal, micro, micro/kernels, micro/memory_planner) and take note of which folders contain .cc files
Find each corresponding directory in your STMCube IDE project, and manually import each missing .cc file into their appropriate location
My project initially looked like this with no source files:
@Markrubianes can you open another thread about your performance issues? And tag me there please, so I get a notification when you post. I’ll see if I can give some recommendations
When you make the new post, can you screenshot or type out the params you’re using for your DSP block? (FFT size, etc)
Hi @Markrubianes@Mj42@Ago11 and others, so the underlying issue is that .cc files are no longer actually being linked into the project, even though they are in the CMSIS-PACK. Sounds like a regression in STM32CubeIDE…
Anyway, we’re now renaming all .cc files to .cpp before generating the pack, and this imports fine again. This will be pushed to production either today or tomorrow, so from then on your packs will work again
I haven’t had a chance to confirm it works yet, but thank you for uncovering this! Given my target processor is Cortex M4, is there any performance to gain from using the CMSIS-PACK export (such as extended instruction set optimizations) as opposed to exporting as a C++ library? Or am I thinking about it too hard and I’m getting identical object code from either export?
