Assistance Needed with Edge Impulse Inference on STMicroelectronics B-L475E-IOT01A Board

[Hcelle]

Hi, I am reaching out for assistance with a project I am working on, specifically related to implementing Edge Impulse voice control on the STMicroelectronics B-L475E-IOT01A board.

Following the Cube.MX CMSIS-PACK tutorial (Cube.MX CMSIS-PACK | Edge Impulse Documentation), I have successfully compiled the code, and everything appears to be functioning correctly. However, I am encountering discrepancies in the inference results. Despite utilizing raw data that was correctly classified within Edge Impulse, the inference results on the board differ significantly.

I am perplexed by this inconsistency and am seeking guidance to identify the root cause of this error. Could you please provide assistance in troubleshooting this issue?

Here is the link to my Edge Impulse project: Voice_control - Dashboard - Edge Impulse
Here is the link to my STM32 project: GitHub - Brighttttttttt/Voice_control

Your expertise and guidance in resolving this matter would be greatly appreciated.

Thank you for your attention to this matter.

Warm regards,

Hugo

[shawn_edgeimpulse]

Hi @Hcelle,

Did you deploy as a float or int8 quantized model? That can make a difference. The “Model testing” section in Studio will display results using the floating point version of the model.

[Hcelle]

Hi @shawn_edgeimpulse,

Thank you for your response.

I have tried both options, but unfortunately, neither of them seems to be working for me. I have conducted more tests on my end:

1. I successfully deployed the Tutorial: continuous motion recognition using Cube.MX CMSIS-PACK on my STMicroelectronics B-L475E-IOT02A board. The model works well when quantized as either float or int8.

2. I also deployed the Tutorial: responding to your voice using Cube.MX CMSIS-PACK on the same STMicroelectronics B-L475E-IOT02A board. However, I encountered the same issue that I described in my initial post.

Following these attempts, I have a hunch that there might be an issue with the MFCC block. Upon examining the output of the MFCC block, I noticed that the Processed features do not seem to align with what we would expect from the set of Raw features provided as input. This inconsistency is leading me to suspect that there might be an underlying problem with the MFCC block’s functionality in my project or before this bloc.

Input Raw features in my B-L475E-IOT02A board :

Raw features and Processed features in Edge Impulse :

Processed features in my B-L475E-IOT02A board :

Thank you for your assistance.

[shawn_edgeimpulse]

Hi @Hcelle,

I chatted with our engineering team. It seems that the CubeMX deployment option may be deprecated soon, and we recommend using the Open CMSIS pack as the preferred deployment option. Could you try that?

[Hcelle]

Hi @shawn_edgeimpulse,

Thanks for your answer.
I will try this, have you tutorial or documentation to implement the Open CMSIS pack in stm32cube ide ?

[shawn_edgeimpulse]

Hi @Hcelle,

Here is the documentation on using Open CMSIS: Embedded IDEs - Open-CMSIS | Edge Impulse Documentation

[Hcelle]

Hello @shawn_edgeimpulse,

I’ve conducted additional tests on my end, and here are the results:

Project\Deployment	Cube.MX CMSIS-PACK	Open CMSIS pack	ST IoT Discovery Kit (.bin)
Motion recognition	Works	Works	Works
Responding to your voice	Doesn’t Work	Doesn’t Work	Works

Both deployments labeled as “not working” were attempted using Cube.MX CMSIS-PACK or Open CMSIS pack for the voice recognition project. I encountered the same problem as with the Cube.MX CMSIS-PACK deployment, as described in my second post.

For the Open CMSIS pack, I used CMSIS v5.9.0, CMSIS-DSP v1.15.0, CMSIS-NN v4.0.0, and EI-SDK v1.49.4. Can you confirm if these are the correct versions?

Additionally, I noticed 10 warnings each time during the deployment of all projects in the EI-SDK. I will further investigate these 10 warnings. It’s possible that the Motion recognition project doesn’t utilize the functions associated with these warnings, which might explain why it works while the Voice recognition project doesn’t.

Thank you for your attention to this matter.

[AlexeyKr]

I confirm the problem, I’ve been suffering for a week now. CUBE.MX CMSIS-PACK not working on NUCLEO STM32F767ZI, i can compile it but features wrong after dsp. and when i use float instead Q8 NN time on 200Mhz CortexM7 is 485ms!!! BUT the same project compiled for arduino XIAO NRF52 NN around 50 ms (Cortex M4 - 64Mhz). I haven’t tried it yet OPEN CMSIS on STM32F767.

[ei_francesco]

Hi @Hcelle

Yeah the versions are ok.
I’ll check if there is anything wrong with the MFCC block, thank you for the report!

regards,
fv

[AlexeyKr]

Plese check MFE block too.

[ei_francesco]

I tested on Arm Virtual Hardware and the results are correct.

I’ll check with a Nucleo F446RE (a Cortex-M4 with FPU and DSP) and let you know.

[Hcelle]

Hi @ei_francesco,

Thanks for your answer.
I get a new stm32 card, I will try with it.
I wait the results of your test with a nucleo !

[ei_francesco]

Hi @Hcelle

I have tested the helloworld kws with my Nucelo and is working as expected.

I also tested your model with the same Nucelo using this project GitHub - edgeimpulse/example-standalone-inferencing-st-nucleo-f466re: Static inferencing with Nucleo F466RE using Keil MDK (for uvision) and so far so good, I’m getting the expected label.

Off

On

Noise

You built the in8 version of the model ?
Edit: I saw you tried both.

I’ll try to have a quick look at your code.

@AlexeyKr which project are you using ? can you share the id ?

fv

[J.Hogendoorn]

Hi @ei_francesco

Did you use a CMSIS-PACK or a C++ library when testing?

I have the same problem as Hcelle. I have a keyword spotting model that I want to get working on an -L475-IOT01A1. The model works perfectly on an Arduino Nano 33 BLE Sense. But if I run it on the B-L475-IOT01A1 using a CMSIS-PACK or C++ library, it does not work. I do this in the STM32CubeIDE environment. I get an ‘unknown’ back as the highest prediction when I put the data from sample ‘yes’ in it.

I also tried this several times on a NUCLEO-L452RE-P (with a CMSIS-PACK). But this also gives the wrong predictions. The same predictions as the B-L475-IOT01A1.

Now I have been able to get the Arduino library working on the B-L475-IOT01A1 using PlatformIO. So this is completely run by Arduino code. I am now getting the correct predictions back. For this I used the same sample data that I used in STM32CubeIDE.

But I have discovered a difference between the outputs. With the Arduino variant I see different output values ​​than with the CMSIS-PACK while I use the same sample data. Is something going wrong in the code I am using?
Both codes: https://github.com/JohanHogendoorn/Edge-Impulse-Audio/tree/main

Kind regards,

Johan

Project ID: 346567

[ei_francesco]

I used the CMSIS-pack, using Keil uVision and the new cmsis-toolbox from Arm GitHub - Open-CMSIS-Pack/cmsis-toolbox: CMSIS-Toolbox.

@J.Hogendoorn the repo is private.

I haven’t tried using Cube, that seems the IDE everybody is using with this issue - I’ll focus on Cube.
If the output is different, the DSP is returning different results, why idk, need to check. I saw something similar in the past, it was a problem of the math.h used.

Which Arm-GCC version are you using ? I tested with 10.3.

[J.Hogendoorn]

I was able to get it working by using another GCC version. I downloaded and tried several versions in STM32CubeIDE.

The version ‘GNU Tools for STM32(9-2020-q2-update)’ worked well for me! The other versions I tried didn’t work.

I now get the correct prediction back:

@ei_francesco Thanks for your help!

For the people who had the same problem in STM32CubeIDE. You can install the GNU version:

“Window” → “Preferences” → “”STM32Cube” → “Toolchain Manager”

There you can click on the version and press install. After installation, set the GNU to default (press ‘Set Default’). Hopefully it will now work for others too

[ei_francesco]

Thank you @J.Hogendoorn !

On my test I used GCC 10.3 with cmsis toolbox and uvision with Arm compiler 6.19.
I’ll test GCC 11.3.1 with cube ide and cmsis toolbox.

fv

[Hcelle]

Hi all,

Thank you all for your help.
I just tested it in stm32cubeIDE with the Cube.MX CMSIS-PACK and it’s works on my side too !!!
I used the ‘GNU Tools for STM32(9-2020-q2-update)’.
And in stm32cubeIDE the Cube.MX CMSIS-PACK doesn’t work with versions :

• GNU Tools for STM32(10.3-2021.10)
• GNU Tools for STM32(12.3.rel1)

Thanks again for your help!

Kind regards,

Hugo

[swalderi]

Hey everyone,

I had the same frustrating issue, and I think I’ve found the underlying problem after debugging deep into the Edge Impulse SDK.

The core issue is a risky speed optimization hack in the log function inside numpy.hpp. Newer GCC compilers (like the 13.3.rel1 I use for my Cortex-M7) compile this hack incorrectly for the FPU, leading to corrupted results in the DSP blocks (like MFE).

Essentially, the MFE frequency buckets were being calculated based on wrong logarithm values. My classifier couldn’t recognize the truncated spectrum values and always interpreted them as my background class.

Quick Test to Confirm the Bug

You can verify this in 5 minutes with a minimal test:

#include "edge-impulse-sdk/dsp/numpy.hpp"
printf("log(2.7)=%f\r\n", numpy::log(2.7));

This should correctly return log(2.7)=0.993252. If you see a vastly different, wrong number (like 3.386...), you have this problem.

The Clean Code Fix (No GCC Downgrade Needed)

The fastest and most stable fix is to simply replace the unsafe hack with the standard, safe C function logf().

1. Open the file .../edge-impulse-sdk/dsp/numpy.hpp
2. Find the log function and replace its contents with this code

    __attribute__((always_inline)) static inline float log(float a)
    {
    	return logf(a);
    }

This completely fixed the issue for me. Since log is only called once per MFE filter, I highly doubt the minor performance difference will be noticeable on modern cores.

Hope this saves you the hours I spent debugging!

[ei_francesco]

thank you for your finding @swalderi !