9. Device Deployment
This section guides you through deploying trained models on TI microcontrollers using Code Composer Studio (CCS).
Contents
- 9.1. CCS Integration Guide
- 9.1.1. Prerequisites
- 9.1.2. Compilation Output
- 9.1.3. Creating a CCS Project
- 9.1.4. Integration Code
- 9.1.5. Memory Placement
- 9.1.6. Linker Command File
- 9.1.7. Interrupt-Based Inference
- 9.1.8. Timing and Profiling
- 9.1.9. Debugging
- 9.1.10. Build Configurations
- 9.1.11. Example Project Structure
- 9.1.12. Common Issues
- 9.1.13. Testing on Hardware
- 9.1.14. Next Steps
- 9.2. NPU Device Deployment
- 9.2.1. NPU-Enabled Devices
- 9.2.2. NPU Compilation
- 9.2.3. NPU Model Requirements
- 9.2.4. NPU Compilation Artifacts
- 9.2.5. NPU Initialization
- 9.2.6. NPU Inference Code
- 9.2.7. NPU Memory Management
- 9.2.8. NPU Performance
- 9.2.9. NPU Power Considerations
- 9.2.10. NPU Debugging
- 9.2.11. NPU Error Handling
- 9.2.12. CCS Project Setup for NPU
- 9.2.13. Example: Arc Fault on F28P55 NPU
- 9.2.14. Troubleshooting NPU Issues
- 9.2.15. CCS Studio Walkthrough: F28P55x
- 9.2.16. Required Files from ModelMaker
- 9.2.17. Model Performance Profiling
- 9.2.18. Next Steps
- 9.3. Non-NPU Deployment
- 9.3.1. Non-NPU Devices
- 9.3.2. Configuration
- 9.3.3. Model Selection
- 9.3.4. CPU Inference Performance
- 9.3.5. Compilation Artifacts
- 9.3.6. CCS Project Setup
- 9.3.7. Basic Integration
- 9.3.8. Optimizing CPU Inference
- 9.3.9. Memory Optimization
- 9.3.10. Power Optimization
- 9.3.11. Real-Time Considerations
- 9.3.12. Device-Specific Notes
- 9.3.13. Example: Vibration Monitoring on MSPM0G3507
- 9.3.14. CCS Studio Walkthrough: F28004x
- 9.3.15. Required Files from ModelMaker
- 9.3.16. Comparison: NPU vs Non-NPU
- 9.3.17. Next Steps
9.4. Supported Devices
Device-Specific SDKs
Device Family |
Devices |
SDK |
SDK Version |
Download |
|---|---|---|---|---|
C2000 (F28x) |
F28003x, F28004x, F28P55x, F28P65x |
C2000Ware |
6.01.00.00 |
|
C2000 (F29x) |
F29H85x, F29P58x, F29P32x |
F29H85X SDK |
01.04.00.00 |
|
MSPM33 |
MSPM33C321Ax |
MSPM33 SDK |
1.03.00.00 |
|
Sitara MCU (AM13x) |
AM13E2x |
MCU SDK |
1.00.00.00 |
|
Sitara MCU (AM26x) |
AM263, AM263P, AM261 |
MCU-PLUS-SDK |
11.03.00.00 |
|
Connectivity |
CC2755, CC1352, CC1354, CC35X1 |
SimpleLink SDK |
– |
Supported LaunchPads/EVMs
Device |
LaunchPad/EVM |
Product Page |
NPU |
|---|---|---|---|
F28003x |
No |
||
F28004x |
No |
||
F28P55x |
Yes |
||
F28P65x |
No |
||
F29H85x |
No |
||
MSPM33C321Ax |
No |
||
AM13E2x |
– |
Yes |
|
AM263x |
No |
||
CC2755 |
– |
No |
|
CC1352 |
– |
No |
|
CC1354 |
– |
No |
|
CC35X1 |
– |
No |
9.5. Deployment Overview
After training and compilation, Tiny ML Tensorlab produces artifacts that you can integrate into your CCS project:
Output Artifacts
File |
Description |
|---|---|
|
Compiled model library (ONNX model compiled by TI MCU NNC into C code, packaged as a static library) |
|
Header file with model inference API exposed by |
|
Golden test vectors (input + expected output) for on-device validation |
|
Feature extraction configuration (preprocessing flags and parameters) |
Deployment Steps
Train and compile your model using Tiny ML Tensorlab
Open Code Composer Studio
Import the SDK example project for your target device and task type
Copy the four output files from ModelMaker to the CCS project
Build, flash, and debug
The specific steps vary depending on whether your device has an NPU:
NPU Device Deployment - For F28P55x, AM13E2x, MSPM0G5187
Non-NPU Deployment - For all other devices
9.6. Prerequisites
Code Composer Studio (CCS)
Download from https://www.ti.com/tool/CCSTUDIO. Version 20.2.0 or later is recommended.
Install support for your target device family during CCS setup, and then install the appropriate SDK listed in the Supported Devices table above.
9.7. Output File Locations
After ModelMaker runs, the four deployment files are located in:
tinyml-modelmaker/data/projects/{dataset_name}/run/{date-time}/{model_name}/
├── compilation/
│ └── artifacts/
│ ├── mod.a <-- Compiled model
│ └── tvmgen_default.h <-- Model API header
│
└── training/
├── base/ <-- For float (non-quantized) models
│ └── golden_vectors/
│ ├── test_vector.c
│ └── user_input_config.h
│
└── quantization/ <-- For quantized models
└── golden_vectors/
├── test_vector.c
└── user_input_config.h
Important
Choose the golden vectors based on the model type you compiled:
Float model (non-quantized): Use golden vectors from
training/base/golden_vectors/Quantized model: Use golden vectors from
training/quantization/golden_vectors/
The mod.a and tvmgen_default.h are always from
compilation/artifacts/ regardless of quantization setting.
9.8. CCS Example Project Locations
TI provides ready-to-use CCS example projects for each task type. The example project location depends on your device family:
C2000Ware (F28x devices):
{C2000WARE_INSTALL_PATH}/libraries/ai/examples/
├── generic_timeseries_classification/
├── generic_timeseries_regression/
├── generic_timeseries_forecasting/
└── generic_timeseries_anomalydetection/
F29H85X SDK (F29x devices):
{F29H85X_SDK_INSTALL_PATH}/examples/rtlibs/ai/examples/
├── generic_timeseries_classification/
├── generic_timeseries_regression/
├── generic_timeseries_forecasting/
└── generic_timeseries_anomalydetection/
Inside each task-type folder, select the subfolder matching your target device
(e.g., f28p55x/, f28004x/, f29h85x/).
9.9. Task-Type-Specific Deployment Notes
The deployment workflow is the same for all task types, but the CCS example project names and verification differ:
Classification
CCS example:
generic_timeseries_classificationVerification: Check
test_resultvariable (1 = pass, 0 = fail)The model outputs class scores;
argmaxgives the predicted class
Regression
CCS example:
generic_timeseries_regressionVerification: Check
test_resultvariable (1 = pass, 0 = fail)The model outputs a continuous value
Forecasting
CCS example:
generic_timeseries_forecastingVerification: Check
test_resultvariable (1 = pass, 0 = fail)The model predicts future values from historical data
Anomaly Detection
CCS example:
generic_timeseries_anomalydetectionVerification: The application computes reconstruction error (MSE between input and autoencoder output) and compares to a threshold
In
user_input_config.h, the anomaly threshold is defined:#define RECONSTRUCTION_ERROR_THRESHOLD 0.014 // Threshold for k=4.5
This was calculated during training as:
threshold = mean_normal_error + k * std_normal_errorAdjusting the threshold:
Increase threshold (higher k): fewer false alarms, may miss subtle anomalies
Decrease threshold (lower k): catches more anomalies, more false alarms
Refer to the
threshold_performance.csvfile from ModelMaker to choose the optimal k value for your application.
9.10. Testing Multiple Cases
The test_vector.c file contains multiple test cases (SET 0, SET 1, etc.).
To test different cases:
Open
test_vector.cin the CCS editorComment out the current test set (SET 0)
Uncomment another test set (e.g., SET 1)
Rebuild and reflash the project
Verify that
test_resultmatches expected output
9.11. Model Compilation Details
The ONNX model produced by training is compiled using
TI MCU NNC
to generate mod.a and tvmgen_default.h. The compilation command
used internally is:
tvmc compile \
--target="c, ti-npu type=hard skip_normalize=true output_int=true" \
--target-c-mcpu=c28 \
./model.onnx \
-o artifacts_c28/mod.a \
--cross-compiler="cl2000" \
--cross-compiler-options="$CL2000_OPTIONS"
Different task types use different compilation flags:
Classification:
skip_normalize=true output_int=trueRegression/Forecasting: Output is float (no
output_int)Anomaly Detection: Output is reconstruction error
See the TI MCU NNC documentation for all compilation options.