FRDM Training Hub

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

FRDM Training Hub

FRDM Training Hub


Restricted Beta Program

  • Comprehensive software and tools for seamless prototyping and rapid development
  • Scale your project with modular, quick-start FRDM and expansion boards
  • Leverage our application code hub or GoPoint to access 180+ code snippets and demos

  • Leverage FRDM Training Hub to learn from the experts
  • Not sure where to start ?

Discussions

Sort by:
Whether you're a student, hobbyist, or professional developer, the FRDM Development Platform by NXP is your gateway to building powerful embedded applications—quickly and affordably. In this beginner-friendly guide, you’ll learn: What FRDM boards are and how they compare to other NXP evaluation kits Who the platform is designed for How to buy and get started with your first board What’s new in the latest FRDM series featuring MCX microcontrollers and i.MX processors How the FRDM ecosystem supports your development with modular hardware, software tools, and ready-to-use code examples
View full article
FRDM Training and Resources This article provide a guide of available resources for FRDM Development boards to help you to find and use available resources (Boards, Guides, Hands-On Trainings and more)
View full article
Getting Started Video:   This guide provides step-by-step instructions on how to verify successful communication with the Ara240 module and the runtime software environment to interface  with the FRDM i.MX 95 development board.   Out of the Box   Get Familiar with the Ara240 Module   Ara240 Module [Top view] Ara240 Module [Back view]                Connecting the M.2 Module   This section explains how to connect Ara240, a discrete module, to the FRDM i.MX 95 development board. The instructions in the FRDM i.MX 95 Quick Start Guide will walk you through the boot-up process for the pre-loaded Embedded Linux image on the board and how to connect the USB debug cable. For additional details, see the official FRDM i.MX 95 Development Board documentation. References: FRDM i.MX 95 Quick Start Guide FRDM i.MX 95 Development Board product page FRDM i.MX 95 getting started page Getting Started with ARA2-M2-16G-GT Follow the steps below to connect the Ara240 module to the FRDM i.MX 95 development board: Important: Ensure the board is powered off before making any connections. Insert the Ara240 module into the M.2 Key-M socket on the FRDM i.MX 95 development board. Using the screw provided, secure the module. Connect the fan cable to the board’s fan header (refer to the FRDM i.MX 95 board documentation for the exact header location). Connect the Ara240 to the FRDM i.MX 95 development board.     Power on the Board   Follow the instructions to power on (boot) the board found in the Getting Started with FRDM-IMX95. After powering on, verify that the fan and green LED indicators Ara240 module are on are on.   Get the Software   This section will walk you through the Ara240 Runtime software development kit (SDK), a streamlined subset of the Ara240 SDK designed for rapid enablement and execution on NXP platforms. The Runtime SDK simplifies installation and configuration, enabling developers to quickly deploy and run AI/ML workloads on the Ara240 module with minimal effort. Overview   Refer to Ara240 software release notes for details on the Ara240 software development kit (SDK) The Getting Started page for Ara240 only outlines usage on specific i.MX development platforms For any other platforms please reach out to your NXP representative for guidance.   Module Enumeration and Software Configuration   This section provides instructions to verify proper installation of Ara240 module and configuration of the Ara240 Runtime SDK on the FRDM i.MX 95 development board. Verify Device Detection   Once the board has successfully booted, connect to the serial debug port to monitor system logs. To confirm that the Ara240 module is being detected by the board, run the following command: $ lspci | grep 1e58   Expected output: 0000:01:00.0 Processing accelerators: Device 1e58:0002 (rev 02)   Enable Ara240 device   For quick enablement, the Ara240 Runtime SDK starts at boot time. Refer to the Ara240 Runtime SDK documentation for detailed instructions and environment setup steps.   Developer Experience   This section provides an overview of Ara240 runtime software enablement using the FRDM i.MX 95 development board. Verify Setup Environment   Use the following guidance on how to connect required devices. For most of the demos, you would need a camera, keyboard, mouse, internet connection and a HDMI display monitor. Setup preparation for FRDM i.MX 95 board [Top view]   Setup preparation for FRDM i.MX 95 board [Back view]   NOTE: You might need to use a USB hub to connect keyboard, mouse and camera at the same time.   Runtime setup Description:   Runtime SDK delivers a complete runtime environment that enables AI/ML acceleration on the Ara240 module. To run demo applications, ensure that the Ara240 bring-up process has been successfully completed and the system is ready for demo evaluation. Refer to the Runtime SDK documentation for detailed guidance on: Verifying correct installation of the Runtime SDK. Checking and updating the Ara240 firmware version. Validating proxy service bring-up status. Executing benchmark tests on Ara240. Following these steps ensures that the module is properly initialized and ready for use. Ara240 supports the execution of CNNs, LLMs, VLMs, and agentic frameworks, enabling advanced AI workloads to run directly on Ara. For comprehensive examples and end-to-end workflow guidance, please refer to the Ara SDK documentation page.
View full article
From TinyML to advanced edge AI and GenAI, discover how to build intelligent systems directly on-device with FRDM, no cloud dependency required.
View full article
Getting Started Video:     This guide provides step-by-step instructions on how to verify successful communication and the runtime software environment to interface with the Ara240 module with the FRDM i.MX 95 Pro development board.   Out of the Box:   Get Familiar with the Ara240 Module   Ara240 Module [Back view] Ara240 Module [Top view]                   Connecting the M.2 Module   This section explains how to connect Ara240, a discrete module, to the FRDM i.MX 95 Pro development board. The instructions in the FRDM i.MX 95 Pro Getting Start Guide will walk you through the boot-up process for the pre-loaded Embedded Linux image on the board and how to connect the USB debug cable. For additional details, see the official FRDM i.MX 95 Pro Development Board documentation. References: FRDM i.MX 95 Pro Quick Start Guide FRDM i.MX 95 Pro Development Board product page  FRDM i.MX 95 Pro Getting started page Getting Started with ARA2-M2-16G-GT Follow the steps below to connect the Ara240 module to the FRDM i.MX 95 Pro development board:   Important: Ensure the board is powered off before making any connections. Insert the Ara240 module into the M.2 Key-M socket on the FRDM i.MX 95 Pro development board. Using the screw provided, secure the module. Connect the fan cable to the board’s fan header (refer to the FRDM i.MX 95 Pro board documentation for the exact header location).   "How to connect two Ara240 devices?"   The figure below illustrates the connection of Ara240 devices to the two M.2 Key-M slots on the FRDM i.MX 95 Pro development board. You can install one Ara240 device in either slot or connect two devices simultaneously by using both slots.     Connect the Ara240 to the FRDM i.MX 95 Pro development board.       Power on the Board   Follow the instructions to power on (boot) the board found in the Getting Started with FRDM-IMX95-Pro. After powering on, verify that the fan and green LED indicators Ara240 module are on are on.       Get the Software   This section will walk you through the Ara240 Runtime software development kit (SDK), a streamlined subset of the Ara240 SDK designed for rapid enablement and execution on NXP platforms. The Runtime SDK simplifies installation and configuration, enabling developers to quickly deploy and run AI/ML workloads on the Ara240 module with minimal effort.   Overview   Refer to Ara240 software release notes for details on the Ara240 software development kit (SDK) The Getting Started page for Ara240 only outlines usage on specific i.MX development platforms For any other platforms please reach out to your NXP representative for guidance.       Q2'26 BSP (L6.18.20-2.0.0) onwards runtime environment for i.MX 8MP and i.MX 95 boards is packed with Linux BSP.       Module Enumeration and Software Configuration   This section provides instructions to verify proper installation of Ara240 module and configuration of the Ara240 Runtime SDK on the FRDM i.MX 95 Pro development board. Verify Device Detection   Once the board has successfully booted, connect to the serial debug port to monitor system logs. To confirm that the Ara240 module is being detected by the board, run the following command: $ lspci | grep 1e58   Expected output: 0000:01:00.0 Processing accelerators: Device 1e58:0002 (rev 02)     Enable Ara240 device   For quick enablement, the Ara240 Runtime SDK starts at boot time. Refer to the Ara240 Runtime SDK documentation for detailed instructions and environment setup steps.   Q2'26 BSP (L6.18.20-2.0.0) onwards runtime environment for i.MX 8MP and i.MX 95 boards is packed with Linux BSP.       Developer Experience   This section provides an overview of Ara240 runtime software enablement using the FRDM i.MX 95 Pro development board. Verify Setup Environment   Use the following guidance on how to connect required devices. For most of the demos, you would need a camera, keyboard, mouse, internet connection and a HDMI display monitor. Setup preparation for FRDM i.MX 95 Pro board    NOTE: You might need to use a USB hub to connect keyboard, mouse and camera at the same time.   Runtime setup Description   Runtime SDK delivers a complete runtime environment that enables AI/ML acceleration on the Ara240 module. To run demo applications, ensure that the Ara240 bring-up process has been successfully completed and the system is ready for demo evaluation. Refer to the Runtime SDK documentation for detailed guidance on: Verifying correct installation of the Runtime SDK. Checking and updating the Ara240 firmware version. Validating proxy service bring-up status. Executing benchmark tests on Ara240. Following these steps ensures that the module is properly initialized and ready for use. Ara240 supports the execution of CNNs, LLMs, VLMs, and agentic frameworks, enabling advanced AI workloads to run directly on Ara240. For comprehensive examples and end-to-end workflow guidance, please refer to the Ara SDK documentation page.   Ara240 Demos   Henceforth Q2'26 Linux BSP, GoPoint can be launched to explore preselected Ara240 demonstrations included in the NXP provided Linux Board Support Package. User Guide: GPNTUG: GoPoint for i.MX Applications Processors User Guide   
View full article
  Introduction   This hands-on walks you through everything that happens before you ever write a line of application code: unboxing your FRDM i.MX 95 Pro board, getting acquainted with its layout and ports, powering it on, and confirming a healthy first boot from the on-board eMMC. By the time you are done, you will be comfortable using both the i.MX System Manager console and the Linux command line to confirm exactly what hardware you have in front of you. By the end you will be able to: Verify that the contents of your FRDM i.MX 95 Pro box are complete Get acquainted with the board, its peripherals, and ports Set up and boot the board for the first time Get familiar with the i.MX System Manager (SM) console and the Linux CLI Verify the board's hardware and resources using Linux commands Hardware & Prerequisites You need very little to get started: FRDM-IMX95-PRO board (the box) — in addition to the board itself, the box includes USB-C cables for power and debugging, mounting standoffs, the IW612 wireless module, and a documentation card linking to the product page and a getting-started tutorial. Power supply — a USB-C to USB-C cable is included in the box. For basic bring-up, any standard USB-C phone charger is sufficient. If your setup adds higher-power accessories (e.g., a display), use a 100 W-capable USB-C power adapter instead. PC host — a computer with a terminal / serial console program to connect to the board's debug port. That's it — no display or camera is required for this hands-on. Watch the Module Video Watch the full hands-on walkthrough below, then follow along on your own board.   Steps to Run the Hands-On Step 1: Explore the Board with Linux Commands Once the board has booted, open a terminal on the debug console and run the following commands to confirm the Linux environment and the hardware resources available to you. # 1) Linux version uname -a # 2) Storage devices lsblk # 3) Verify CPU numbers and architecture. lscpu # 4) SoC Id and Family cat /sys/devices/soc0/soc_id cat /sys/devices/soc0/family # 5) RAM memory available cat /proc/meminfo | head -20 # 6) network peripherals and addresses ip addr # 7) List Video Encoders and Decoders v4l2-ctl --list-devices # 8) GPU specs and capabilities vulkaninfo --summary # 9) Print available GPIOs gpioinfo Step 2: Explore the i.MX System Manager Console Next, switch to the i.MX System Manager (SM) console to inspect the board at the system level — Logical Machines, boot times, power rails, and clocks. # 1) System manager version, Board, Revision, Silicon etc info # 2) Logical Machines information lm info # 3) Boot time of each Logical machine btime # 4) Power status of each peripheral power.r # 5) Clocks status clock.r Troubleshooting Symptom What to check Power LED is on but there is no output on the console Check the Boot Mode switches (set them to eMMC) Power-cycle the board (turn it off and back on) after changing the Boot Mode switches Verify the serial console baud rate is set to 115200 Confirm the Debug port is connected to the host PC Open all the COM ports exposed by the board when the Debug port is connected to the host PC Conclusion In this hands-on, you: Verified the contents of your FRDM i.MX 95 Pro box Got acquainted with the board, its peripherals, and ports Set up and booted the board for the first time from eMMC Used the i.MX System Manager console and the Linux CLI to inspect the board Confirmed the board's hardware and resources via Linux commands If you have not already, watch the module video above for the full walkthrough, and check out the rest of the FRDM Training Hub for the next hands-on in the series.
View full article
FRDM i.MX 95 Pro Hands-On: ARA240 DNPU AI Accelerator FRDM i.MX 95 Pro Hands-On Training Series  |  September 2026   Introduction This hands-on walks you through the ARA240 DNPU AI Accelerator integrated with the FRDM i.MX 95 Pro development board. The ARA240 is an M.2-form-factor neural processing unit that connects over PCIe and dramatically expands the board's AI inference capability — from classic computer-vision pipelines to large language models (LLMs) and vision-language models (VLMs) — all powered by NXP's eIQ software stack.   Item Details Host Board FRDM i.MX 95 Pro AI Accelerator ARA240 DNPU (up to 2 modules) BSP L6.18.20-2.0.0 (precompiled, available on the NXP website) Interface PCIe via M.2 Key-M slots J24 / J25   By the end of this hands-on you will be able to: Verify that the ARA240 DNPU is correctly detected by the system. List, download, and run AI models (CNN, LLM, VLM) on the accelerator. Measure DNPU performance metrics using the provided shell utilities. Configure and start the eIQ AAF Connector service to expose a REST API for AI inference. Send chat-completion requests to a locally running LLM through the connector's web interface. Troubleshoot the most common setup issues.   Hardware & Prerequisites Gather the following before starting: Hardware FRDM-IMX95-PRO development board ARA240 DNPU module (one or two, depending on your use case) Keyboard (for direct board interaction) Host machine with a web browser (to access the connector API UI) Internet connection (required for model downloads) M.2 Connector Reference Connector Purpose J24 M.2 Key-M slot — ARA240 Module #1 J25 M.2 Key-M slot — ARA240 Module #2 J9 Fan power supply for the module in J24 J10 Fan power supply for the module in J25 Software BSP L6.18.20-2.0.0 — precompiled image available on the NXP website.   Watch the Hands-On Video The video below walks through the complete ARA240 DNPU setup and demo flow on the FRDM i.MX 95 Pro, covering device detection, model download, inference testing, NPU metrics, and the eIQ AAF Connector in action. Watch it alongside the step-by-step instructions in the next section.   Steps to Run the Hands-On All commands below are run directly on the FRDM i.MX 95 Pro board (via serial console or SSH). The eIQ utilities are pre-installed in the BSP image. Step 1 — Verify Device Detection After powering on the board with the ARA240 module seated in J24 (and/or J25), confirm the accelerator is recognized by the system: # Device Detection & Status chip_info.sh The script prints the detected DNPU chip information. If nothing is returned, check the M.2 seating and fan-power connectors (J9/J10). Step 2 — List Available Models Use the fetch_models utility to see which AI models are available for download: # List available models fetch_models --list The output shows model IDs for CNN, LLM, and VLM workloads that are compatible with the ARA240. Step 3 — Download a Model Download a model by its repository ID. The example below fetches a 7-billion-parameter instruction-tuned LLM: # Download a specific model (example: Qwen2.5 7B) fetch_models --repo-id nxp/Qwen2.5-7B-Instruct-Ara240 Models are stored under /usr/share/ in subdirectories named cnn , llm , or vlm depending on the model type. Step 4 — Run Inference Performance Tests Once a model is downloaded, benchmark its inference performance on the DNPU: # Running Inference Tests run_model_perf.sh Step 5 — Measure DNPU Metrics Capture real-time NPU utilization and performance counters: # Measuring DNPU Metrics ara2_metrics.sh Step 6 — Configure and Start the eIQ AAF Connector The eIQ AAF Connector exposes a REST API (OpenAI-compatible) so any HTTP client or web application can send inference requests to the ARA240. Follow these steps: # Check whether the connector service is already running systemctl status eiq-aaf-connector.service # Start the connector service (systemd-managed) systemctl start eiq-aaf-connector.service # Stop the connector service when done systemctl stop eiq-aaf-connector.service # Edit the connector configuration (model path, port, etc.) vi /usr/share/eiq/aaf-connector/server_config.json # Alternatively, start the connector manually (foreground) /usr/share/eiq/aaf-connector/venv/bin/connector --host 0.0.0.0 --port 8000 Once the connector is running, open the interactive API documentation in a browser on your host machine (replace <board-ip> with the board's actual IP address): # Open the connector Web API interface in a browser http://<board-ip>:8000/docs Step 7 — Send a Chat Completion Request With the connector running and a downloaded LLM, you can send an OpenAI-compatible chat completion request directly from the API docs page or via any HTTP client: # Example chat completion payload (POST to /v1/chat/completions) { "model": "Qwen2.5-7B-Instruct", "messages": [ { "role": "system", "content": "You are a helpful assistant" }, { "role": "user", "content": "hello, how are you?" } ] }   Troubleshooting Symptom What to Check chip_info.sh returns nothing / DNPU not detected Verify the ARA240 module is firmly seated in J24 or J25. Confirm the fan-power cable is connected to J9 (for J24) or J10 (for J25). Reboot the board after reseating. fetch_models --list fails or model download hangs Check internet connectivity: ping 8.8.8.8 If DNS resolution fails, set it manually: echo nameserver 8.8.8.8 > /etc/resolv.conf Model not found after download Verify the model landed in the correct directory: ls /usr/share/<cnn|llm|vlm>/ Certificate or TLS errors during model download The board's system clock may be wrong. Set the correct date and time: date --set="18 SEP 2026 13:00:00" Then retry the download. Connector service fails to start Check journalctl -u eiq-aaf-connector.service for error details. Ensure server_config.json points to a valid downloaded model path.   Conclusion In this hands-on you: Connected the ARA240 DNPU AI Accelerator to the FRDM i.MX 95 Pro via PCIe (M.2 Key-M). Verified device detection and explored available AI models using the eIQ command-line utilities. Downloaded and benchmarked a large language model on the DNPU. Measured real-time NPU performance metrics with ara2_metrics.sh . Configured and launched the eIQ AAF Connector to expose an OpenAI-compatible REST API. Sent a live chat-completion request to a locally running LLM — entirely on the edge. For a full visual walkthrough, watch the demo video above. Explore the rest of the FRDM i.MX 95 Pro Hands-On Training Hub for additional modules covering cameras, connectivity, multimedia, and more.
View full article
Introduction   This hands-on video explains how to take a trained AI model and deploy it for NPU-accelerated inference using eIQ Neutron on the FRDM i.MX 95 PRO development board. YOLOv8n is used as the example model. The video covers the complete workflow, including host setup, model export, calibration, INT8 quantization, Neutron compilation, board deployment, benchmarking, and troubleshooting. By the End of This Training, You Will Be Able To Understand the main components of the eIQ Neutron-S hardware and software stack. Download and export a YOLOv8n model to TFLite. Quantize the model to INT8 for Neutron NPU execution. Compile the quantized model for the i.MX 95 target. Review compiler statistics and determine which operations are delegated to the NPU. Deploy the model, delegate, driver, and firmware to the board. Run CPU and NPU benchmarks. Compare inference latency and calculate the NPU speed-up.   Hardware and Prerequisites   Before starting the training, verify that you have the required development board, host system, network connection, model, calibration data, and software tools. Development Board   FRDM i.MX 95 PRO development board. NXP BSP LF6.18.20 2.0.0. eIQ Neutron runtime compatible with Neutron SDK 3.2.1 or later. TensorFlow Lite 2.19.0 benchmark application. Ethernet or USB-CDC connectivity. SSH and SCP access to the board. Root access on the target system. Linux Host Computer   Ubuntu 20.04 or Ubuntu 22.04 is recommended. Python 3.8 or later. Python virtual environment support. SSH and SCP command-line tools. Sufficient storage for the SDK, models, calibration images, and generated artifacts.     Watch the Complete Training Video   Watch the video from beginning to end and execute the commands in the presented order. Each stage generates an artifact required by the next stage.     Command Cheat Sheet   The following commands are organized in execution order. Replace placeholders such as <board-ip> with the values for your environment. 1. Download and Configure the Neutron SDK   # Extract the SDK archive unzip eiq-neutron-sdk-linux-3.2.1.zip # Enter the SDK directory cd eiq-neutron-sdk-linux-3.2.1 # Add the SDK tools to PATH for the current terminal export PATH="$PWD/bin:$PATH" # Optional: make the PATH configuration persistent echo 'export PATH="/path/to/eiq-neutron-sdk-linux-3.2.1/bin:$PATH"' >> ~/.bashrc # Reload the shell configuration source ~/.bashrc # Verify the SDK tools tflite-profiler --help tflite-quantizer --help neutron-compiler --help   2. Create the Python Environment   # Create a Python virtual environment python3 -m venv .venv # Activate the virtual environment source .venv/bin/activate # Upgrade pip python3 -m pip install --upgrade pip # Install the required packages pip install generate-parameter-library-py \ ultralytics \ hf \ ai-edge-litert \ litert_torch \ numpy \ opencv-python   3. Download the YOLOv8n Model   # Download the trained YOLOv8n weights hf download Ultralytics/YOLOv8 yolov8n.pt --local-dir . # Verify the downloaded model ls -lh yolov8n.pt   4. Export YOLOv8n to TFLite   # Export the PyTorch model to TFLite yolo export model=yolov8n.pt format=tflite # Locate the generated TFLite model find . -name "*.tflite" -type f # Update the following commands if your exported # model uses a different file name or directory.   5. Download the COCO Calibration Dataset   # Create a directory for the calibration dataset mkdir -p coco cd coco # Download the COCO training images wget --no-check-certificate \ http://images.cocodataset.org/zips/train2017.zip # Extract the images unzip train2017.zip # Return to the project directory cd .. # Verify the image directory find ./coco/train2017 -type f -name "*.jpg" | head   6. Create the Calibration Conversion Script   Save the following script as jpg2bin.py . It converts the JPEG calibration images into raw binary tensors expected by the profiler. #!/usr/bin/env python3 import argparse import glob import os import random import cv2 import numpy as np def letterbox(image, new_shape=640, color=(114, 114, 114)): height, width = image.shape[:2] ratio = min(new_shape / height, new_shape / width) resized_height = int(round(height * ratio)) resized_width = int(round(width * ratio)) resized = cv2.resize( image, (resized_width, resized_height), interpolation=cv2.INTER_LINEAR, ) canvas = np.full( (new_shape, new_shape, 3), color, dtype=np.uint8, ) top = (new_shape - resized_height) // 2 left = (new_shape - resized_width) // 2 canvas[ top:top + resized_height, left:left + resized_width, ] = resized return canvas def main(): parser = argparse.ArgumentParser( description="Convert JPEG images to YOLOv8n calibration tensors." ) parser.add_argument( "--images", default="./coco/train2017", help="Directory containing the calibration JPEG images.", ) parser.add_argument( "--out", default="./calib_yolov8n", help="Output directory for the binary tensors.", ) parser.add_argument( "--num", type=int, default=1000, help="Maximum number of calibration images.", ) parser.add_argument( "--size", type=int, default=640, help="Model input width and height.", ) parser.add_argument( "--shuffle", action="store_true", help="Shuffle the image list before selecting images.", ) args = parser.parse_args() os.makedirs(args.out, exist_ok=True) files = sorted( glob.glob(os.path.join(args.images, "*.jpg")) ) if args.shuffle: random.seed(0) random.shuffle(files) files = files[:args.num] if not files: raise RuntimeError( f"No JPEG images were found in {args.images}" ) for index, file_path in enumerate(files): image = cv2.imread(file_path) if image is None: print(f"Skipping unreadable image: {file_path}") continue # Convert BGR to RGB. image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB) # Letterbox resize to 640 x 640. image = letterbox(image, args.size) # Convert to float32 and normalize to [0, 1]. tensor = image.astype(np.float32) / 255.0 # Add batch dimension. # Final layout: 1 x 640 x 640 x 3, NHWC. tensor = np.expand_dims(tensor, axis=0) output_path = os.path.join( args.out, f"calib_{index:05d}.bin", ) tensor.tofile(output_path) print( f"Calibration tensors written to: {args.out}" ) if __name__ == "__main__": main() # Make the script executable chmod +x jpg2bin.py # Generate up to 1000 calibration tensors python3 jpg2bin.py \ --images ./coco/train2017 \ --out ./calib_yolov8n \ --num 1000 \ --size 640 \ --shuffle # Count the generated binary files find ./calib_yolov8n -type f -name "*.bin" | wc -l # Check the size of a generated tensor ls -lh ./calib_yolov8n | head   7. Inspect the TFLite Input and Output Tensors   python3 - <<'PY' from ai_edge_litert.interpreter import Interpreter model_path = "yolov8n.tflite" interpreter = Interpreter(model_path=model_path) interpreter.allocate_tensors() print("Input details:") for tensor in interpreter.get_input_details(): print(tensor) print("\nOutput details:") for tensor in interpreter.get_output_details(): print(tensor) PY Record the exact input tensor name reported by the model. Replace serving_default_args_0 in the profiling command if your model uses a different name.   8. Profile the Floating-Point TFLite Model   # Replace serving_default_args_0 if the model # reports a different input tensor name. tflite-profiler \ --input yolov8n.tflite \ --dataset serving_default_args_0,calib_yolov8n \ --output yolov8n_profile.csv # Verify that the profiling CSV was generated ls -lh yolov8n_profile.csv # Preview the beginning of the profile head yolov8n_profile.csv   9. Quantize the Model to INT8   # Generate the INT8 TFLite model tflite-quantizer \ --input yolov8n.tflite \ --profile yolov8n_profile.csv \ --output yolov8n_quant.tflite # Compare the model file sizes ls -lh yolov8n.tflite yolov8n_quant.tflite   10. Verify the Quantized Model   python3 - <<'PY' from ai_edge_litert.interpreter import Interpreter model_path = "yolov8n_quant.tflite" interpreter = Interpreter(model_path=model_path) interpreter.allocate_tensors() print("Quantized input details:") for tensor in interpreter.get_input_details(): print("Name:", tensor["name"]) print("Shape:", tensor["shape"]) print("Data type:", tensor["dtype"]) print("Quantization:", tensor["quantization"]) print() print("Quantized output details:") for tensor in interpreter.get_output_details(): print("Name:", tensor["name"]) print("Shape:", tensor["shape"]) print("Data type:", tensor["dtype"]) print("Quantization:", tensor["quantization"]) print() PY   11. Compile the Model for the Neutron NPU   # Compile the INT8 model for the i.MX 95 Neutron NPU neutron-compiler \ --input yolov8n_quant.tflite \ --output yolov8n_neutron.tflite \ --target imx95 # Verify the generated model ls -lh yolov8n_neutron.tflite Generate Compiler Statistics # Generate compiler and delegation statistics neutron-compiler \ --input yolov8n_quant.tflite \ --output yolov8n_neutron_stats.tflite \ --target imx95 \ --dump-statistics # Review the compiler output and record: # 1. Number of delegated nodes # 2. Number of CPU fallback nodes # 3. Unsupported operators # 4. Generated NeutronGraph partitions Create a Profiling Build # Compile a profiling-enabled model neutron-compiler \ --input yolov8n_quant.tflite \ --output yolov8n_neutron_prof.tflite \ --target imx95 \ --use-profiling # Verify all generated models ls -lh yolov8n_quant.tflite \ yolov8n_neutron.tflite \ yolov8n_neutron_prof.tflite   12. Configure the Board IP Address   # Replace the example address with the board IP address export BOARD_IP="192.168.1.100" # Verify network connectivity ping -c 4 "$BOARD_IP" # Test the SSH connection ssh root@"$BOARD_IP"   13. Create the Deployment Directory   # Create the working directory remotely ssh root@"$BOARD_IP" \ "mkdir -p /root/neutron_demo"   14. Copy Runtime Artifacts to the Board   The driver, delegate, and firmware may already be included in the BSP. Copy them only when the required or matching versions are not already installed. # Copy the Neutron driver scp libNeutronDriver.so \ root@"$BOARD_IP":/lib/ # Copy the Neutron delegate scp libneutron_delegate.so \ root@"$BOARD_IP":/usr/lib/ # Copy the Neutron firmware scp NeutronFirmware.elf \ root@"$BOARD_IP":/lib/firmware/ # Copy the plain INT8 model for the CPU baseline scp yolov8n_quant.tflite \ root@"$BOARD_IP":/root/neutron_demo/ # Copy the Neutron-compiled model scp yolov8n_neutron.tflite \ root@"$BOARD_IP":/root/neutron_demo/ # Optional: copy the profiling-enabled model scp yolov8n_neutron_prof.tflite \ root@"$BOARD_IP":/root/neutron_demo/   15. Verify the Files on the Board   # Connect to the board ssh root@"$BOARD_IP" # Enter the deployment directory cd /root/neutron_demo # Verify the models ls -lh /root/neutron_demo/ # Check the driver ls -lh /lib/libNeutronDriver.so # Check the delegate ls -lh /usr/lib/libneutron_delegate.so # Check the firmware ls -lh /lib/firmware/NeutronFirmware.elf # Refresh the shared-library cache ldconfig # Verify that the delegate is visible to the loader ldconfig -p | grep -i neutron   16. Check the BSP and Runtime Environment   # Display the Linux distribution and BSP information cat /etc/os-release # Display the kernel version uname -a # Search for Neutron-related kernel messages dmesg | grep -i neutron # Search for firmware-related messages dmesg | grep -i firmware # Locate the TensorFlow Lite benchmark application find /usr/bin -name "benchmark_model*" -type f 2>/dev/null   17. Run the CPU Baseline   cd /root/neutron_demo /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=yolov8n_quant.tflite \ --num_threads=4 \ --num_runs=50 Record the average inference latency, minimum latency, maximum latency, initialization time, and memory information reported by the benchmark.   18. Run the NPU Benchmark   cd /root/neutron_demo /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=yolov8n_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so \ --num_runs=50 Confirm that the benchmark output reports that the external delegate was loaded and that one or more model partitions were delegated.   19. Save Benchmark Results   # Save the CPU benchmark output /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=yolov8n_quant.tflite \ --num_threads=4 \ --num_runs=50 \ 2>&1 | tee cpu_benchmark.txt # Save the NPU benchmark output /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=yolov8n_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so \ --num_runs=50 \ 2>&1 | tee npu_benchmark.txt # Review the saved results cat cpu_benchmark.txt cat npu_benchmark.txt   20. Calculate the NPU Speed-Up   Use the average latency reported by each benchmark: Speed-up = CPU average latency / NPU average latency Example: CPU average latency = 100 ms NPU average latency = 10 ms Speed-up = 100 / 10 Speed-up = 10x     Required Deployment Artifacts   Artifact Example File Purpose Neutron driver libNeutronDriver.so Communicates with the Neutron firmware and passes model buffers, weights, kernels, and input or output data. Neutron delegate libneutron_delegate.so Connects TensorFlow Lite to the Neutron runtime and delegates supported NeutronGraph operations to the NPU. Neutron firmware NeutronFirmware.elf Runs on the dedicated RISC-V core and executes the generated Neutron microcode. Quantized TFLite model yolov8n_quant.tflite Provides the CPU baseline and serves as the input to the Neutron compiler. Neutron-compiled model yolov8n_neutron.tflite Contains NeutronGraph operations generated for NPU execution.   Troubleshooting   Use the following table to identify common host, model, compilation, deployment, and runtime problems. Area Problem Possible Cause Recommended Solution Host setup SDK commands are not found. The SDK bin directory is not included in PATH . Run export PATH="$PWD/bin:$PATH" from the SDK directory. Add the absolute SDK path to ~/.bashrc if the configuration must persist. Python environment A required Python module cannot be imported. The virtual environment is not active or the package was installed in a different environment. Run source .venv/bin/activate . Verify the active interpreter with which python3 , and reinstall the missing dependency with pip install PACKAGE_NAME . Model export The expected yolov8n.tflite file cannot be found. The exporter created a subdirectory or used a different filename. Run find . -name "*.tflite" -type f . Update the following commands to use the actual exported model path. Calibration No calibration binary files are generated. The image directory is incorrect or does not contain JPEG files. Verify the directory with find ./coco/train2017 -name "*.jpg" | head . Pass the correct directory through the --images argument. Calibration The calibration tensor has the wrong shape or size. The resize, batch dimension, layout, or data type is incorrect. Confirm an NHWC tensor with shape 1 x 640 x 640 x 3 , RGB channel order, float32 data, and values normalized to [0, 1] . Calibration The quantized model produces inaccurate predictions. The calibration preprocessing differs from inference preprocessing. Verify letterbox resizing, padding color, RGB conversion, normalization, tensor layout, input size, and data type. Use representative images that match the intended application. Profiler The profiler reports an invalid or unknown input tensor. The tensor name in --dataset does not match the model input name. Inspect the model input details with the TFLite interpreter. Replace serving_default_args_0 with the exact name reported by the model. Profiler The profiler cannot read the calibration files. The dataset path is incorrect, the folder is empty, or the binary format does not match the input tensor. Verify the folder path, count the files, and confirm the expected number of bytes for each tensor. Quantization The quantized model still uses floating-point tensors. The model was not fully quantized or the generated profile is incomplete. Re-run profiling with valid calibration data. Inspect the input, output, and intermediate tensor data types before compiling the model. Compilation neutron-compiler fails. The input model is invalid, not INT8, or contains unsupported quantization parameters. Confirm that the input is the quantized TFLite model. Inspect its tensor types and quantization parameters, then run the compiler again with statistics enabled.   Conclusion   Congratulations! You have completed the end-to-end workflow for deploying and running an AI model on the eIQ Neutron-S NPU integrated into the FRDM i.MX 95 PRO. Throughout this training, you learned how to prepare the Linux host environment, export YOLOv8n to TFLite, build a representative calibration dataset, quantize the model to INT8, and compile it for the i.MX 95 target. You also learned how to transfer the required runtime artifacts to the board and compare CPU and NPU inference performance. This workflow is not limited to YOLOv8n. You can use the same process as a starting point for deploying your own computer vision models. However, each model must be evaluated individually because input formats, preprocessing requirements, quantization behavior, and operator support may differ. Recommended Next Steps   Validate the accuracy of the INT8 model against the original floating-point model. Review the compiler statistics to identify unsupported operations and CPU fallback sections. Measure end-to-end application performance, including preprocessing, inference, and post-processing. Test the workflow with your own model and a calibration dataset that represents your real application. Use a profiling-enabled build to identify the most expensive layers and potential performance bottlenecks.
View full article