Inspiration
My background is in electrical engineering, with a focus on power electronics, motor drives, converters, and real-time control systems. These systems execute control loops at tens of kilohertz on resource-constrained microcontrollers, where deterministic timing and efficiency are critical.
After transitioning into machine learning, I was struck by the separation between control and AI in industrial systems. Motor controllers continuously collect high-quality signals such as phase currents, voltages, and vibration data, yet predictive-maintenance algorithms are typically deployed on gateways, edge computers, or cloud infrastructure rather than on the controller itself.
This raised a straightforward engineering question: if the controller already has access to the necessary data and available compute resources, why shouldn't the predictive-maintenance model execute on the same microcontroller alongside the control algorithm?
That question became the motivation for this project. The objective was to design a fault-detection model that is small enough, fast enough, and efficient enough to run alongside a real-time motor controller on a single embedded microcontroller, and to validate its performance through measurements on real Arm hardware rather than theoretical estimates.
What it does
The implementation targets the Infineon PSOC™ Control C3M5, an Arm Cortex-M33 microcontroller running at 180 MHz, representative of the class of processors commonly used in industrial motor-control applications. The complete fault-detection pipeline executes entirely on the microcontroller:
$$\text{raw ADC window} \;\rightarrow\; \text{FFT features} \;\rightarrow\; \text{INT8 classify} \;\rightarrow\; \text{fault alert}$$
The system performs bearing-fault classification from vibration data using the Case Western Reserve University (CWRU) dataset (10 fault classes), with all signal processing and inference performed on-device.
A key focus of the project is the systematic optimization of the embedded ML pipeline. Instead of evaluating only the final implementation, each optimization stage was measured independently using the Arm Cortex-M Data Watchpoint and Trace (DWT) cycle counter to obtain cycle-accurate performance measurements.
Neural network inference: The model was optimized from an FP32 TensorFlow Lite Micro baseline to an INT8 implementation, followed by acceleration using CMSIS-NN. This reduced inference cost to 83,414 cycles (463 μs) — a 1.68× reduction versus the FP32 baseline (140,437 cycles / 780 μs). Naive INT8 without CMSIS-NN was actually slower than FP32 (179,889 cycles / 999 μs, 1.28× slower) — CMSIS-NN is what makes INT8 a net win, at 2.16× faster than naive INT8. Quantization also shrank the model from 72,236 B to 24,152 B — a 3× reduction, freeing 48,084 B of flash for the same accuracy (0.00 pp drop).
Feature extraction: The original custom C FFT implementation was replaced with the optimized CMSIS-DSP
arm_rfft_fast_f32routine. This reduced feature-extraction time to 110,693 cycles (614 μs), a 3.0× speedup over the plain-C FFT (334,213 cycles / 1,856 μs).End-to-end pipeline: Combining the inference and DSP optimizations reduced the complete sensor-to-decision latency from approximately 2,327 μs to 1,086 μs, an overall 2.1× improvement, while keeping the entire pipeline on-chip.
Fits alongside real-time control: A typical motor-control loop ticks every few tens of µs (tens of kHz). The full detection pipeline needs 1.086 ms of CPU, but only once per 42.7 ms window. So it can run as a low-priority background task without claiming a dedicated processor. For example, spreading the 1.086 ms inference workload across 50 ticks of a 20 kHz control loop (50 μs/tick) needs only ~21.7 μs (43%) per tick, finishing in 2.5 ms — well inside the 42.7 ms window — and leaving ~28 μs/tick for the controller.
To validate real-time operation, a live demonstration system was developed that streams a continuous 12-bit ADC sample stream to the board in 512-sample windows, replicating a typical ADC + DMA acquisition flow. The microcontroller performs windowing, FFT feature extraction, classification, and fault-alert generation locally, without relying on external processors, gateways, or cloud resources.
How I built it
Model development and validation
I developed and validated the model on a laptop before deploying it to the target hardware. Vibration recordings from the CWRU bearing dataset (10 fault classes, using only the drive-end channel) were quantized to 12-bit signed integer values with a fixed full-scale range, matching the format expected from the chip’s ADC. This ensured that the training data accurately represented the conditions of real-time inference.
Each recording was split chronologically into training and test sets using a 70/30 split. Any window crossing the split boundary was discarded to prevent data leakage between the two sets. Each input window was transformed using an FFT to extract frequency-domain features, producing 128 input values per sample.
A compact fully connected neural network architecture (128 → 96 → 48 → 10) was trained using TensorFlow/Keras. The trained model was then converted into a fully integer INT8 model using TensorFlow Lite post-training quantization, with calibration performed on representative samples from the training dataset.
Embedded deployment
Because no existing TensorFlow Lite Micro implementation was available for this target platform, I built the embedded runtime integration from source. The deployment combined TensorFlow Lite Micro with CMSIS-NN, Arm’s optimized neural-network kernels for Cortex-M processors, and CMSIS-DSP, which was used for efficient FFT computation.
The application was integrated into an Infineon ModusToolbox project and compiled using arm-none-eabi-gcc. To meet the device memory constraints, I carefully controlled build dependencies and reduced the included CMSIS-DSP components to only the lookup tables required for the 1024-point FFT. This allowed the complete application to fit within the device’s 256 KB flash memory limit.
Performance measurement and optimization
To evaluate performance at each stage, I used the Cortex-M DWT cycle counter to measure execution time at CPU-cycle resolution.
I created an optimization ladder by evaluating multiple configurations:
- FP32 reference kernels
- INT8 reference kernels
- INT8 kernels accelerated with CMSIS-NN
- Standard C FFT implementation
- CMSIS-DSP optimized FFT implementation
The complete signal-processing pipeline was implemented directly on the embedded device, including windowing, FFT computation, logarithmic scaling, and normalization. The embedded feature extraction results were compared against the Python reference pipeline sample-by-sample, achieving agreement within approximately one part per million.
Real-time demonstration
For the live demonstration, I established a UART connection between a laptop and the embedded board. A Python script streams raw vibration recordings as 12-bit ADC samples in continuous 512-sample blocks, replicating the data flow expected from an ADC and DMA-based acquisition system.
The device maintains a sliding 1024-sample input window and continuously executes the full inference pipeline:
- FFT-based feature extraction
- INT8 neural-network inference
- Fault classification
- Alert state management
The alert logic includes temporal filtering to reduce false triggers. A fault condition must be detected multiple consecutive times before activating an alert, and the alert is only cleared after multiple consecutive normal readings. The final classification result is reported in real time.
Challenges I ran into
Several technical challenges were encountered during the development and deployment of the embedded ML pipeline.
Lack of Existing AI Support for the Target Platform
The Infineon PSOC™ Control C3M5 does not currently have a dedicated AI deployment toolkit or reference implementation for this specific use case. Although related devices in the family provide AI support, no existing example could be directly adapted. As a result, the complete workflow — including model deployment, optimization, and integration with the embedded application — had to be developed from the ground up.
Build System and Dependency Management Issues
The initial development process exposed several challenges with the embedded build environment. The build system automatically included additional source directories and test files that introduced compilation conflicts. Resolving these issues required explicit control over source inclusion and project configuration to ensure that only the required components were compiled.
Memory Optimization Constraints
The target device provides 256 KB of flash memory, making memory optimization a critical design constraint. During optimization, the integration of an optimized FFT implementation introduced additional lookup tables that exceeded available flash capacity by approximately 21 KB. The implementation was refined by removing unused tables and retaining only the resources required for the deployed FFT configuration.
Preventing Data Leakage During Evaluation
An initial train/test split allowed the possibility of overlapping samples between training and evaluation data, which could artificially inflate performance. The dataset split was redesigned to ensure complete separation between training and testing samples, providing a more reliable measure of model generalization.
Accomplishments that I am proud of
Developed the first working TensorFlow Lite Micro + CMSIS-NN integration for the PSOC™ Control C3M5.
Since no reference implementation existed for this device, the complete toolchain integration was developed from the ground up, creating a reusable foundation for future embedded ML applications on this platform.Implemented a complete, cycle-accurate optimization pipeline.
The project evaluated FP32 → INT8 → INT8 + CMSIS-NN for inference (1.68× over FP32; naive INT8 alone was 1.28× slower) and a custom C FFT vs. CMSIS-DSP for feature extraction (3.0×). All figures were measured directly with the Cortex-M DWT cycle counter, not estimated.Identified and documented an important embedded ML performance trade-off.
The initial INT8 implementation was slower than the FP32 version on this FPU-equipped microcontroller. Rather than treating this as a failure, the result was analyzed and reported as an example of why embedded ML optimizations must be validated on the target hardware.Achieved a fully on-chip fault-detection pipeline.
The system processes raw ADC samples and produces fault decisions entirely on the microcontroller, with no dependency on external gateways, servers, or cloud processing.Developed a realistic real-time demonstration system.
The final demo streams raw 12-bit ADC samples in continuous 512-sample windows, requiring the board to perform the complete processing chain — acquisition, windowing, FFT extraction, classification, and alert generation — in real time.Validated the feasibility of running ML alongside motor-control workloads.
The full on-chip pipeline completes in ~1.09 ms — small enough to run alongside a motor-control loop as a background task, sharing the same silicon without requiring a second processor.
What I learned
Embedded ML performance must be measured on the target hardware.
Optimization techniques that improve performance on desktop-class systems do not always translate to microcontrollers. For example, quantization alone can introduce overhead if the hardware does not efficiently accelerate the resulting operations.Embedded AI deployment requires understanding the complete software stack.
TensorFlow Lite Micro defines the model execution framework, while libraries such as CMSIS-NN and CMSIS-DSP provide hardware-specific optimizations. Achieving efficient deployment requires understanding both the ML model and the underlying embedded implementation.Developing embedded ML systems requires both ML and embedded expertise.
The project provided practical experience in model quantization, dataset preparation, prevention of data leakage, and accurate reporting of model performance and limitations.
What's next for Motor predictive maintenance on the control chip itself
Validate the system on a physical motor test platform.
The next step is to deploy the system on a real motor with an accelerometer, allowing the motor-control loop and fault-detection pipeline to run simultaneously on the same microcontroller.Evaluate performance on Arm Corstone-300.
A comparison with the Corstone-300 platform, which includes an integrated NPU for AI acceleration, will provide insight into how the same workload scales to more capable embedded AI hardware.Evaluate ExecuTorch as an alternative deployment framework.
The Cortex-M backend will be explored as another runtime option using CMSIS-NN acceleration, comparing both performance and development workflow.Further reduce model size and resource usage.
Additional optimization techniques, including pruning and feature reduction, will be investigated to reduce flash and RAM usage while leaving more resources available for the motor-control application.Train and test on a second, independent bearing-fault dataset.
The current results are validated only on CWRU. Repeating the training and evaluation pipeline on a different public bearing-fault dataset would test whether the approach generalizes beyond one lab's recording setup, rather than being tuned to CWRU's specific sensors and conditions.Release the toolchain integration as a documented template.
The completed TensorFlow Lite Micro and CMSIS-NN port will be packaged as a reusable reference project to simplify future embedded ML development on the PSOC™ Control C3 family.
Log in or sign up for Devpost to join the conversation.