How to replace the USC network in the Dual-mode application for STEVAL-STWINBX1

[dzf]

Hi, 

I’m developing a voice-control system on ST’s STEVAL-STWINBX1 evaluation board. I’d like to build on the original “Dual-mode application with STM32Cube.AI and NanoEdge™ AI” by replacing the anomaly-detection function with a binary classifier based on IMP23ABSU microphone data (“xiaobei” vs. “other”). I also plan to replace the original USC model with a 10-class classification model trained on IMP23ABSU microphone data. The intended behavior is: when the MCU recognizes “xiaobei,” it should wake the USC model; otherwise, it should not.

My NanoEdge™ AI binary model is already running—when I execute start neai_class, I can see the classification output. However, after “xiaobei” is detected, the USC model fails to wake up and the firmware even falls into HardFault_Handler in some cases. I’m not sure what’s going wrong. Could you please share suggestions? For example, after modifying the USC model parameters, which source files need to be updated so the new model is compatible with the original code? Thank you!

zefang

[JennyMods]

Hi Zefang,

Your issue likely stems from inconsistencies between the modified USC model and the integration layer that manages inference triggering in the Dual-mode firmware. When you replace the original USC model with a new 10-class classifier, several dependencies must be updated to ensure proper model loading and memory alignment.

Here’s a step-by-step approach to resolve the issue:

1. Update Model Parameters:
   Ensure that the usc_net.c and usc_net.h files reflect the new model’s structure — input size, output classes, and tensor dimensions. If you generated the model using STM32Cube.AI, re-export the C files and replace the old ones completely.

2. Adjust Inference Management:
   In the dual-mode example, the app_x-cube-ai.c or app_neai.c files handle switching between the NanoEdge AI and the USC model. You need to modify the logic that triggers the USC inference to ensure it only runs after your “xiaobei” event. Add checks to confirm that memory buffers and model handlers are properly initialized before calling ai_run().

3. Memory and Stack Configuration:
   A HardFault can indicate a memory overflow or misaligned pointer. Verify that the .bss, heap, and stack sizes in your linker script (STM32xxxx_FLASH.ld) are sufficient for both models to coexist. If needed, increase HEAP_SIZE or STACK_SIZE.

4. Reinitialize AI Networks Properly:
   When switching from the NanoEdge AI model to the USC model, always call ai_network_destroy() before reinitializing another network to avoid overlapping memory contexts.

5. Check Interrupt and DMA Conflicts:
   Since you’re using the IMP23ABSU microphone, confirm that DMA and I2S/DFSDM channels aren’t interrupted by concurrent tasks when switching modes.

6. Debugging Tip:
   Use STM32CubeIDE’s debugger to check the call stack when HardFault occurs — it often points directly to the function (like ai_run() or a buffer operation) that’s misbehaving.

If the problem persists after updating these files, consider running both models independently in isolation first to confirm that each works before integrating them into the dual-mode framework.