MCX W23 Knowledge Hub The MCX W23 is a family of devices. All devices are Arm Cortex®-M33 based wireless microcontrollers for embedded applications supporting Bluetooth Low Energy 5.3. It can be used to develop IoT solutions. MCX W23xA supports LV_SM mode. MCX W23xB supports HV_SM and XR_SM mode. Building on NXP's strong history of providing industrial edge solutions, the MCX W series offers a wide operating temperature range from -40 °C to 125 °C. The Arm Cortex-M33 provides a security foundation, offering isolation to protect valuable IP and data with Trust Zone technology. It simplifies the design and software development of digital signal control systems with the integrated digital signal processing (DSP) instructions. To support security requirements, the MCX W23 also offers support for SHA-1, SHA2-256, AES, RSA, ECC, UUID, dynamic encryption, and decryption of the flash data using a PRINCE engine, debug authentication, and TBSA-M compliance.   Documents Reference Manual Fact sheet Data Sheet Errata for MCX W23xUIK MCX W23 Hardware Design Guide Secure Reference manual** European Union Declaration of Conformity for FRDM-MCXW23 FRDM-MCXW23 Board User Manual Bluetooth Specifications The MCX W23 is compatible with the Bluetooth Low Energy 5.3 specification: – Bluetooth Low Energy 5.3 controller subsystem (QDID 200592) – Bluetooth Low Energy 5.3 host subsystem (QDID 226395) – Includes a 48-bit unique Bluetooth device address – Up to 4 simultaneous connections supported The MCX W23 supports the following Bluetooth Low Energy features: – Device privacy and network privacy modes (version 5.0) – Advertising extension PDUs (version 5.0) – Anonymous device address type (version 5.0) – Up to 2 Mbps data rate (version 5.0) – Long range (version 5.0) – High-duty cycle, Non connectable advertising (version 5.0) – Channel selection algorithm #2 (version 5.0) – High output power (version 5.0) – Advertising channel index (version 5.1) – Periodic advertising sync transfer (PAST) (version 5.1) – Supports LE power control feature (version 5.2) RF antenna: 50 Ω single-ended RF receiver characteristics: – Sensitivity −94 dBm in Bluetooth Low Energy 2 Mbps – Sensitivity −97 dBm in Bluetooth Low Energy 1 Mbps – Sensitivity −100 dBm in Bluetooth Low Energy 500 kbps – Sensitivity −102 dBm in Bluetooth Low Energy 125 kbps – Accurate RSSI measurement with ±3 dB accuracy Flexible RF transmitter level configurability: – TX mode 1 (TXM1): Range from −31 dBm to +2 dBm when VDD_RF exceeds 1.1 V – TX mode 2 (TXM2): Range from −28 dBm to +6 dBm when VDD_RF exceeds 1.7   Bluetooth_5.0_Feature_Overview Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview   Training MCX W Series Training - NXP Community   Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development    Application Notes Power Management: AN14660: Power Management for MCX W23: This App Note provides information about the power manager software component. The application uses this component and the operating system to achieve optimal low-power states, based on the requirements of the application. RF: AN14575: MCX W23 Health Care IoT Peripheral Software Architecture: This App Note provides an overview of the software architecture for the MCX W23 Health care IoT Peripheral application. Designed as a model implementation, this application showcases the key features of the MCX W23 platform and serves as a foundation for developing product-quality applications. AN14659: MCX W23 Bluetooth Low Energy Power Consumption Analysis: This App Note describes the power consumption of the MCX W23 Bluetooth Low Energy (LE) device and the procedure to measure the current consumption using the MCXW23_EVK_BB and MCXW236B_RDM boards. AN2731: Compact Planar Antennas for 2.4 GHz Communication: This App Note is not an exhaustive inquiry into antenna design. It is instead focused on helping the customers understand enough board layout and antenna basics to select a correct antenna type for their application, as well as avoiding typical layout mistakes that cause performance issues that lead to delays Security: AN14657: Getting Started with Secure Boot on MCX W23: This application note covers the design of the bootloader ROM code that NXP has developed on the MCX W23, and how to use all its features. Useful Links Bluetooth LE FSCI Host Application running on FRDM-MCXN947 and MCXW23B-Click Board: The Bluetooth LE FSCI Host application demonstrates a host-side implementation for the Health Thermometer use case. It is designed to work alongside the FSCI Blackbox application, which runs on platforms such as the MCXW236 Click Board, FRDM-MCXW236, or other compatible Bluetooth LE wireless MCUs. Transmitter Maximum Output Power Override Application Note Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization):  This page is dedicated to the Kinetis (KW35/KW38/KW45/KW47/KW43) and MCX W7x (MCX W71/W72/W70) Power Profile Tools. It will help you to estimate the power consumption in your application (Automotive or IIoT) and evaluate the battery lifetime of your solution. Development Tools  VSCode: MCUXpresso for Visual Studio Code (VS Code) provides an optimized embedded developer experience for code editing and development. Zephyr RTOs  NXP Application Code Hub: Application Code Hub (ACH) repository enables engineers to easily find microcontroller software examples, code snippets, application software packs and demos developed by our in-house experts. This space provides a quick, easy and consistent way to find microcontroller applications. NXP SPSDK: Is a unified, reliable, and easy to use Python SDK library working across the NXP MCU portfolio providing a strong foundation from quick customer prototyping up to production deployment. NXP SEC Tool: The MCUXpresso Secure Provisioning Tool us a GUI-based application provided to simplify generation and provisioning of bootable executables on NCP MCU devices. NXP OTAP Tool: Is an application that helps the user to perform an over the air firmware update of an NXP development board. FRDM-RW612

MCX W23ナレッジハブ MCX W23はデバイスファミリです。すべてのデバイスは、Bluetooth Low Energy 5.3をサポートする組み込みアプリケーション向けのArm Cortex®-M33ベースのワイヤレスマイクロコントローラです。IoTソリューションの開発に使用できます。MCX W23xAはLV_SMモードをサポートしています。MCX W23xBはHV_SMモードとXR_SMモードをサポートしています。 NXPがインダストリアル・エッジ・ソリューションを提供してきた確固たる歴史に基づいて、MCX Wシリーズは-40°C～125°Cまでの幅広い動作温度範囲を提供します。 Arm Cortex-M33はセキュリティ基盤を提供し、TrustZoneテクノロジーで貴重なIPとデータをアイソレートで保護します。統合されたデジタル信号プロセッシング（DSP）命令により、デジタル信号制御システムのデザインとソフトウェア開発が簡素化されます。セキュリティ要件をサポートするため、MCX W23はSHA-1、SHA2-256、AES、RSA、ECC、UUID、PRINCEエンジンを使用したフラッシュデータの動的暗号化および復号化、デバッグ認証、TBSA-Mコンプライアンスもサポートしています。   ドキュメント リファレンス・マニュアル ファクト・シート データ・シート MCX W23xuikの正誤表 MCX W23ハードウェア設計ガイド Secure Referenceマニュアル** FRDM-MCXW23の欧州連合適合宣言 FRDM-MCXW23ボード・ユーザー・マニュアル Bluetooth仕様 MCX W23はBluetooth Low Energy 5.3仕様と互換性があります： – Bluetooth Low Energy 5.3コントローラサブシステム (QDID 200592) – Bluetooth Low Energy 5.3ホストサブシステム (QDID 226395) – 48ビットのユニークなBluetoothデバイスアドレスを含む – 最大4つの同時接続に対応。 MCX W23は以下のBluetooth Low Energy機能をサポートしています： – デバイス・プライバシーおよびネットワーク・プライバシー・モード（バージョン5.0） – 広告拡張PDU（バージョン5.0） – 匿名デバイス・アドレス・タイプ（バージョン5.0） – 最大2 Mbpsデータ・レート（バージョン5.0） – 長距離（バージョン5.0） – 高デューティ・サイクル、非接続型広告（バージョン5.0） – チャネル選択アルゴリズム#2（バージョン5.0） – 高出力（バージョン5.0） – 広告チャネル・インデックス（バージョン5.1） – 定期広告同期転送（PAST）（バージョン5.1） – LE電力制御機能をサポート（バージョン5.2） RFアンテナ：50 Ωシングルエンド RF レシーバ特性： - Bluetooth Low Energy 2 Mbps における感度 -94 dBm - Bluetooth Low Energy 1 Mbps における感度 -97 dBm - Bluetooth Low Energy 500 kbps における感度 -100 dBm - Bluetooth Low Energy 125 kbps における感度 -102 dBm - ±3 dB 精度の正確な RSSI 測定 柔軟なRFトランスミッター・レベルを設定可能： – TXモード1（TXM1）：VDD_RF が 1.1 V を超える場合、-31 dBm～+2 dBm の範囲 – TXモード2（TXM2）：VDD_RF が 1.7 V を超える場合、-28 dBm～+6 dBm の範囲。   Bluetooth_5.0_機能の概要 Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能_概要 Bluetooth_5.3_機能_概要   トレーニング MCX W シリーズトレーニング - NXP コミュニティ   機器 ワイヤレス機器：この記事には、プロジェクト策定に役立つ機器へのリンクが掲載されています。   アプリケーション・ノート 電力管理： AN14660: MCX W23のパワーマネージメント：このアプリケーションノートでは、パワーマネージャソフトウェアコンポーネントに関する情報を提供します。アプリケーションは、このコンポーネントとオペレーティングシステムを使用することで、アプリケーションの要件に基づいて最適な低電力状態を実現します。 RF： AN14575: MCX W23 ヘルスケア IoT ペリフェラルのソフトウェア アーキテクチャ:このアプリケーション ノートでは、MCX W23 ヘルスケア IoT ペリフェラルアプリケーションのソフトウェア アーキテクチャの概要を説明します。モデル実装として設計されたこのアプリケーションは、MCX W23 プラットフォームの主要な機能を紹介し、製品品質のアプリケーションを開発するための基盤として機能します。 AN14659: MCX W23 Bluetooth Low Energy の電力消費分析:このアプリケーション ノートでは、MCX W23 Bluetooth Low Energy (LE) デバイスの電力消費と、MCXW23_EVK_BB および MCXW236B_RDM ボードを使用して電流消費を測定する手順について説明します。 AN2731: 2.4 GHz 通信用小型平面アンテナ:このアプリケーション ノートは、アンテナデザインに関する徹底的な調査ではありません。その代わりに、お客様がボードレイアウトとアンテナの基礎を十分に理解し、アプリケーションに適したアンテナタイプを選択できるようにすること、そして遅延につながるパフォーマンスの問題を引き起こす一般的なレイアウトミスを回避することに重点を置いています。 セキュリティ: AN14657: MCX W23 でのセキュア ブートの開始:このアプリケーションノートでは、NXP がMCX W23用に開発したブートローダ ROM コードの設計と、そのすべての機能の使用方法について説明します。 便利なリンク FRDM-MCXN947およびMCXW23Bクリックボード上で動作するBluetooth LE FSCIホストアプリケーション： Bluetooth LE FSCIホストアプリケーションは、Health ThermometerのユースCASEに対するホスト側実装を示しています。これは、MCXW236クリックボード、FRDM-MCXW236、またはその他の互換性のあるBluetooth LEワイヤレスMCUなどのプラットフォーム上で動作するFSCI Blackboxアプリケーションと一緒に動作するように設計されています。 トランスミッタ最大出力電力オーバーライドアプリケーションノート Kinetis (../45/47/43;MCX W71/72/70) および MCX W23 パワープロファイルツール (ローカライゼーションを含む) : このページは、Kinetis (KW35/KW38/KW45/KW47/KW43) および MCX W7x (MCX W71/W72/W70) パワープロファイルツール専用です。このツールを使用すると、アプリケーション (オートモーティブまたは IIoT) の消費電力を推定し、ソリューションのバッテリー寿命を評価できます。 開発ツール VS Code：MCUXpresso for Visual Studio Code（VS Code）は、組み込み開発者のエクスペリエンスをコードの編集と開発に向けて最適化したものです。 Zephyr RTOS  NXPアプリケーション・コード・ハブ：アプリケーション・コード・ハブ（ACH）リポジトリで、当社の専門家が開発したマイクロコントローラ・ソフトウェアのサンプル、コードスニペット、アプリケーション・ソフトウェア・パック、デモが簡単に見つかります。このスペースには、エンジニアがマイクロコントローラ・アプリケーションを迅速かつ容易に一貫性をもって探し当てるための方法があります。 NXP SPSDK：信頼性が高く使いやすいPython SDK統合ライブラリです。NXP MCUポートフォリオ全体で動作するので、お客様のクイックプロトタイピングから本番環境デプロイまで対応する強力な基盤となります。 NXP SECツール：GUIベースのアプリケーションMCUXpresso Secure Provisioning Toolは、NCP MCUデバイスのブータブル実行ファイルの生成とプロビジョニングをシンプル化するものです。 NXP OTAP Tool：ユーザーがNXP開発ボードのOver-the Air)ファームウェア・アップデートを実行するのに役立つアプリケーションです。 FRDM-RW612

Front and Rear Lights – SW & HW Environment 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article belongs to the Front and Rear Lights series and describes the software and hardware environment used throughout the project. Before looking into signal routing, control logic, or integration aspects, it is important to first understand the tools and platforms that support the development and execution of the front and rear lights application. This article introduces the software components used to develop, configure, and deploy the application, together with the hardware platforms used to demonstrate the lighting functionality. This information provides the foundation needed for the remaining articles in the series. Model-Based Design sits at the center of the workflow. MathWorks tools handle the modeling of the front and rear lighting control logic, the definition of the CAN communication interfaces, and validation across simulation stages. NXP tools then deploy those models to the S32K3 target platform, wiring the generated application to real-time peripherals, LED driver hardware, and lighting feedback signals. 3 Required Software 3.1. Vehicle Network Toolbox Within this workflow, Vehicle Network Toolbox plays a central role in defining, simulating, and validating the CAN interfaces of the front and rear lights module. It brings DBC-driven message definitions directly into Simulink, allowing communication behavior to be tested alongside the control logic long before integration. Every command received from the central controller and every status message sent back to the network is modeled using the exact structure defined in the DBC files, keeping the application perfectly aligned with the vehicle-level specification. Vehicle Network Toolbox is available as an add-on in MATLAB/Simulink, adding support for CAN communication and DBC-based message definitions.   Figure 1 - Vehicle Network Toolbox 3.2. Stateflow Stateflow is used to model the control logic of both lighting modules, translating the CAN commands received from the central controller into concrete lighting actions. Each function is represented as a state machine, where transitions are triggered by incoming signals and internal conditions. This approach keeps the logic structured and readable: activation, deactivation, mode switching, and fault handling are all captured in the same diagram. Stateflow is available as an add-on that can be installed directly from within MATLAB/Simulink, extending the environment with state machine modeling capabilities. Figure 2 - Stateflow 3.3. NXP Model-Based Design Toolbox for S32K3 NXP Model-Based Design Toolbox for S32K3 is the link between the Simulink model and the S32K3 microcontroller. It takes care of generating the code, building it, and running it on the target, turning the lighting model into a real embedded application. Through its peripheral blocks, the model can directly use the resources needed by the front and rear lights modules, such as DIO, CAN, and UART without leaving the Simulink environment. It also connects to the NXP configuration tools and supports FreeMASTER for real-time monitoring, which makes it easy to check how the lighting logic actually behaves on the hardware. Figure 3 - Development flow diagram 4 Required Hardware 4.1. FRDM Automotive S32K312 Development Board (FRDM-A-S32K312) The front and rear lights application runs on the FRDM Automotive S32K312 Development Board, a development platform based on the NXP S32K312 microcontroller. The board provides access to the communication interfaces and processing capabilities of the target device while offering an integrated platform for software development, debugging, and validation activities. Within the scope of this project, the board is used to execute the lighting application and exchange messages with the central controller through the CAN network. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating body electronics use cases and lighting control scenarios. Figure 4 - FRDM Automotive S32K312 Development Board 4.2. CAN analyzer Emulates the central controller when the node is not yet integrated with the full system. It injects the CAN commands defined in the DBC files (turn signals, headlight modes, hazard, brake indication, etc.) and captures the status messages sent back by the module, enabling the CAN interface and control logic to be validated in a controlled and repeatable way. 4.3. Addressable LED Strip The physical lighting output is represented by an addressable LED strip, in which each LED can be controlled individually. This makes it possible to reproduce all the relevant lighting functions on a single strip - turn signals, hazard lights, headlight modes, and brake indication - by assigning different LEDs or groups of LEDs to each function. The result is a clear visual representation of the module's behavior, making it easy to demonstrate how the control logic reacts to incoming CAN commands. 5 References Model-Based Design Toolbox (MBDT) MATLAB® and Simulink® Documentation S32K3 Microcontrollers FRDM Automotive S32K312 Development Board (FRDM-A-S32K312) 6 Conclusion This article described the software and hardware enablement required for the front and rear lights modules. The software environment combines MathWorks modeling and vehicle network capabilities with NXP target support, while the hardware environment brings together the FRDM Automotive S32K312 Development Board, a CAN analyzer, and an addressable LED strip. Together, these elements provide the foundation for modeling, simulation, communication, code generation, deployment, and validation of the lighting application. The next article will focus on the architecture and model description of the front and rear lights modules, including the control logic, CAN interfaces, and overall application structure.

在 i.MX95 NPU 上运行 yolov11n、yolov8n、yolov5nu 模型后未获得任何输出。   [i.MX95 NPU] YOLOv5n/v8n/v11n 中子转换模型运行但未返回任何探测结果（零输出） 问题描述 我正在使用 Neutron 变流器在 i.MX95 NPU 上评估 YOLO 目标检测模型。 虽然 INT8 量化的 TFLite 模型在 Cortex-A55 CPU 上运行成功并能检测到物体，但编译后的 neutron.tflite 版本在卸载到 NPU 时，尽管执行推理时没有崩溃，却产生了零检测结果（空/无输出）。 环境及硬件设置   硬件： i.MX95 19x19 LPDDR5 EVK（A1 版本） 操作系统/内核： Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) NXP 工具链： MCU-SDK v25.09.00 + Linux 6.12.34_2.1.0 测试型号： YOLOv5nu、YOLOv8n、YOLOv11n（Ultralytics） 工作流程步骤和使用的命令 1. 量化（Ultralytics 导出） 模型导出为 INT8 全整数量化格式，分辨率为 320x320： yolo export model=yolov8n.pt format=tflite int8=True imgsz=320# (Repeated identically for yolov11n.pt and yolov5nu.pt)   状态：在CPU上运行完美。yolovXn_full_integer_quant.tflite 在 A55 内核上能够正确检测对象。 2. 中子汇编 TFLite 模型是使用 MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 中的 Neutron 转换器为 i.MX95 NPU 编译的： ./neutron-converter --input yolov8n_full_integer_quant.tflite --target imx95 --output yolov8n_full_integer_quant_neutron.tflite   状态：无法在 NPU 上检测到对象。编译后的模型可以加载并运行推理，不会抛出语法或执行错误，但对于完全相同的测试图像，输出张量返回零检测结果。 观察到的症状和疑似根本原因   操作回退：变流器是否会针对特定的 YOLO 层（如自定义锚点、SiLU/Swin 激活或非最大值抑制）回退到 CPU？ 量化缩放/不对称性：通过 Ultralytics 导出的 YOLO 模型通常使用不对称量化或具有 Neutron NPU 驱动程序可能误解的特定输出张量缩放。 输出张量格式：推理运行正常，这表明输入管道没有问题，但输出边界框/分数要么为空白，要么完全是垃圾值。 向恩智浦专家提问   中子变流器是否存在针对 Ultralytics YOLO 架构的已知限制或必需的优化标志？ 在将 TFLite 模型传递给 Neutron 转换器之前，是否应该去除 NMS（非极大值抑制）层？ i.MX95 Neutron SDK 是否需要对称量化（per_channel=True 或 False）才能正确解析输出层？ 任何关于 i.MX95 NPU 的指导、参考脚本或 YOLO 部署说明都将不胜感激。   Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 嗨，亚历杭德罗， 感谢您的回复。 我认为我的硬件平台可能存在一些误解。我的问题与 i.MX91 无关。 我正在使用以下平台： 主板：i.MX95 19x19 LPDDR5 EVK（IMX95LPD5EVK-19CM，A1 版本） 开发板快速入门指南： https://www.nxp.com/docs/en/quick-reference-guide/IMX95LPD5EVK-19CM.pdf Neutron SDK：MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 内核：Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) 您分享的指南似乎是针对 i.MX91 的，而我的问题是关于在 i.MX95 Neutron NPU 上部署 YOLO。 原始的 INT8 TFLite 模型（YOLOv5nu、YOLOv8n 和 YOLOv11n）在 Cortex-A55 CPU 上运行正常，并产生有效的检测结果。然而，在使用 MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 中包含的 Neutron 变流器编译相同的模型后，推理在 NPU 上成功执行，没有任何运行时错误，但输出张量不包含任何有效检测结果。 为了便于调查，我已经将以下文件附加到我的原帖中： * 原始 INT8 量化 TFLite 模型。 * YOLOv8n 和 YOLOv11n 的中子转换 TFLite 模型。 * 一个可用于重现该问题的 Python 推理脚本。 由于这些是原始的预训练 Ultralytics 模型转换为 TFLite，因此您可以直接使用提供的脚本中的标准 COCO 类名。它应该能让你在 i.MX95 平台上重现该行为，而无需任何额外的修改。 如果您能使用附件中的文件重现该问题，并告知我这是否是当前 Neutron SDK for i.MX95 的已知限制或问题，我将不胜感激。 谢谢。 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 你好@vijayranaACL ， 感谢您联系恩智浦技术支持。 请参考本指南。 由于您使用的是 i.MX91 A1 芯片版本，因此某些特性或功能可能无法正常工作，因为 A1 是一个早期芯片版本，主要用于评估和开发目的。 因此，我们建议您在测试和验证活动中使用 i.MX91 B0 芯片版本。该指南是使用 B0 硅版本开发和验证的，因此记录的行为和结果均基于该版本。 如果可以，请确认您使用的是哪个版本的芯片，以及您是否可以获取 B0 设备进行比较。 此致， 亚历杭德罗·加西亚 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 你好@vijayranaACL ， 我已在采用 B0 芯片的 i.MX95 EVK 上测试了您的代码，在我们这边运行正常，没有任何问题。 使用 person_detect.py 应用程序，模型加载成功，Neutron 委托初始化正确，应用程序按预期执行推理。在测试过程中，我观察到稳定的目标检测和持续约 13-14 FPS 的性能。日志还证实 Neutron 代理处于活动状态，并且模型在 NPU 加速下正在正常执行。 根据这些结果，我建议升级到 B0 硅片版本。A0 和 A1 硅版本主要是为了评估和 beta 测试目的而发布的，它们没有与 B0 相同级别的软件支持和验证。早期版本之后引入了一些功能和修复，这或许可以解释您看到的情况。 以下是我的测试日志的相关部分： root@imx95evk:~# python3 person_detect.py Opening camera /dev/video52 ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Loading model and NPU delegate ... Loaded Neutron delegate: /usr/lib/libneutron_delegate.so /usr/lib/python3.13/site-packages/tflite_runtime/interpreter.py:457: UserWarning: Warning: tf.lite.Interpreter is deprecated and is scheduled for deletion in TF 2.20. Please use the LiteRT interpreter from the ai_edge_litert package. See the [migration guide](https://ai.google.dev/edge/litert/migration) for details. warnings.warn(_INTERPRETER_DELETION_WARNING) INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-d98743a7, zerocp enabled. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Model input: shape=[ 1 640 640 3] dtype= quant=(0.003921568859368563, -128) Model output[0]: shape=[ 1 84 8400] dtype= quant=(0.003906319383531809, -128) Using model input size: 640x640 Re-opening camera after model load ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Person detection running. Press Ctrl+C to stop. First frame: 640x480 Output tensor shape: (1, 84, 8400) frame=22 person conf=0.61 box=[143,8,496,476] fps=10.7 --- fps=11.5 detections=0 --- frame=39 person conf=0.58 box=[138,16,496,473] fps=12.1 frame=50 person conf=0.50 box=[138,12,496,472] fps=12.5 frame=60 person conf=0.58 box=[138,13,496,476] fps=12.8 --- fps=12.8 detections=1 --- frame=84 person conf=0.61 box=[143,10,496,475] fps=13.3 frame=85 person conf=0.54 box=[138,10,496,475] fps=13.3 frame=86 person conf=0.61 box=[138,13,496,476] fps=13.3 frame=88 person conf=0.54 box=[138,12,496,472] fps=13.3 --- fps=13.3 detections=0 --- --- fps=13.6 detections=0 --- frame=136 person conf=0.65 box=[138,13,496,476] fps=13.7 frame=139 person conf=0.58 box=[138,12,496,472] fps=13.7 frame=140 person conf=0.61 box=[136,10,498,475] fps=13.8 frame=141 person conf=0.61 box=[138,13,496,476] fps=13.8 frame=145 person conf=0.50 box=[138,13,496,476] fps=13.8 frame=146 person conf=0.65 box=[138,13,496,476] fps=13.8 frame=148 person conf=0.54 box=[138,16,496,473] fps=13.8 frame=150 person conf=0.50 box=[131,12,498,472] fps=13.8 --- fps=13.8 detections=1 --- frame=155 person conf=0.50 box=[152,32,497,472] fps=13.8 frame=156 person conf=0.71 box=[180,37,495,422] fps=13.8 frame=157 person conf=0.54 box=[182,38,497,411] fps=13.8 frame=158 person conf=0.65 box=[156,37,493,472] fps=13.8 frame=159 person conf=0.68 box=[158,42,496,472] fps=13.8 frame=160 person conf=0.61 box=[155,46,495,468] fps=13.8 frame=162 person conf=0.54 box=[156,46,493,463] fps=13.8 frame=163 person conf=0.71 box=[171,43,493,466] fps=13.8 frame=164 person conf=0.54 box=[186,41,363,353] fps=13.8 frame=165 person conf=0.61 box=[187,42,492,452] fps=13.8 frame=166 person conf=0.58 box=[190,41,495,393] fps=13.8 frame=167 person conf=0.61 box=[190,42,495,432] fps=13.8 frame=168 person conf=0.61 box=[195,38,495,426] fps=13.8 frame=169 person conf=0.50 box=[190,36,495,423] fps=13.8 frame=170 person conf=0.58 box=[198,37,496,397] fps=13.8 --- fps=13.9 detections=0 --- frame=202 person conf=0.50 box=[145,28,495,456] fps=13.9 --- fps=14.0 detections=0 --- ^CStopped. root@imx95evk:~# 由于相同的应用程序和模型在 B0 芯片上运行正常，我的建议是在继续进行进一步调试之前，使用 B0 设备重复测试，因为问题可能与芯片版本有关，而不是与应用程序本身有关。 此致， 查维拉 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 嗨，亚历杭德罗， 感谢您澄清是 i.MX 95（而非 i.MX 91）的问题，并推荐使用 --优化级别 OOpt。 我们尝试在现有配置上执行您建议的命令，但是 --优化级别 不可用 在与我们的板级 BSP 配套的中子变流器中。 我们目前的环境 元器件版本 电路板 IMX95LPD5EVK-19 BSP LF6.12.34_2.1.0 (Linux 6.12.34-lts-next ） 中子号代表已登船 v1.0.0-be8bf399 主机变流器 eIQ 工具包 1.17 → 中子变流器 2.1.3+0Xaf140cf5 变流器 电路板支持包 标签 MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 在这个变流器上， 中子转换器 --help 做 不是 列表 --优化级别。 我们实际运行的命令 中子变流器 \ --输入yolov8n_full_integer_quant.tflite \ --输出yolov8n_neutron.tflite \ --target imx95 为了进行调试，我们还使用： 中子变流器 \ --输入yolov8n_full_integer_quant.tflite \ --输出yolov8n_neutron.tflite \ --target imx95 \ --详细 我们的变流器（2.1.3）中可用的标志 关键选项  - 帮助： - 输入，  - 输出，  - 目标 --合并中子图 --将输入的 uint8 转换为 int8， --convert-outputs-uint8-to-int8 --dump-statistics， --dump-graphs， --详细 --include-between-input-tensors, --排除输入张量之间的差异 --显示目标， --show-kernel-kinds --优化级别 不存在 在这个版本上。 目前为止的测试结果 模型 NPU 行为 YOLOv8n 中子（我们的转换） 调用没问题，但是 0 次检测 YOLOv8n 无头骨干网 NPU 输出 常数（~1.13） 无头CPU主干网+CPU头部 检测结果正常 ——管道逻辑正确 问题 是 --optimization-level OOpt 仅支持较新的中子变流器 2.1.3 ？ 推荐的转换命令是什么？ LF6.12.34 / imx95 什么时候 OOpt 不可用？ Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 嗨@vijayranaACL ， 抱歉，这是我的笔误。 我指的是 i.MX95，因为 i.MX91 不包含 NPU。 我建议尝试使用以下命令转换模型： .\neutron-converter.exe ` --input " .tflite" ` --target imx95 ` --output " .tflite" ` --optimization-level OOpt 根据 Neutron SDK 文档，需要注意的是，对于 Neutron-S 靶（例如 i.MX95），变流器不是确定性的。转换过程依赖于多线程约束编程求解器，这意味着对同一模型执行变流器的不同操作可能会产生略有不同的结果，尤其是在 TCM 内存分配和生成的微代码方面。 由于可能存在多个最优解，因此在每次转换过程中，不同的求解器线程可能会收敛到不同的有效解。尽管这些解决方案内部可能有所不同，但变流器认为它们都是正确且经过优化的。在大多数情况下，这些差异不应显著影响功能或性能。 如果您观察到行为、性能或准确性方面的变化，我建议您多次转换模型并比较结果。虽然有一些方法可以强制执行确定性行为，但通常会大大增加转换时间，因此除非绝对必要，否则一般不建议使用。 请告知我您的测试结果。 此致， 亚历杭德罗·加西亚 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU 嗨，亚历杭德罗， 请您确认一下，我们讨论的代码和模型是否与FRDM-IMX95 15x15平台兼容？ 使用bsp 6.12.49_2.2.0

S32K3X8EVB-Q289 Power Supply Question I bought the S32K3X8EVB-Q289 board and need to purchase a power cable separately. Should I buy a power adapter with 12V 2A or higher? Or is there a product recommended by NXP? The FRDM-A-S32K358 uses a USB Type-C port, so it was sufficiently powered by a laptop's USB port, Re: S32K3X8EVB-Q289 Power Supply Question Hello @wj_kwak, Yes, as noted inside the S32K3X8 EVB HW UM, you can use any external power supply as long as it provides +12V/≥2A; Best regards, Julián

V5705芯片 您好，我有一台适用于Clio 5汽车的收音机。它采用的是恩智浦V5707芯片。但我没有找到这款芯片的任何技术规格。这款芯片属于哪个TEF系列？（例如TEF6686、TEF6687、TEF6688、TEF6689等） 标记 = v5705 54 10 sSD1462

AUTOSAR MCAL for MPC5744P 大家好， 我正在使用 MPC5744P 和生成的 AUTOSAR MCAL 包。 我遇到了一个版本错误： 没有找到该文件或目录——指的是 Os_memmap.h在 MemMap.h 中： #ifndef AUTOSAR_OS_NOT_USED #include "Os_memmap.h" #endif 但是，生成的文件中没有 Os_memmap.h 文件。 我该如何找回这个丢失的文件？ 另外，如何使用 EB tresos 配置和生成新的 MCAL 包（或重新生成缺失的部分）？ 非常感谢您的帮助！ 谢谢！ Re: AUTOSAR MCAL for MPC5744P 您好@petervlna ，请问是否有免费的编译器选项可以用来构建适用于 MPC5744P 的 AUTOSAR MCAL 应用程序？ Re: AUTOSAR MCAL for MPC5744P 你好， 您可以使用生成的代码，并将其编译为 GHS 或 DIAB。 请务必参考 RTD 和 OS 发行说明中列出的受支持的编译器。 顺祝商祺！ Peter Re: AUTOSAR MCAL for MPC5744P 嗨，彼得， 谢谢你的解释！ 请问：是否可以使用 GCC 编译生成的代码（来自 Tresos + MCAL），还是必须使用 S32DS 或 GHS 等工具链？ 此致， 伟大的 Re: AUTOSAR MCAL for MPC5744P 你好， 我该如何找回这个丢失的文件？ 它不是 MCAL 生成的文件的一部分，而是来自 Tresos 操作系统配置。 我认为可能是操作系统配置出了问题。 另请参阅此处： https://community.nxp.com/t5/S32K/No-such-file-or-directory-include-quot-Os-memmap-h-quot/td-p/1818413 另外，如何使用 EB tresos 配置和生成新的 MCAL 包（或重新生成缺失的部分）？ 嗯，我们为此提供 S32 设计工作室。如需了解 Tresos 的相关培训，请联系 Elektrobit。 其实应该很简单。安装 MCAL 后，您只需创建项目，添加所需的插件，然后从 Tresos 生成 c/h 文件。然后，您需要将项目整理到 S32DS、GHS 等项目管理软件中，以便进行编译。 顺祝商祺！ Peter

S32K3X8EVB-Q289 電源に関する質問 S32K3X8EVB-Q289ボードを購入しましたが、電源ケーブルは別途購入する必要があります。12V 2A以上の電源アダプターを購入すべきでしょうか？それともNXPが推奨する製品はありますか? FRDM-A-S32K358はUSB Type-Cポートを使用しているため、ノートPCのUSBポートで十分な電力を供給していました。 Re: S32K3X8EVB-Q289 Power Supply Question こんにちは、 @wj_kwak さん、 はい、S32K3X8 EVB HW UMの中に記載されている通り、+12V/≥2Aを供給する外部電源ならどんなものでも使えます。 よろしくお願いします、 ジュリアン

yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU   [i.MX95 NPU] YOLOv5n/v8n/v11n Neutron-converted Models Run but Return No Detections (Zero Output) Issue Description I am evaluating YOLO object detection models on the i.MX95 NPU using the Neutron converter. While the INT8 quantized TFLite models run successfully and detect objects on the Cortex-A55 CPU, the compiled neutron.tflite versions yield zero detections (empty/no output) when offloaded to the NPU, despite executing inference without crashing. Environment & Hardware Setup   Hardware: i.MX95 19x19 LPDDR5 EVK (A1 Revision) OS/Kernel: Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) NXP Toolchain: MCU-SDK v25.09.00 + Linux 6.12.34_2.1.0 Models Tested: YOLOv5nu, YOLOv8n, YOLOv11n (Ultralytics) Workflow Steps & Commands Used 1. Quantization (Ultralytics Export) Models were exported to INT8 full integer quantization with a 320x320 resolution: yolo export model=yolov8n.pt format=tflite int8=True imgsz=320# (Repeated identically for yolov11n.pt and yolov5nu.pt)   Status: Works perfectly on CPU. yolovXn_full_integer_quant.tflite detects objects correctly on the A55 cores. 2. Neutron Compilation The TFLite models were compiled for the i.MX95 NPU using the Neutron converter from MCU_SDK_25.09.00+Linux_6.12.34_2.1.0: ./neutron-converter --input yolov8n_full_integer_quant.tflite --target imx95 --output yolov8n_full_integer_quant_neutron.tflite   Status: Fails to detect objects on NPU. The compiled model loads and runs inference without throwing syntax or execution errors, but output tensors return zero detections for the exact same test images. Observed Symptoms & Suspected Root Causes   Operator Fallbacks: Did the converter fall back to CPU for specific YOLO layers (like custom Anchors, SiLU/Swin activations, or Non-Max Suppression)? Quantization Scaling/Asymmetry: YOLO models exported via Ultralytics often use asymmetric quantization or have specific output tensor scaling that the Neutron NPU driver might misinterpret. Output Tensor Formatting: The inference runs, which suggests the input pipeline is fine, but the output bounding boxes/scores are either blank or completely garbage values. Questions for NXP Experts   Are there known limitations or mandatory optimization flags needed in the neutron-converter specifically for Ultralytics YOLO architectures? Should the NMS (Non-Max Suppression) layer be stripped out before passing the TFLite model to the Neutron converter? Does the i.MX95 Neutron SDK require symmetric quantization (per_channel=True or False) to parse the output layers properly? Any guidance, reference scripts, or working YOLO deployment notes for the i.MX95 NPU would be highly appreciated.   Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU Hi Alejandro, Thank you for your response. I believe there may be a misunderstanding regarding my hardware platform. My issue is not related to the i.MX91. I am using the following platform: Board: i.MX95 19x19 LPDDR5 EVK (IMX95LPD5EVK-19CM, A1 Revision) Board Quick Start Guide: https://www.nxp.com/docs/en/quick-reference-guide/IMX95LPD5EVK-19CM.pdf Neutron SDK: MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 Kernel: Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) The guide you shared appears to be for the i.MX91, whereas my question is specifically about YOLO deployment on the i.MX95 Neutron NPU. The original INT8 TFLite models (YOLOv5nu, YOLOv8n, and YOLOv11n) run correctly on the Cortex-A55 CPU and produce valid detections. However, after compiling the same models using the Neutron converter included in MCU_SDK_25.09.00+Linux_6.12.34_2.1.0, inference executes successfully on the NPU without any runtime errors, but the output tensors contain no valid detections. For easier investigation, I have already attached the following files to my original post: * Original INT8 quantized TFLite models. * Neutron-converted TFLite models for YOLOv8n and YOLOv11n. * A Python inference script that can be used to reproduce the issue. Since these are the original pretrained Ultralytics models converted to TFLite, you can use the standard COCO class names directly with the provided script. It should allow you to reproduce the behavior on your i.MX95 platform without requiring any additional modifications. I would appreciate it if you could reproduce the issue using the attached files and let me know whether this is a known limitation or issue with the current Neutron SDK for the i.MX95. Thank you. Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU Hi @vijayranaACL, Thank you for contacting NXP Support. Please refer to this guide. Since you are using the i.MX91 A1 silicon revision, it is possible that some features or functionality may not operate correctly, as A1 is an early silicon revision intended primarily for evaluation and development purposes. For this reason, we recommend using the i.MX91 B0 silicon revision for your testing and validation activities. The guide was developed and validated using the B0 silicon version, so the documented behavior and results are based on that revision. If possible, please confirm which silicon revision you are using and whether you have access to a B0 device for comparison. Best regards, Alejandro Garcia Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU Hi Alejandro, Thank you for the clarification regarding i.MX 95 (not i.MX 91) and for the recommendation to use --optimization-level OOpt. We tried to follow your suggested command on our current setup, but --optimization-level is not available in the neutron-converter paired with our board BSP. Our current environment Component Version Board IMX95LPD5EVK-19 BSP LF6.12.34_2.1.0 (Linux 6.12.34-lts-next) Neutron delegate on board v1.0.0-be8bf399 Host converter eIQ Toolkit 1.17 → neutron-converter 2.1.3+0Xaf140cf5 Converter BSP tag MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 On this converter, neutron-converter --help does not list --optimization-level. Command we actually run neutron-converter \ --input yolov8n_full_integer_quant.tflite \ --output yolov8n_neutron.tflite \ --target imx95 For debugging we also use: neutron-converter \ --input yolov8n_full_integer_quant.tflite \ --output yolov8n_neutron.tflite \ --target imx95 \ --verbose Flags available on our converter (2.1.3) Key options from --help: --input, --output, --target --merge-neutron-graphs --convert-inputs-uint8-to-int8, --convert-outputs-uint8-to-int8 --dump-statistics, --dump-graphs, --verbose --include-between-input-tensors, --exclude-between-input-tensors --show-targets, --show-kernel-kinds --optimization-level is not present on this build. Test results so far Model NPU behaviour YOLOv8n Neutron (our conversion) Invoke OK, but 0 detections YOLOv8n headless backbone NPU output constant (~1.13) Headless CPU backbone + CPU head Detections OK — pipeline logic is correct Questions Is --optimization-level OOpt only supported in a newer neutron-converter than 2.1.3? What is the recommended conversion command for LF6.12.34 / imx95 when OOpt is not available? Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU HI @vijayranaACL, Sorry, that was a typo on my side. I was referring to the i.MX95, since the i.MX91 does not include an NPU. I recommend trying the following command to convert the model: .\neutron-converter.exe ` --input " .tflite" ` --target imx95 ` --output " .tflite" ` --optimization-level OOpt According to the Neutron SDK documentation, it is important to note that the converter is not deterministic for Neutron-S targets such as the i.MX95. The conversion process relies on multithreaded constrained programming solvers, which means that different executions of the converter on the same model may produce slightly different results, particularly regarding TCM memory allocation and generated microcode. Because multiple optimal solutions may exist, different solver threads can converge on different valid solutions during each conversion. Although these solutions may differ internally, they are all considered correct and optimized by the converter. In most cases, these differences should not significantly affect functionality or performance. If you observe variations in behavior, performance, or accuracy, I recommend converting the model multiple times and comparing the results. There are methods available to force deterministic behavior, but they typically increase conversion time considerably and are generally not recommended unless strictly required. Please let me know the outcome of your tests. Best regards, Alejandro Garcia Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU Hi @vijayranaACL, I have tested your code on an i.MX95 EVK with B0 silicon, and it appears to be working correctly on our side without any issues. Using your person_detect.py application, the model loads successfully, the Neutron delegate is initialized correctly, and the application performs inference as expected. During testing, I observed stable object detection and a sustained performance of approximately 13–14 FPS. The logs also confirm that the Neutron delegate is active and that the model is executing properly with NPU acceleration. Based on these results, I recommend moving to the B0 silicon revision. The A0 and A1 silicon versions were released primarily for evaluation and beta testing purposes, and they do not have the same level of software support and validation as B0. Several features and fixes were introduced after the early revisions, which may explain the behavior you are seeing. The relevant portion of my test log is shown below: root@imx95evk:~# python3 person_detect.py Opening camera /dev/video52 ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Loading model and NPU delegate ... Loaded Neutron delegate: /usr/lib/libneutron_delegate.so /usr/lib/python3.13/site-packages/tflite_runtime/interpreter.py:457: UserWarning: Warning: tf.lite.Interpreter is deprecated and is scheduled for deletion in TF 2.20. Please use the LiteRT interpreter from the ai_edge_litert package. See the [migration guide](https://ai.google.dev/edge/litert/migration) for details. warnings.warn(_INTERPRETER_DELETION_WARNING) INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-d98743a7, zerocp enabled. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Model input: shape=[ 1 640 640 3] dtype= quant=(0.003921568859368563, -128) Model output[0]: shape=[ 1 84 8400] dtype= quant=(0.003906319383531809, -128) Using model input size: 640x640 Re-opening camera after model load ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Person detection running. Press Ctrl+C to stop. First frame: 640x480 Output tensor shape: (1, 84, 8400) frame=22 person conf=0.61 box=[143,8,496,476] fps=10.7 --- fps=11.5 detections=0 --- frame=39 person conf=0.58 box=[138,16,496,473] fps=12.1 frame=50 person conf=0.50 box=[138,12,496,472] fps=12.5 frame=60 person conf=0.58 box=[138,13,496,476] fps=12.8 --- fps=12.8 detections=1 --- frame=84 person conf=0.61 box=[143,10,496,475] fps=13.3 frame=85 person conf=0.54 box=[138,10,496,475] fps=13.3 frame=86 person conf=0.61 box=[138,13,496,476] fps=13.3 frame=88 person conf=0.54 box=[138,12,496,472] fps=13.3 --- fps=13.3 detections=0 --- --- fps=13.6 detections=0 --- frame=136 person conf=0.65 box=[138,13,496,476] fps=13.7 frame=139 person conf=0.58 box=[138,12,496,472] fps=13.7 frame=140 person conf=0.61 box=[136,10,498,475] fps=13.8 frame=141 person conf=0.61 box=[138,13,496,476] fps=13.8 frame=145 person conf=0.50 box=[138,13,496,476] fps=13.8 frame=146 person conf=0.65 box=[138,13,496,476] fps=13.8 frame=148 person conf=0.54 box=[138,16,496,473] fps=13.8 frame=150 person conf=0.50 box=[131,12,498,472] fps=13.8 --- fps=13.8 detections=1 --- frame=155 person conf=0.50 box=[152,32,497,472] fps=13.8 frame=156 person conf=0.71 box=[180,37,495,422] fps=13.8 frame=157 person conf=0.54 box=[182,38,497,411] fps=13.8 frame=158 person conf=0.65 box=[156,37,493,472] fps=13.8 frame=159 person conf=0.68 box=[158,42,496,472] fps=13.8 frame=160 person conf=0.61 box=[155,46,495,468] fps=13.8 frame=162 person conf=0.54 box=[156,46,493,463] fps=13.8 frame=163 person conf=0.71 box=[171,43,493,466] fps=13.8 frame=164 person conf=0.54 box=[186,41,363,353] fps=13.8 frame=165 person conf=0.61 box=[187,42,492,452] fps=13.8 frame=166 person conf=0.58 box=[190,41,495,393] fps=13.8 frame=167 person conf=0.61 box=[190,42,495,432] fps=13.8 frame=168 person conf=0.61 box=[195,38,495,426] fps=13.8 frame=169 person conf=0.50 box=[190,36,495,423] fps=13.8 frame=170 person conf=0.58 box=[198,37,496,397] fps=13.8 --- fps=13.9 detections=0 --- frame=202 person conf=0.50 box=[145,28,495,456] fps=13.9 --- fps=14.0 detections=0 --- ^CStopped. root@imx95evk:~# Since the same application and model work correctly on B0 silicon, my recommendation is to repeat the test using a B0 device before continuing with further debugging, as the issue may be related to the silicon revision rather than the application itself. Best Regards, Chavira Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU Hi Alejandro, Could you please confirm that the code and models we discussed are compatible with the FRDM-IMX95 15x15 platform? with bsp 6.12.49_2.2.0

yolov11n、yolov8n、yolov5nuモデルでi.MX95 NPUを使用しても出力が出ません   [i.MX95 NPU]YOLOv5n/v8n/v11n Neutron変換モデルは動作しますが検出なし(出力ゼロ) 問題の説明 私はNeutronコンバーターを使ってi.MX95 NPU上のYOLO物体検出モデルを評価しています。 INT8量子化されたTFLiteモデルはCortex-A55 CPU上で正常に動作しオブジェクトを検出しますが、コンパイルされたneutron.tflite版は、推論をクラッシュせずに実行しても、NPUにオフロードしても検出ゼロ(空/出力なし)ができません。 環境およびハードウェアのセットアップ   ハードウェア： i.MX95 19x19 LPDDR5 EVK（A1リビジョン） OS/カーネル: Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) NXPツールチェーン: MCU-SDK v25.09.00 + Linux 6.12.34_2.1.0 テストされたモデル: YOLOv5nu、YOLOv8n、YOLOv11n(ウルトラリティクス) ワークフローの手順と使用されるコマンド 1. 量子化（Ultralyticsエクスポート） モデルはINT8のフル整数量子化で320x320解像度でエクスポートされました。 yolo export model=yolov8n.pt format=tflite int8=True imgsz=320# (Repeated identically for yolov11n.pt and yolov5nu.pt)   状態： CPU上で完全に動作します。yolovXn_full_integer_quant.tflite は、A55 コア上でオブジェクトを正しく検出します。 2. Neutron 編纂 TFLiteモデルは、Neutronコンバータを用いてi.MX95 NPU向けにMCU_SDK_25.09.00+Linux_6.12.34_2.1.0でコンパイルされました: ./neutron-converter --input yolov8n_full_integer_quant.tflite --target imx95 --output yolov8n_full_integer_quant_neutron.tflite   状態： NPU上のオブジェクトを検出できませんでした。コンパイルされたモデルは構文や実行エラーを投げることなく推論を読み込み実行しますが、出力テンソルはまったく同じテスト画像に対して検出をゼロ返します。 観察された症状と疑われる根本原因   オペレーターの代替手段: コンバーターは特定のYOLOレイヤー(カスタムアンカー、SiLU/Swinのアクティベーション、Non-Max Suppressionなど)でCPUにフォールバックしましたか? 量子化のスケーリング/非対称性: Ultralytics経由でエクスポートされるYOLOモデルは、しばしば非対称量子化を用いたり、特定の出力テンソルスケーリングを用いており、Neutron NPUドライバーが誤解することがあります。 出力テンソルのフォーマット：推論は実行されるため、入力パイプラインは問題ないと思われますが、出力バウンディングボックス/スコアが空白であるか、完全にゴミ値になっています。 NXPのエキスパートへの質問   Ultralytics YOLOアーキテクチャ特有のNeutron変換器には既知の制限や必須の最適化フラグはありますか? TFLiteモデルをNeutronコンバーターに渡す前に、NMS(Non-Max Suppression)レイヤーを取り除くべきでしょうか? i.MX95 Neutron SDKは、出力層を正しく解析するために対称量子化(per_channel=TrueまたはFalse)を必要としますか? i.MX95 NPU向けのガイダンス、リファレンススクリプト、またはYOLOの導入に関する作業手順書などがあれば、大変ありがたいです。   Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、アレハンドロさん。 ご回答ありがとうございます。 私のハードウェアプラットフォームについて誤解があるのではないかと思います。私の問題はi.MX91とは関係ありません。 私は以下のプラットフォームを使っています: 基板:i.MX95 19x19 LPDDR5 EVK(IMX95LPD5EVK-19CM、A1リビジョン) ボードクイックスタートガイド: https://www.nxp.com/docs/en/quick-reference-guide/IMX95LPD5EVK-19CM.pdf Neutron SDK: MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 カーネル: Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) あなたが共有したガイドはi.MX91向けのようですが、私の質問はi.MX95 Neutron NPUでのYOLO展開についてです。 オリジナルのINT8 TFLiteモデル(YOLOv5nu、YOLOv8n、YOLOv11n)はCortex-A55 CPU上で正しく動作し、有効な検出結果を生み出します。しかし、同じモデルをMCU_SDK_25.09.00+Linux_6.12.34_2.1.0に含まれるNeutron コンバータでまとめた後、推論はNPU上で実行時エラーなく正常に実行されるが、出力テンソルには有効な検出結果が含まれない。 調査を容易にするために、すでに元の投稿に以下のファイルを添付しています: * オリジナルのINT8量子化されたTFLiteモデル。 * YOLOv8nおよびYOLOv11n向けの中性子変換TFLiteモデル。 * 問題を再現するために使えるPython推論スクリプト。 これらは元の事前学習済みUltralyticsモデルをTFLiteに変換したものなので、標準のCOCOクラス名を提供されたスクリプトで直接使用できます。追加の修正なしでi.MX95プラットフォーム上で同じ動作を再現できるはずです。 添付ファイルを使って問題を再現していただけるとありがたいです。また、これがi.MX95の現行Neutron SDKの既知の制限か、あるいは問題なのか教えていただけると助かります。 ありがとう。 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは@vijayranaACL。 NXPサポートまでご連絡いただきありがとうございます。 このガイドを参照してください。 お客様が使用されているのはi.MX91 A1シリコンリビジョンであるため、A1は主に評価および開発目的を意図した初期のシリコンリビジョンであり、一部の機能が正しく動作しない可能性があります。 そのため、テストおよび検証作業には、i.MX91 B0シリコンリビジョンを使用することをお勧めします。このガイドはB0シリコン版を用いて作成・検証されたため、文書化された挙動と結果はその改訂版に基づいています。 可能であれば、どのシリコンリビジョンを使っているか、そして比較のためにB0デバイスにアクセスできるかを確認してください。 よろしくお願いします、 アレハンドロ・ガルシア Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、 @vijayranaACL さん。 すみません、私の入力ミスでした。 私が言及していたのはi.MX95のことです。i.MX91にはNPUが搭載されていないからです。 モデル変換には以下のコマンドを試してみることをおすすめします: .\neutron-converter.exe ` --input " .tflite" ` --target imx95 ` --output " .tflite" ` --optimization-level OOpt Neutron SDKのドキュメントによると、コンバータはi.MX95のようなNeutron-Sターゲットに対してデターミニスティックではないことに注意が必要です。変換プロセスはマルチスレッド制約付きプログラミングソルバーに依存しているため、同じモデル上でコンバータを実行する場合、特にTCMメモリ割り当てや生成されたマイクロコードに関してわずかに異なる結果が生じることがあります。 複数の最適解が存在する可能性があるため、異なるソルバースレッドが各変換時に異なる有効な解に収束することがあります。これらの解は内部的に異なる場合がありますが、すべてコンバーターによって正しく最適化されています。ほとんどの場合、これらの違いは機能性や性能に大きな影響を与えることはありません。 挙動、性能、精度にばらつきが見られた場合は、モデルを複数回変換して結果を比較することをお勧めします。デターミニスティックな振る舞いを強制する方法は存在しますが、通常は変換時間が大幅に長くなり、厳密に必要でない限り推奨されません。 検査結果をお知らせください。 よろしくお願いします、 アレハンドロ・ガルシア Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、アレハンドロさん。 i.MX 95（i.MX 91ではない）に関する説明と、使用に関する推奨事項をありがとうございます。 --最適化レベル OOpt。 現在のセットアップであなたの提案されたコマンドに従おうとしましたが、Neutron-コンバーターとボードBSPを組み合わせたところ --optimization-level は利用できません 利用できません 。 現在の環境 コンポーネントバージョン ボード IMX95LPD5EVK-19 BSP LF6.12.34_2.1.0 (Linux 6.12.34-lts-next) Neutron 代表乗船中 v1.0.0-be8bf399 ホストコンバータ eIQツールキット 1.17 → Neutron-converter 2.1.3+0Xaf140cf5 コンバーターBSPタグ MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 このコンバーターでは、 中性子コンバーター――help does not list ―最適化レベル。 実際に実行するコマンド Neutron-converter \ --input yolov8n_full_integer_quant.tflite \ --output yolov8n_neutron.tflite \ --ターゲットimx95 デバッグには、以下のツールも使用します。 Neutron-converter \ --input yolov8n_full_integer_quant.tflite \ --output yolov8n_neutron.tflite \ --ターゲットimx95 \ --詳細表示 当社のコンバーター(2.1.3)で利用可能なフラグ 主なオプション  - ヘルプ： - 入力、  - 出力、  - ターゲット --合一Neutronグラフ --入力値をuint8からint8に変換、 --出力をuint8からint8に変換 --ダンプ統計、 --ダンプグラフ、 --詳細表示 --入力テンソル間のインクルード、 --入力テンソル間の除外 --ターゲットを表示、 --カーネルの種類を表示 --最適化レベル 存在しません このビルドでは。 これまでの検査結果 モデルNPUの挙動 YOLOv8n Neutron (我々の変換) 呼び出しOKですが 検出数：0 YOLOv8n ヘッドレスバックボーン NPU出力 定数（約1.13） ヘッドレスCPUバックボーン＋CPUヘッド 検出は正常です — パイプラインのロジックは正しい 質問 最適化レベルのOOpt は 2.1.3 よりも新しいNeutronコンバーターでしかサポートされていないのでしょうか? 推奨される変換コマンドは何ですか？ LF6.12.34 / imx95 いつ OOpt 利用できませんか？ Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、 @vijayranaACL さん。 B0シリコンを搭載したi.MX95 EVKであなたのコードをテストしましたが、こちら側では問題なく正常に動作しているようです。 person_detect.pyアプリケーションを使うと、モデルは正常に読み込まれ、Neutronデリゲートは正しく初期化され、アプリケーションは予想通りの推論を実行します。テスト中、安定した物体検出と、約13～14 FPSの持続的なパフォーマンスを確認しました。ログはまた、Neutron delegateがアクティブであり、モデルがNPU加速で正しく動作していることも確認しています。 これらの結果に基づき、B0シリコンリビジョンへの移行を推奨します。A0およびA1シリコン版は主に評価およびベータテスト目的でリリースされており、B0ほどのソフトウェアサポートや検証レベルが整っていません。初期の改訂版以降、いくつかの機能追加や修正が行われており、それがお客様が経験されている動作の原因となっている可能性があります。 私のテストログの関連部分を以下に示します。 root@imx95evk:~# python3 person_detect.py Opening camera /dev/video52 ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Loading model and NPU delegate ... Loaded Neutron delegate: /usr/lib/libneutron_delegate.so /usr/lib/python3.13/site-packages/tflite_runtime/interpreter.py:457: UserWarning: Warning: tf.lite.Interpreter is deprecated and is scheduled for deletion in TF 2.20. Please use the LiteRT interpreter from the ai_edge_litert package. See the [migration guide](https://ai.google.dev/edge/litert/migration) for details. warnings.warn(_INTERPRETER_DELETION_WARNING) INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-d98743a7, zerocp enabled. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Model input: shape=[ 1 640 640 3] dtype= quant=(0.003921568859368563, -128) Model output[0]: shape=[ 1 84 8400] dtype= quant=(0.003906319383531809, -128) Using model input size: 640x640 Re-opening camera after model load ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Person detection running. Press Ctrl+C to stop. First frame: 640x480 Output tensor shape: (1, 84, 8400) frame=22 person conf=0.61 box=[143,8,496,476] fps=10.7 --- fps=11.5 detections=0 --- frame=39 person conf=0.58 box=[138,16,496,473] fps=12.1 frame=50 person conf=0.50 box=[138,12,496,472] fps=12.5 frame=60 person conf=0.58 box=[138,13,496,476] fps=12.8 --- fps=12.8 detections=1 --- frame=84 person conf=0.61 box=[143,10,496,475] fps=13.3 frame=85 person conf=0.54 box=[138,10,496,475] fps=13.3 frame=86 person conf=0.61 box=[138,13,496,476] fps=13.3 frame=88 person conf=0.54 box=[138,12,496,472] fps=13.3 --- fps=13.3 detections=0 --- --- fps=13.6 detections=0 --- frame=136 person conf=0.65 box=[138,13,496,476] fps=13.7 frame=139 person conf=0.58 box=[138,12,496,472] fps=13.7 frame=140 person conf=0.61 box=[136,10,498,475] fps=13.8 frame=141 person conf=0.61 box=[138,13,496,476] fps=13.8 frame=145 person conf=0.50 box=[138,13,496,476] fps=13.8 frame=146 person conf=0.65 box=[138,13,496,476] fps=13.8 frame=148 person conf=0.54 box=[138,16,496,473] fps=13.8 frame=150 person conf=0.50 box=[131,12,498,472] fps=13.8 --- fps=13.8 detections=1 --- frame=155 person conf=0.50 box=[152,32,497,472] fps=13.8 frame=156 person conf=0.71 box=[180,37,495,422] fps=13.8 frame=157 person conf=0.54 box=[182,38,497,411] fps=13.8 frame=158 person conf=0.65 box=[156,37,493,472] fps=13.8 frame=159 person conf=0.68 box=[158,42,496,472] fps=13.8 frame=160 person conf=0.61 box=[155,46,495,468] fps=13.8 frame=162 person conf=0.54 box=[156,46,493,463] fps=13.8 frame=163 person conf=0.71 box=[171,43,493,466] fps=13.8 frame=164 person conf=0.54 box=[186,41,363,353] fps=13.8 frame=165 person conf=0.61 box=[187,42,492,452] fps=13.8 frame=166 person conf=0.58 box=[190,41,495,393] fps=13.8 frame=167 person conf=0.61 box=[190,42,495,432] fps=13.8 frame=168 person conf=0.61 box=[195,38,495,426] fps=13.8 frame=169 person conf=0.50 box=[190,36,495,423] fps=13.8 frame=170 person conf=0.58 box=[198,37,496,397] fps=13.8 --- fps=13.9 detections=0 --- frame=202 person conf=0.50 box=[145,28,495,456] fps=13.9 --- fps=14.0 detections=0 --- ^CStopped. root@imx95evk:~# 同じアプリケーションとモデルがB0シリコン上で正常に動作するため、問題はアプリケーション自体ではなくシリコンリビジョンに関連している可能性があるため、さらなるデバッグを続ける前にB0デバイスでテストを繰り返し行うことをお勧めします。 よろしくお願いします、 チャビラ Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、アレハンドロさん。 私たちが話したコードとモデルが FRDM-IMX95 15x15 プラットフォームと互換性があるか確認していただけますか? bsp 6.12.49_2.2.0 を使用

V5705 Chip Hi, I have got radio for Clio 5 car. It's have V5707 nxp chip. But i didnt find any technical spec for this chip. Which tef series does this chip belong to? (tef6686, tef6687, tef6688, tef6689 etc) marked = v5705 54 10 sSD1462 

S32K3X8EVB-Q289 电源问题 我购买了S32K3X8EVB-Q289主板，还需要单独购买电源线。我应该购买12V 2A或更高规格的电源适配器吗？或者恩智浦半导体有没有推荐的产品？ FRDM-A-S32K358 使用 USB Type-C 接口，因此可以通过笔记本电脑的 USB 接口供电。 Re: S32K3X8EVB-Q289 Power Supply Question 你好@wj_kwak ， 是的，正如 S32K3X8 EVB HW UM 中所述，只要外部电源提供 +12V/≥2A，您就可以使用它； 此致， 朱利安

AUTOSAR MCAL for MPC5744P Hello everyone, I'm working with the MPC5744P and using the generated AUTOSAR MCAL packages. I'm encountering a build error: No such file or directory — referring to Os_memmap.h inside MemMap.h: #ifndef AUTOSAR_OS_NOT_USED       #include "Os_memmap.h" #endif However, Os_memmap.h is not present in the generated files. How can I get this missing file? Also, how can I use EB tresos to configure and generate a new MCAL package (or regenerate the missing parts)? Any help would be appreciated! Thank you. Re: AUTOSAR MCAL for MPC5744P Hello @petervlna , is there any free compiler option to build the AUTOSAR MCAL applications for MPC5744P? Re: AUTOSAR MCAL for MPC5744P Hello, You can use the generated code and compile it in GHS or DIAB. Always refer to supported compilators in release notes of the RTD and OS. Best regards, Peter Re: AUTOSAR MCAL for MPC5744P Hi Peter, Thank you for the clarification! Just a quick question: Is it possible to compile the generated code (from Tresos + MCAL) using GCC, or is it mandatory to use toolchains like S32DS or GHS? Best regards, El-Greatly Re: AUTOSAR MCAL for MPC5744P Hello, How can I get this missing file? It is not part of generated files of MCAL but from the Tresos OS configuration. In my opinion probably there was something wrong in OS configuration. Have a look also here: https://community.nxp.com/t5/S32K/No-such-file-or-directory-include-quot-Os-memmap-h-quot/td-p/1818413 Also, how can I use EB tresos to configure and generate a new MCAL package (or regenerate the missing parts)? Hmm, we offer S32 design studio for such. For trainings on Tresos please get in touch with Elektrobit. Actually it should be very simple. Once you install MCAL you will simply create project, add desired pluggins and generate the c/h files from tresos. Then you will put the project together in some project manager like S32DS, GHS, etc... to be able to compile it. Best regards, Peter

MIPIセンサからのフレームデータの破損 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> MIPIのOmniVision OS05A20センサを使用しています。 imx6sベースのボードが破損したフレームを受信しました。 イメージセンサーにテストパターンを起動しました。フレームサイズは640×480です。ピクセル値は0x00または0xFFである必要があります。 想定されるフレーム: 受信した画像: 予想フレームはOmniVisionセンサー評価ボードに記録されました。 興味深いことに、破損したフレームでは、480個の要素のうち約355個しか埋められていない。期待されるフレームでは、行内の隣接するピクセルが0xFFと0x00を交互に繰り返します。コロップフレームでは、同じピクセルが8つずつグループに入り、他のピクセルがドロップした場合と同じ値を持っています。後半部分では、ピクセルの破損の仕方が少し異なる。 両方のセンサはレーン数以外は同じ構成で動作しており、評価ボードは4レーン、私のボードは2レーンです。 センサーのMIPIは544Mbps、内部ピクセルクロックは68MHzで動作しています。 MIPI_CSI_PHY_TST_CTRL1は0x14（800～850MHz）に設定されます。 これは、すべてのピクセルが飽和状態になった実際のピクセル読み出しフレームです（カメラレンズは取り外されています）。 この問題の原因について何かアイデアはありますか? よろしくお願いします。 i.MX6S Re: Corrupt frame data from MIPI sensor ドライバーがフレーム開始を逃す原因になったことは、@gennadiykiryukh見つかりましたか?私もOmnivisionセンサで似たような現象を経験しています。 Re: Corrupt frame data from MIPI sensor <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> >OmniVisionセンサに設定が必要なものはありますか?この件についてもっと知っている方はいらっしゃいますか? セクション6.1.2を見てみましょうOmnivision Camera i.MX Linux リファレンスマニュアル ドライバー/メディア/プラットフォーム/MXC/キャプチャ/ov5640_mipi.Cでサポートされているフォーマット よろしくお願いします イゴール Re: Corrupt frame data from MIPI sensor <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 既にその項で説明されている通りにクロック周波数を確認済みです。画像センサ内のPLLは、センサのPHY CLKが544MHzに設定されています。MIPI_CSI_PHY_TST_CTRL1レジスタは0x14に設定され、これは849MHzに相当します。セクション3.4の最初の式によると… MIPIデータレート = (MIPIクロック * 2) * レーン数 >= ピクセルクロック * ピクセルあたりのビット数 MIPIクロックは最小値以上である必要があります。私の場合は時間がずっと長かったです。センサーのクロックに近い値(0x2E、600MHz)に設定しようとしましたが、同じ結果でした。悪い信号の可能性を完全に排除するわけではありませんが、破損パターンは非常に再現可能で、バイトシーケンスを抽出して画像の一部を再構築できるほどです。 フレームの性質を解明するために、カメラの水平視野の半分をカバーして「ハーフフレーム」を取得しました。良いフレームであれば、左半分は暗く、右半分は明るく（彩度が高く）なり、彩度は640ピクセルごと（新しい行ごとに）繰り返されるだろう。破損した画像では、彩度が入っていないピクセルが160ピクセルごとに繰り返され、幅の4分の1にあたります。また、そのデータピクセルの流れは、144個の黒いピクセルの連続によって中断される。実際のデータ288ピクセルごとにピクセルストリームが中断されるようです。 「破損」のパターンは、約240行後に変化するようです。その後、汚職の発生頻度は2倍に増加する。彩度パターンは現在80ピクセルで、黒ピクセルバーストの長さは72ピクセルです。 フレームの半分を過ぎたあたりで画像データが圧縮されているのを見たことがあるのは、YUV422とYUV420フォーマットだけです。それは関係があるのでしょうか?センサはバイヤーフォーマットです。 考えられる可能性の一つは、受信側がデータを「理解」するのに苦労しているということだ。上記文書の表1では、パケットを定義するために使用されるデータ型について説明しています。プロセッサが期待する実際の値は一覧にされていません。これはOmniVisionセンサが設定する必要があるものでしょうか?この件についてもっと詳しい情報をお持ちの方はいらっしゃいますか？ Re: Corrupt frame data from MIPI sensor <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、ゲンナジー データ破損の問題については、以下のクロック設定を考慮することができます。 セクション3.4MIPI D-PHYクロック AN5305 MIPI–CSI2 ペリフェラル(i.MX6 MPU搭載) よろしくお願いします イゴール ----------------------------------------------------------------------------------------------------------------------- 注：この記事があなたの質問への回答になっている場合は、「正解」ボタンをクリックしてください。ありがとう！ -----------------------------------------------------------------------------------------------------------------------

LLCE_CAN/LIN(MCALドライバー)をS32DS 3.4に統合するが、S32 DSのビルドエラーがある こんにちは、みんな、 「INTEGR LLCE_CAN/LIN(MCAL DRIVER) TO S32DS 3.4」というドキュメントに従うと、いくつか問題が発生しました。 プロジェクトを構築してみたところ、ドキュメントほど成功しませんでした。 エラーは以下のとおりです。 説明 リソース パス 場所 タイプ #エラー "MemMap.h、有効なメモリマッピングシンボルが定義されていません。LLCE_CAN_LIN_M7_0 12754行、外部位置:D:\NXP\S32DS.3.4\S32DS\software\PlatformSDK_S32XX_2022_03\SW32_RTD_4_4_3_0_2_D2203\Base_TS_T40D11M30I2R0\include\Ecum_MemMap.hC/C++ の問題 #エラー "MemMap.h、有効なメモリマッピングシンボルが定義されていません。LLCE_CAN_LIN_M7_0 12754行、外部位置:D:\NXP\S32DS.3.4\S32DS\software\PlatformSDK_S32XX_2022_03\SW32_RTD_4_4_3_0_2_D2203\Base_TS_T40D11M30I2R0\include\Rte_MemMap.hC/C++ の問題 #エラー "MemMap.h、有効なメモリマッピングシンボルが定義されていません。LLCE_CAN_LIN_M7_0 12910行、外部位置:D:\NXP\S32DS.3.4\S32DS\ソフトウェア\PlatformSDK_S32XX_2022_03\SW32_RTD_4_4_3_0_2_D2203\Base_TS_T40D11M30I2R0\include\Can_43_LLCE_MemMap.hC/C++ の問題 #エラー "MemMap.h、有効なメモリマッピングシンボルが定義されていません。LLCE_CAN_LIN_M7_0 12910行、外部位置:D:\NXP\S32DS.3.4\S32DS\software\PlatformSDK_S32XX_2022_03\SW32_RTD_4_4_3_0_2_D2203\Base_TS_T40D11M30I2R0\include\Lin_43_LLCE_MemMap.hC/C++ の問題 make: *** [llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:27:llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/Can_43_LLCE_Irq.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** [llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:27:llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/Can_43_LLCE.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** [llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:27:llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/Can_Llce.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** [llce/plugins/EcuM_TS_T40D11M10I0R0/src/subdir.mk:20:llce/plugins/EcuM_TS_T40D11M10I0R0/src/EcuM.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** [llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:26:llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/Lin_43_LLCE.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** [llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:26:llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/Lin_Llce_Irq.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** [llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:26:llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/Lin_Llce.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** [llce/plugins/Rte_TS_T40D11M10I0R0/src/subdir.mk:20:llce/plugins/Rte_TS_T40D11M10I0R0/src/SchM_Can_43_LLCE.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** [src/subdir.mk:20:src/main.o]エラー 1 LLCE_CAN_LIN_M7_0 C/C++ の問題 make: *** 未完了のジョブを待機中.... LLCE_CAN_LIN_M7_0 C/C++ 問題 'Linflexd_Uart_Ip_pHwConfigPB_0_BOARD_INITPERIPHERALS' が宣言されていません (この関数での最初の使用)。もしかして 'Linflexd_Uart_Ip_xHwConfigPB_0_BOARD_INITPERIPHERALS' のことでしょうか？ main.c/LLCE_CAN_LIN_M7_0/src 296行目 C/C++ の問題。 何かアドバイスをいただけますか?ありがとうございます! Re: INTEGRATE LLCE_CAN/LIN(MCAL DRIVER) TO S32DS 3.4 ,But S32 DS Bulid ERROR 実はS32DS.3.5でそのような問題に直面したことがありますが、解決方法が見当たりません。私はS32G-VNP-RDB2(S32G274A_Rev2)ボードではなく、S32G-VNP-RDB3(S32G399A)ボードを使用しています。この問題は解決しましたか？

Corrupt frame data from MIPI sensor Using MIPI OmniVision OS05A20 sensor. imx6s based board receives a corrupt frame. I activated a test pattern on the image sensor. Frame size is 640 x 480. Pixels values should be 0x00 or 0xFF. Expected frame: Image received: The expected frame was captured on the OmniVision sensor evaluation board. Interestingly, the corrupt frame only has about 355 out of 480 filled. In the expected frame, the adjacent pixels in a row alternate from 0xFF to 0x00. In the corrupt frame, same pixels are in groups of 8 having the same values as if every other pixels gets dropped. In the second have of the pixels get corrupt a bit differently. Both sensors are running the same configuration with the exception of the number of lanes, eval board running 4 lanes, my board running 2 lanes. The sensor's MIPI is running at 544Mbps with internal pixel clock at 68MHz. MIPI_CSI_PHY_TST_CTRL1 is set to 0x14 (800–850 MHz). Here is the actual pixel readout frame with all pixels saturated (camera lens removed). Any Ideas as to what could cause the problem? Thank you. i.MX6S Re: Corrupt frame data from MIPI sensor @gennadiykiryukh did you ever find an issue with your driver causing the missed start of frame? I am experiencing something similar with an Omnivision sensor. Re: Corrupt frame data from MIPI sensor >Is it something the OmniVision sensors may need to have configured? Anybody know more on this subject? one can look at sect.6.1.2 Omnivision Camera i.MX Linux Reference Manual supported formats in drivers/media/platform/mxc/capture/ov5640_mipi.c Best regards igor Re: Corrupt frame data from MIPI sensor I already checked the clock frequency as described in that section. PLLs in the image sensor are configured so that PHY CLK of the sensor is 544MHz. MIPI_CSI_PHY_TST_CTRL1 register was set to 0x14 which corresponded to 849MHz. According to the first equation in section 3.4 ... MIPI data rate = (MIPI clock * 2) * Number of lanes >= Pixel clock * Bits-per-pixel ... MIPI clock needs to be above minimum value. In my case the clock was much higher. I tried to set it to a value closely matching the clock of the sensor (0x2E, 600MHz) with the same result. I would not rule out the possibility of bad signals, but the corruption patters is very repeatable to a point where I could reconstruct some of the image by extracting byte sequences. In an attempt to figure out the nature of the frame, I have covered half of the cameras horizontal field of view to obtain a "half-frame". A good frame would have left half of it dark and right half bright (saturated), with saturation repeating every 640 pixels (with every new row). In the corrupt image the saturated-not-saturated pixels were repeating every 160 pixels which is a quarter of the width. Also, that stream of data pixels would be interrupted by a burst of 144 black pixels. It appears to interrupt the pixel stream after every 288 pixels of actual data. The "corruption" pattern seems to change after about 240 lines. After that the corruption appears twice as frequent. the saturation pattern now is 80 pixels and the black pixel burst is now 72 pixels long. The only place where I have seen the image data compressed after half of the frame is in YUV422 and YUV420 formats. Could that be related? The sensor is Bayer format. One possibility is that the receiving end has trouble "understanding" the data. Table 1 in the mentioned document talk about data types used to define packets. The actual values that the processor expects are not listed. Is it something the OmniVision sensors may need to have configured? Anybody know more on this subject? Re: Corrupt frame data from MIPI sensor Hi Gennady for data corruption issues one can consider clock settings described in sect.3.4. MIPI D-PHY clock AN5305  MIPI–CSI2 Peripheral on i.MX6 MPUs Best regards igor ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! -----------------------------------------------------------------------------------------------------------------------

来自 MIPI 传感器的帧数据损坏 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 使用 MIPI OmniVision OS05A20 传感器。 基于 imx6s 的主板接收到损坏的帧。 我在图像传感器上激活了一个测试图案。画框尺寸为 640 x 480。像素值应为 0x00 或 0xFF。 预期帧： 已收到图像： 在 OmniVision 传感器评估板上捕获到了预期的帧。 有趣的是，损坏的帧中只有大约 480 个帧中的 355 个被填充。在预期帧中，一行中相邻像素的值从 0xFF 交替变为 0x00。在损坏的帧中，相同的像素以 8 个为一组，具有相同的值，就好像每隔一个像素都被丢弃一样。在第二部分，像素损坏的方式略有不同。 除了通道数不同之外，两个传感器的配置相同，评估板运行 4 个通道，我的板运行 2 个通道。 该传感器的 MIPI 运行速度为 544Mbps，内部像素时钟频率为 68MHz。 MIPI_CSI_PHY_TST_CTRL1 设置为 0x14（800–850 MHz）。 这是所有像素都饱和的实际像素读取帧（相机镜头已移除）。 大家觉得可能是什么原因导致这个问题？ 谢谢！ i.MX6S Re: Corrupt frame data from MIPI sensor @gennadiykiryukh你是否找到过驱动程序导致帧起始丢失的问题？我的 Omnivision 传感器也遇到了类似的问题。 Re: Corrupt frame data from MIPI sensor <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> OmniVision传感器是否需要进行一些配置？有人了解更多相关信息吗？ 可以参考第6.1.2节。Omnivision i.MX 摄像机 Linux 参考手册 drivers/media/platform/mxc/capture/ov5640_mipi.c 中支持的格式 此致 伊戈尔 Re: Corrupt frame data from MIPI sensor <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我已经按照该章节中的描述检查了时钟频率。图像传感器中的锁相环配置为使传感器的物理层时钟频率为 544MHz。MIPI_CSI_PHY_TST_CTRL1寄存器设置为0x14，对应于 849MHz。根据第 3.4 节中的第一个公式…… MIPI 数据速率 = (MIPI 时钟频率 * 2) * 通道数 >= 像素时钟频率 * 每像素位数 MIPI时钟频率需要高于最小值。就我而言，时钟的时间要高得多。我尝试将其设置为与传感器时钟（0x2E，600MHz）非常接近的值，但结果相同。我不排除信号质量差的可能性，但这种损坏模式具有很强的可重复性，以至于我可以通过提取字节序列来重建部分图像。 为了弄清画面的性质，我遮挡了相机水平视野的一半，得到了一个“半帧”。一个好的画面应该一半较暗，一半较亮（饱和），饱和度每 640 像素重复一次（每行都重复一次）。在损坏的图像中，饱和像素和非饱和像素每 160 个像素重复出现一次，这是宽度的四分之一。此外，该数据像素流会被 144 个黑色像素的突发出现所打断。它似乎每传输 288 个像素的实际数据后就会中断像素流。 大约 240 行之后，“错误”模式似乎发生了变化。此后，腐败现象出现的频率增加了一倍。饱和图案现在为 80 像素，黑色像素爆发现在为 72 像素长。 我只在 YUV422 和 YUV420 格式中见过图像数据在帧的一半之后被压缩的情况。这之间会有关联吗？该传感器采用拜耳阵列格式。 一种可能性是接收端难以“理解”数据。上述文档中的表 1 讨论了用于定义数据包的数据类型。处理器实际期望的值并未列出。OmniVision传感器是否需要进行一些配置？有人了解更多这方面的信息吗？ Re: Corrupt frame data from MIPI sensor <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好，Gennady 对于数据损坏问题，可以考虑文中描述的时钟设置。 第 3.4 节i.MX6 MPU 上的 MIPI D-PHY 时钟 AN5305 MIPI–CSI2 外设 此致 伊戈尔 ----------------------------------------------------------------------------------------------------------------------- 注：如果此回复解答了您的问题，请点击“正确答案”按钮。谢谢你！ -----------------------------------------------------------------------------------------------------------------------

AUTOSAR MCAL MPC5744P こんにちは、みんな、 MPC5744Pを扱い、生成されたAUTOSAR MCALパッケージを使っています。 ビルドエラーが発生しました。 そのようなファイルまたはディレクトリはありません — Os_memmap.h を参照していますMemMap.h の内部: #ifndef AUTOSAR_OS_NOT_USED #include "Os_memmap.h" #endif しかし、生成されたファイルには Os_memmap.h が含まれていません。 この欠けているファイルをどうやって入手できますか? また、EB Tresosを使って新しいMCALパッケージの設定・生成(または欠損部分の再生成)にはどうすればよいのでしょうか? どんなご支援でもありがたいです！ よろしくお願いします。 Re: AUTOSAR MCAL for MPC5744P こんにちは @petervlnaさん、MPC5744P向けにAUTOSAR MCALアプリケーションをビルドするための無料のコンパイラオプションはありますか? Re: AUTOSAR MCAL for MPC5744P こんにちは、 生成されたコードを使ってGHSやDIABでコンパイルできます。 サポートされているコンパイラについては、必ずRTDおよびOSのリリースノートを参照してください。 よろしくお願いいたします。 ピーター Re: AUTOSAR MCAL for MPC5744P こんにちは、ピーターさん。 ご説明ありがとうございます！ 簡単な質問なのですが、Tresos + MCALで生成されたコードをGCCでコンパイルすることは可能でしょうか？それともS32DSやGHSのようなツールチェーンを使用する必要があるのでしょうか？ よろしくお願いします、 エル・グレートリー Re: AUTOSAR MCAL for MPC5744P こんにちは、 この欠けているファイルをどうやって入手できますか? これはMCALによって生成されるファイルの一部ではなく、Tresos OSの設定ファイルからのものです。 私の意見では、おそらくOSの設定に何らかの問題があったのでしょう。 こちらもご覧ください： https://community.nxp.com/t5/S32K/No-such-file-or-directory-include-quot-Os-memmap-h-quot/td-p/1818413 また、EB Tresosを使って新しいMCALパッケージの設定・生成(または欠損部分の再生成)にはどうすればよいのでしょうか? うーん、そういうためのS32デザインスタジオを提供しています。トレソスのトレーニングについては、Elektrobitまでお問い合わせください。 実際はとても簡単なはずです。MCALをインストールしたら、プロジェクトを作成し、必要なプラグインを追加して、tresosからc/hファイルを生成するだけです。その後、S32DS、GHSなどのプロジェクトマネージャーでプロジェクトをまとめます。それをコンパイルできるように。 よろしくお願いいたします。 ピーター

V5705チップ こんにちは、クリオ5用のラジオを手に入れました。NXP製のV5707チップが搭載されています。しかし、このチップの技術仕様は見つかりませんでした。このチップはどのTEFシリーズに属しますか？（TEF6686、TEF6687、TEF6688、TEF6689など） マーク済み = v5705 54 10 sSD1462

将 LLCE_CAN/LIN（MCAL 驱动程序）集成到 S32DS 3.4 中，但 S32 DS 构建错误 大家好， 当我按照文档“INTEGRATE LLCE_CAN/LIN(MCAL DRIVER) TO S32DS 3.4”进行操作时，遇到了一些问题。 当我搭建项目时，它并没有像文档中描述的那样成功。 错误如下所示。 描述 资源路径位置类型 #错误“MemMap.h，未定义有效的内存映射符号。LLCE_CAN_LIN_M7_0 第 12754 行，外部位置：D:\NXP\S32DS.3.4\S32DS\software\PlatformSDK_S32XX_2022_03\SW32_RTD_4_4_3_0_2_D2203\Base_TS_T40D11M30I2R0\include\Ecum_MemMap.hC/C++ 问题 #错误“MemMap.h，未定义有效的内存映射符号。LLCE_CAN_LIN_M7_0 第 12754 行，外部位置：D:\NXP\S32DS.3.4\S32DS\software\PlatformSDK_S32XX_2022_03\SW32_RTD_4_4_3_0_2_D2203\Base_TS_T40D11M30I2R0\include\Rte_MemMap.hC/C++ 问题 #错误“MemMap.h，未定义有效的内存映射符号。LLCE_CAN_LIN_M7_0 第 12910 行，外部位置：D:\NXP\S32DS.3.4\S32DS\software\PlatformSDK_S32XX_2022_03\SW32_RTD_4_4_3_0_2_D2203\Base_TS_T40D11M30I2R0\include\Can_43_LLCE_MemMap.hC/C++ 问题 #错误“MemMap.h，未定义有效的内存映射符号。LLCE_CAN_LIN_M7_0 第 12910 行，外部位置：D:\NXP\S32DS.3.4\S32DS\software\PlatformSDK_S32XX_2022_03\SW32_RTD_4_4_3_0_2_D2203\Base_TS_T40D11M30I2R0\include\Lin_43_LLCE_MemMap.hC/C++ 问题 make: *** [llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:27:llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/Can_43_LLCE_Irq.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 make: *** [llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:27:llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/Can_43_LLCE.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 make: *** [llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:27:llce/plugins/Can_43_LLCE_TS_T40D11M10I0R0/src/Can_Llce.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 制作： *** [llce/plugins/EcuM_TS_T40D11M10I0R0/src/subdir.mk:20:llce/插件/EcuM_TS_T40D11M10I0R0/src/EcuM.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 make: *** [llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:26:llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/Lin_43_LLCE.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 make: *** [llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:26:llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/Lin_Llce_Irq.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 make: *** [llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/subdir.mk:26:llce/plugins/Lin_43_LLCE_TS_T40D11M10I0R0/src/Lin_Llce.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 make: *** [llce/plugins/Rte_TS_T40D11M10I0R0/src/subdir.mk:20:llce/插件/Rte_TS_T40D11M10I0R0/src/SchM_Can_43_LLCE.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 make：*** [src/subdir.mk:20:src/main.o]错误 1 LLCE_CAN_LIN_M7_0 C/C++ 问题 make：*** 等待未完成的作业.... LLCE_CAN_LIN_M7_0 C/C++ 问题 未声明的变量“Linflexd_Uart_Ip_pHwConfigPB_0_BOARD_INITPERIPHERALS”（在此函数中首次使用）；您是不是想用“Linflexd_Uart_Ip_xHwConfigPB_0_BOARD_INITPERIPHERALS”？ main.c/LLCE_CAN_LIN_M7_0/src 第 296 行 C/C++ 问题。 你能给我一些建议吗？谢谢！ Re: INTEGRATE LLCE_CAN/LIN(MCAL DRIVER) TO S32DS 3.4 ,But S32 DS Bulid ERROR 实际上，我在 S32DS.3.5 中也遇到过这个问题，但我没有办法解决。我使用的是 S32G-VNP-RDB3(S32G399A) 板，而不是 S32G-VNP-RDB2(S32G274A_Rev2) 板。这个问题解决了吗？