Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
8M以上のリアルタイム精度について こんにちは。8M Plusのリアルタイムアプリケーションに関する機能について、さらに詳しく知りたいと思います。TSNやリアルタイムパフォーマンス、ジッターに関するテストレポートや関連資料はありますか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy エリア 入手可能な資料 内容物 リアルタイムCPU/RTOSレイテンシ ハープーンユーザーガイド  i.MX 8M Plus / Zephyr でリアルタイムレイテンシを測定し、IRQレイテンシやタスクレイテンシ(ns単位)も含まれます。例としての結果:no-load IRQ レイテンシ min/avg/max/stddev = 625 / 796 / 11,125 / 1,798 ns タスクレイテンシ = 2,583 / 2,671 / 13,041 / 6,045 ns 。Linux CPU + メモリ負荷の場合、IRQレイテンシ= 625 / 798 / 4,250 / 4,674 ns 、タスクレイテンシ= 2,583 / 2,670 / 14,333 / 10,407 ns です。 リアルタイムベンチマーク方法 Harpoon ユーザーガイド — RT レイテンシアプリケーション ベンチマークをハードウェアIRQイベントとソフトウェア動作間の時間差と定義し、ハードウェアタイマーとサブマイクロ秒単位の精度で測定します。 TSNの能力 i.MX 8M Plus製品/リファレンスマテリアル i.MX 8M PlusはデュアルGbイーサネットを搭載し、そのうち1つはTSNに対応し、産業用リアルタイム制御には統合 800 MHzのArm Cortex-M7 を使用します。 TSNハードウェア規格 i.MX 8M プラスリファレンスマニュアル TSNのサポートには 、IEEE 802.1Qbv Time-Aware Shaper 、 802.1Qav Credit-Based Shaper 、 IEEE 1588v2 PTP 、およびイーサネットブロック実装 802.1Qbv-2015が含まれます 、 802.3br 、 そして 802.1Qbu フレームプリエンプション関連のTSN関数。 TSNテスト/検証環境 リアルタイムエッジユーザーガイド トラフィック生成・解析およびレイテンシ、ジッター、同期精度の監視を含む8M Plus TSNの能力を評価するためのTSNテスト環境 i.MX 説明します。 TSNジッター/レイテンシの例 リアルタイムエッジユーザーガイド — TSNエンドポイントサンプルアプリ トラフィックの最小/平均/最大レイテンシやノート レイテンシは約503μs と レイテンシ ジッターは約300 ns を含むTSNエンドポイント統計を提供します。 TSNアプリケーションデモ AN13588 GenAVB/TSNのリアルタイム制御アプリケーションを実証します。これは 2ミリ秒サイクル  、400μsの予約/保証制御トラフィックウィンドウ 、スケジューリング、プロセッシングタイミング、トラフィックの正確性、レイテンシのための統計スレッドを記述しています。 TSN 802.1Qbv デモ AN13995 8M Plus i.MX を用いたTSN 802.1Qbvの実演と、時間認識シェーピングが固定リピーティングサイクルを用いてデターミニスティックなレイテンシを提供する方法を説明しています。また、Linux  tc  /  taprio  configurationの例も含まれています。   Re: Regarding 8M Plus Real time Accuracy @yipingwang 情報を提供していただきありがとうございます。iMX8M Plus EVKについても情報を教えていただけますか? ありがとうございます。 Re: Regarding 8M Plus Real time Accuracy i.MX95 EVKに関する公式な「リアルタイム性能レポート」は公開されていないことを承知しております。しかし、NXPはi.MX95プラットフォーム上でリアルタイムのベンチマークを内部で行っています。内部ベンチマーク文書によると、cyclictestおよびEtherCATのパフォーマンス評価は、Linux上でリアルタイムエッジソフトウェアを実行するi.MX95 LPDDR5 EVK上で実施PREEMPT_RTされています。報告された例としては、6時間のストレスNGテストにおける最大周期テスト**レイテンシ**約38μsや、EtherCATのフィルタによる最大ジッター約12μsが報告されています。リアルタイム性能はBSPバージョン、カーネル構成、CPU分離、ワークロード、ネットワークトラフィックに大きく依存するため、これらの値はアプリケーションレベルの保証された制限ではなく、参照の測定とみなすべきです。   詳細については、 https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdfを参照してください。 サポートされるベンチマークプラットフォームとして、詳細なサイクリックテスト、ストレス、rt_latency手順を提供します。 Re: Regarding 8M Plus Real time Accuracy 代理店からは、NXP i.MX95 EVKのリアルタイムパフォーマンスやジッターに関する公式なパフォーマンスレポートは現在存在しないと伝えられました。 しかし、リアルタイムレイテンシを評価するためのテスト手法(例:cyclictest)についてのドキュメントも提供しました。 これは我々の側で多少の混乱を招いている。標準化されたテスト手法が存在することから、そのようなテストは少なくともリファレンスEVKプラットフォーム上で内部で実施されたと仮定します。 したがって、以下の点を明確にしたいと思います。 NXPはi.MX95 EVKのリアルタイム性能(例:レイテンシ、ジッター)の内部測定を行ったことはありますか? もしそうなら、共有できる参考や基準の結果はありますか? リアルタイムのパフォーマンスは、システム構成やワークロードによって変動する可能性があることを理解しています。しかし、管理された条件下(例えば、デフォルトのBSP、最小負荷)でのベースライン結果であっても、初期評価には非常に役立つだろう。 再開まで今しばらくお待ちください。 Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (リアルタイムエッジソフトウェアユーザーガイド)(https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf) .リアルタイムエッジソフトウェア(最も関連性が高い) NXPの Real-Time Edgeソフトウェア は公式にi.MX8M Plus EVKをサポートし、以下を含みます: PREEMPT_RT Linux TSNスタック IEEE 802.1AS (gPTP) 同期 TSNトラフィックシェーピングとスケジューリング EtherCAT、OPC-UA、CAN関連の産業用プロトコル Cortex-A53 + Cortex-M7を用いた異種リアルタイム動作 内部文書 REALTIMEEDGEUG によると、Real-Time Edge Softwareは以下の機能を提供します: リアルタイムネットワーキング(TSN) リアルタイムLinux(PREEMPT_RT) 純粋なRTOS/ベアメタルオプション 刑務所の仕切り インダストリアルプロトコルサポート i.MX 8M Plus LPDDR4 EVKのサポート NXPアプリケーションノート AN13995 – i.MX 8M Plusを用いたTSN 802.1Qbvデモンストレーション リアルタイムエッジのSix Pack資料(PREEMPT_RT+TSNサポートを説明する) Re: Regarding 8M Plus Real time Accuracy @yipingwang情報を提供していただき、本当にありがとうございました。
記事全体を表示
PWM Capture can't work in frdm_mcxw72 board Hi, I tried to practice the pwm capture sample in  frdm_mcxw72 board, but unfortunately, the print message in serial tool only show " capture cycle err -134" . I'm sure there is the 1Khz, 50% duty cycle pwm signal inject into the PTA21 pins in frdm_mcxw72 board. i imported the whole project files from the demo case,  there is no change that i only added the overlay file,   below is the overlay files setting. can you help check the reason why there is no correct print information. thanks in advance! Re: PWM Capture can't work in frdm_mcxw72 board Hello, Hope you are doing well. Could you please clarify what Zephyr repo are you using? Also, are you starting from any of the examples? Did you modify something? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo, The repo version is V4.4.1.0,  below is the my steps  1. Import the capture example application from the repo  2. Add the  DTS overlay file in the board folder, the content of the overlay file  posted in first message. 3. build and flash into the frdm_mcxw72 board in my hand,  the print message is  "capture cycle err" ,  it looks the board state is ok because i didn't inject the pwm signal , but the print message is the same after the pwm signal injected into PTA21 pins.     Re: PWM Capture can't work in frdm_mcxw72 board Hello, Could you please clarify what repository are you using? Are you using Upstream or Downstream? Also, is the example working on your side without modifications? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo here is the repo version  i only update the overlay file,  it will be  can't build successfully if there is no this file. Best regards! Re: PWM Capture can't work in frdm_mcxw72 board Hello, Could you please clarify if you are using Upstream or Downstream? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo, Sorry, i didn't very understand  what's the "Upstream" or "Downstream" here . i guess it should be the downstream. or can you change another description?
記事全体を表示
IMXRT LPUARTの非ブロッキング転送APIはエラー処理を困難にする こんにちは、 私は、割り込みベースのノンブロッキング転送を行うためのLPUARTの「転送」APIについて調べています。LPUART割り込みなどの「ハッピーケース」処理をうまくラップし、準備ができたときにだけデータを受信できる良い高水準APIを提供しているようです。アイドル状態、受信準備完了、送信完了などの処理。しかし、これによってUARTエラーの処理が非常に困難になる。 LPUART_TransferHandleIRQ関数内にはエラー処理がなく、fsl_lpuart.cのその関数の直後には「ユーザーによって実装される」というコメントを含む偽の空LPUART_TransferHandleErrorIRQがあります。これは完全に未完成に見える。 UARTエラーを実際に処理する唯一の方法は、デフォルトのLPUARTx_IRQHandler関数を上書きし、LPUARTx_RX_DriverIRQHandler(またはTX)を呼び出す代わりに、自分でエラーを処理し、「ハッピーCASE」割り込みを元のLPUARTx_RX/TX_DriverIRQHandlerに渡してLPUART_TransferHandleErrorIRQに呼び出すようにすることのようです。 さらに、転送APIの外部でLPUART_EnableInterruptsを呼び出してエラー割り込みを自分で有効にし、エラー処理の中でLPUART_DisableInterruptsを呼び出してそれらをクリアするなどの処理を行う必要があります。 エラー処理にこれだけの手間をかけるのは、かなり面倒な作業のように思える。なぜこの機能が転送API自体に組み込まれていないのでしょうか? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 詳細なフィードバックをありがとうございます。SDKは各ペリフェラル機能の共通ユースケースを提供するためのものなので、少し曖昧な部分もあることは理解しています。このようなご意見も参考にしながら、私たちは常にAPIの改善に取り組んでいます。ご提案ありがとうございます。今後のリリースでもLPUARTのエラー処理が実装されることを願っています。 一方で、どのエラー条件を扱いたいのか、どのデバイスを使っているのか教えていただけますか?その情報をもとに、実装に役立つエラー条件に関するドキュメントを提案できます。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 考えられるすべてのエラー。これは、転送APIはあるがエラー処理がないほぼすべてのペリフェラル(SPI、I2Cなど)に当てはまります。IMXRT1172のLPUARTには、特にフレーミングエラー、パリティエラー、ノイズエラーがあり、これらは適切に処理されていません。残念ながら現状、これらのペリフェラルは転送API使用時のエラー処理にハッキングが必要です。SDKハンドラーを呼び出す前に、エラーを確認するために実際のデフォルトのIRQハンドラをオーバーライドしなければなりませんでした。 ありがとうございます -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 追加の開発期間が必要になる可能性があることは理解していますが、SDKsの改善に引き続き取り組んでいます。参考として、SDK(バージョン26.6)の関数「LPUART_TransferHandleIRQ」の構造を確認し、アプリケーションが必要とする類似の回復フローを実装できます。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 他に質問がありましたら、お気軽にお知らせください。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult はい、既に似たようなものを実装しています。送っていただきありがとうございます。
記事全体を表示
我需要为SPI配置DMA。 我正在使用 S32DS IDE 和 RTD 3.0,请问有人能告诉我如何通过 SPI 启动 DMA 吗?最好能提供详细的步骤说明或示例代码。 Re: I need to configure DMA for SPI 谢谢你的回复 请对 s32k322 MCU 执行此操作 Re: I need to configure DMA for SPI 嗨@ershi RTD 附带两个使用 DMA 进行 SPI 通信的示例代码,一个使用低级驱动程序 (Ip),一个使用高级驱动程序 (MCAL)。您可以参考主题HOWTO: S32 Design Studio - 从示例创建新的 S32DS 项目,以获取有关如何导入示例的指导。 另外,您可以参考主题“示例 S32K31 SPI 多数据包发送和接收:DMA 缓存问题的解决方案”中提供的示例。 BR,VaneB Re: I need to configure DMA for SPI 嗨@ershi 虽然这些示例并非专门为 S32K322 设计,但除非参考手册另有说明,否则其功能在 S32K3 系列中通常相同。因此,您可以将此项目作为您实现的参考,并根据您的特定设备进行必要的调整。 Re: I need to configure DMA for SPI 我已经配置好了一切,但它仍然无法正常工作。第一次调用 (Lpspi_Ip_AsyncTransmit) 时返回 LPSPI_IP_STATUS_SUCCESS,第二次调用时返回失败 LPSPI_IP_STATUS_FAIL。我可以使用这个 API 通过 SPI 发送数据,而无需使用 DMA 调用 Lpspi_Ip_SyncTransmit()。我附上了一些配置截图。
記事全体を表示
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) and MCX Wx (MCX W71/72 & MCX W23) Power Profile Tools. It will help you to estimate the power consumption in your application (Automotive or IIoT) and evaluate the battery life time of your solution. This page content 2 dedicated power profile tools :    1. 'One Connectivity Power Profiling Tool' which includes: New: KW43 (Automotive) and MCX W70 (IIoT) products in standalone based on simulation. KW3x/KW4x (Automotive) and MCX W7x (IIoT) products in standalone. MCX W23 (IIoT) product in standalone. K32W0/QN9090, KW41, QN9080 products in standalone. MCX W71 & W72 product in standalone (IIoT). New: MCX W70 product in standalone (IIoT) based on simulation. Bluetooth LE 802.15.4 Matter & ZED SmartFob application (Automotive):                        BLE/KW45 + UWB Ranger4 + SE + motion sensor                        New: BLE/KW47 + UWB Ranger5 + SE + motion sensor    2. CCC CS application (Automotive) 1.'One Connectivity Power Profiling Tool' Overview: Installation file is available in the OneConnectivityPowerProfilingtool_SDK_26_03.ZIP file. Follow the quick start instruction to play with the tool. To update the tool with the latest revision, you only need to download the source_file.txt available in the ZIP.  NEW: SmartFob application (Automotive) for both BLE(KW45/47)+UWB(Ranger4/5) is available in the One Connectivity Power Profiling tool   Overview: 2. KW43 CCC CS localization application (Automotive) This tool is based on simulation data provided by R&D designers For Power and Low Power Application Notes please see product pages. Here are some direct links for your convenience: Bluetooth LE AN14554 Kinetis KW47 Bluetooth LE Power profile analysis release.pdf AN14739 MCX W72 Bluetooth LE Power profile analysis Rev2.0.pdf Kinetis KW45 and K32W1 Bluetooth LE Power Consumption Analysis MCX W71 Bluetooth LE Power Consumption Analysis AN14659: MCX W23 Bluetooth Low Energy Power Consumption Analysis | NXP Semiconductors CS AN14628_KW47_CCC_CS_Power_Profile_estimator tool_release.pdf 802.15.4 AN14841 MCX W72 802.15.4 Matter and Zigbee Power profile analysis.pdf Power Management KW45/K32W148 - Power Management Hardware MCXW71 - Power Management Hardware Please, find this important link to build a PCB using a KW45/MCX W71 or KW47/MCX W72 and all concerning the radio performances and radio certification (CE/FCC/IC): The best way to build a PCB using a KW45 (car acce... - NXP Community The best way to build a PCB first time right with KW47 (Automotive) or MCX W72 (IoT/Industrial) Product: K32W0 Product: K32W1 Product: KW 34|35|36 Product: KW 37|38|39 Product: KW41Z |31Z | 21Z Product: QN9080|SIP Product: QN9090|30 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) Hi Everett, The password is in place to avoid changes or competitor benchmarks in too much details. Sorry for the inconvenient but it can't be. Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) Hi  christophe_menard, @christophe_menard  Could you provide the password of Sheet protection, thanks very much. Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) Hello , We would like to work with OneConnectivityPowerProfilingtool_SDK_26_03.zip but a trojan is detected. How to do to use thtis tool. Thank you for the support Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) Hi @pierre_demeyer  I opened a ticket to our IT to verify this. I will keep you informed soon. Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) Hi @pierre_demeyer  After IT verification, no Trojan virus was detection using Crowstrike or Defender softwares.
記事全体を表示
RT1064 I2C 通信异常,频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常,但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看,这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS:将该设备的 I2C 驱动程序移植到另一台 1064 设备上,测试模块 A,在 400k 功耗下未发现问题。 原因可能是什么? 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 图 2:模块 A 在 100kHz 下的逻辑分析仪波形 图3:模块B在400kHz时的波形 i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察,该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足,而不是模块 A 本身的异常。 即使上升时间在规格范围内,在 RT1064 上,我们仍然建议检查 LPI2C 主侧 400 kHz 配置,特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1,因为 RT1064 上的主同步延迟不仅受上升时间的影响,还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置,并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符: I2C模块时钟源 目标波特率:400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息:昨天在定位方面取得了一些进展: 我们的硬件扩容计划如下: 主板:RT1064--- ADUM1251 3.3V 至 5 V 子板:ADUM1251-模块A 5V转3.3V 经验证,在硬件链路的两层中添加 ADUM1251 后,模块 A 的通信出现异常。但移除 ADUM1251 后,通信在 400k 处恢复正常。造成这种情况的原因可能是什么? PS:我们的硬件工程师认为 ADUM1251 只会增加通信延迟,不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好,@mayliu1 我们的产品即将发布,我们已经调查这个问题好几天了。如果您能尽快回复,我们将不胜感激! Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形,上升时间符合要求,在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备,并测试了模块 A,没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 怀疑: 1.如果时钟在拉伸后恢复异常,还有哪些其他原因可能导致这种情况? 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置?我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求,我们是否就不需要考虑这些寄存器设置了? Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 , 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题,而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上,LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出,上升时间越大,同步延迟就越高。(参见第 47.3.1.4 章)时序参数) 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置,使其延迟保持在最小 SCL 低/高周期以下,RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 因此,如果模块 A 使总线边沿稍微变慢或改变有效负载,则总线可能在 400 kHz 时发生故障,但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率,但应根据 I2C 规范仔细验证自动生成的定时参数,特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险,建议使用经过验证的时钟源,例如 48 MHz,如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数? PS:显然是由于自动接口分配造成的 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 您可以尝试直接设置寄存器。 例如,当使用 60 MHz I2C 时钟时,可以采用以下配置。 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 当前的 I2C 时钟是基于 SDK2_13_0-EVK-MIMXRT1064 板 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c 目录中的示例配置进行配置的。 #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); 我该如何修改才能获得精确的 8MHz 或 48MHz 频率?(时钟树似乎看不见) Re: RT1064 I2C communication abnormality at 400kHz 我尝试将频率修改为 60MHz 和 8MHz,但仍然无效。下图中的红色方框显示的是修改后打印的值,这些值与手册中的值不同。 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 配置 I2C 时钟有多种方法。 建议您尝试 8 MHz 和 60 MHz,因为这两个时钟设置相对容易实现。 我正在使用 SDK 演示版: "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" 方法一:将 LPI2C 时钟源配置为 60 MHz 只需将时钟分频器设置为 0 即可。 方法二:将 LPI2C 时钟源配置为 8 MHz 使用 MCUXpresso IDE 时钟工具并按如下所示进行配置。选择 OSC_CLK 作为时钟源,并将分频器设置为 3,这将为 LPI2C (I2C) 模块生成 8 MHz 时钟。 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 如图所示,我尝试修改寄存器设置以匹配参数,但在 60MHz 下性能没有提升;即使是性能良好的模块在 8MHz 下也无法正常工作。 Re: RT1064 I2C communication abnormality at 400kHz 原因已查明,出现问题的模块将在 400k 时出现时钟拉伸现象。 但是我们使用的隔离器芯片不支持 SCL 双向。更换隔离芯片后, 测试结果正常;此订单可以结案。
記事全体を表示
board.h に extern C ガードがありません これはバグレポートです。MCXA153にはSDK_2.16.000を使用しています。MCUXpressoの「新しいC/C++プロジェクトの作成」ウィザードを使用して新しいC++プロジェクトを作成すると、生成されたコードがビルドに失敗します。 `BOARD_InitDebugConsole()' への未定義の参照 これは board.h に extern C ガードが欠落しているためです。これは次のように修正できます。 #ifdef __cplusplus extern "C" { #endif void BOARD_InitDebugConsole(void); #ifdef __cplusplus } #endif 開発ボード MCXA Re: board.h missing extern C guard 約束してから 1 年以上経ちましたが、新規インストールで C++ プロジェクトを作成すると、バグはまだ存在します (2025 年 12 月)。 `BOARD_InitDebugConsole()' への未定義の参照 NXP ではお客様のケアをしている人っているのでしょうか? Re: board.h missing extern C guard 親愛なる@aberger様、 お客様のフィードバックに基づいて問題を再現し、対応する問題を特定しました。 回答を NXP コミュニティにご提供いただき、ありがとうございます。このバグは関連チームに提出済みであり、対応するパッチをできるだけ早く更新したいと考えています。 よろしくお願いいたします LIU Re: board.h missing extern C guard こんにちは、 @fjrg76さん この問題を報告していただきありがとうございます。返信が遅くなり、大変申し訳ございませんでした。 当社の社内システムでは、CASEが1か月以上クローズされると、新たな更新が加わった際にリマインダーや通知を受け取ることはありません。ご迷惑をおかけしましたことを心よりお詫び申し上げます。 この問題については、SDKチームに確認し、できるだけ早くご連絡いたします。 念のためお伝えしますが、今後さらに質問や懸念があれば、新しいサポートチケットを作成してください。これにより、お客様のご要望を迅速に確認し、タイムリーな対応が可能になります。または、直接私にご連絡いただければ、メッセージを受け取り次第すぐにご連絡いたします。 ご理解とご辛抱に感謝いたします。 BR アリス
記事全体を表示
SPI用のDMAを設定する必要があります 私はS32DS IDEとRTD 3.0を使っています。SPIでDMAを起動する方法や、ステップバイステップの手順や、もしあれば他の例コードがあれば教えてもらえますか? Re: I need to configure DMA for SPI ご回答ありがとうございます。 この作業はs32k322 MCUで行ってください Re: I need to configure DMA for SPI こんにちは@ershi RTDにはDMAを用いたSPI通信用の2つの例コードが付属しており、1つは低レベルドライバ(Ip)を用い、もう1つは高レベルドライバ(MCAL)を使用します。例のインポート方法については、HOWTO: S32 Design Studio - Create a New S32DS Project from Example Threadを参照してください。 また、スレッドの 例であるS32K31 SPI Multiple Packet Transmit and Receive: Solution for DMA Cache Issueの例を参照することもできます。 BR、VaneB Re: I need to configure DMA for SPI こんにちは@ershi これらの例はS32K322向けに特別に設計されているわけではありませんが、リファレンス・マニュアルに特に記載されていない限り、S32K3 ファミリ全体で機能性は概ね同じです。したがって、このプロジェクトを実装の参考として活用し、必要に応じてデバイスに合わせて調整することができます。 Re: I need to configure DMA for SPI すべて設定しましたが、最初は動作せず、(Lpspi_Ip_AsyncTransmit)でLPSPI_IP_STATUS_SUCCESSとして返され、2回目は失敗と表示されますLPSPI_IP_STATUS_FAIL、DMAなしでこのAPIを使ってデータをSPI経由で送信できますLpspi_Ip_SyncTransmit()いくつかの設定スクリーンショットを添付しました。
記事全体を表示
Kinetis (.. /45/47/43;MCX W71/72/70) & MCX W23 Power 我的 工具(包括本地化) 本页专用于 Kinetis(KW35/KW38/KW45/KW47)和 MCX Wx(MCX W71/72 & MCX W23)Power 我的 工具。 它将帮助您估算应用(汽车或物联网)的功耗,并评估解决方案的电池寿命。 本页包含 2 个专用的电源配置工具: 1.'One 连接 Power Profiling Tool' 包括: 新增:基于仿真的KW43(汽车)和 MCX W70(工业物联网)产品独立组网 (SA)。 KW3x/KW4x(汽车)和 MCX W7x(工业物联网)产品独立组网 (SA)。 MCX W23 (IIoT) 产品独立组网 \\(SA\\)。 K32W0/QN9090、KW41、QN9080 产品独立组网 (SA)。 MCX W71 & W72 独立组网 \\(SA\\) 产品 (IIoT)。 新增:基于仿真的独立组网 (SA) (IIoT) 的 MCX W70 产品。 BLE 802.15.4 物质& ZED SmartFob应用程序(汽车): BLE/KW45 + UWB Ranger4 + SE + 运动传感器 新产品:BLE/KW47 + UWB Ranger5 + SE + 运动传感器 2.CCC CS 应用程序(汽车) 1。'One Connectivity 电源分析工具' 概述: 安装文件可在 OneConnectivityPowerProfilingtool_SDK_26_03.ZIP 文件中。文件中。 请按照快速启动说明使用该工具。 要使用最新版本更新工具,只需下载 ZIP 中的 source_file.txt。 新增:One Connectivity 电源配置工具中提供适用于 BLE (KW45/47) 和 UWB (Ranger4/5) 的 Smart Fob 应用程序(汽车)   概述: 2.KW43 CCC CS 本地化 应用(汽车) 该工具基于 R&D 设计人员提供的模拟数据。 有关功耗和低功耗应用笔记,请参阅产品页面。以下是一些直接链接,以方便您使用: BLE AN14554 Kinetis KW47 蓝牙 LE 功率我的分析 版本.pdf AN14739 MCX W72 低功耗蓝牙我的分析 Rev2.0.pdf Kinetis KW45 和 K32W1 蓝牙 LE 功耗分析 MCX W71 蓝牙 LE 功耗分析 AN14659:MCX W23 低功耗蓝牙功耗分析|恩智浦半导体 CS AN14628_KW47_CCC_CS_Power_Profile_estimator tool_release.pdf 802.15.4 AN14841 MCX W72 802.15.4 Matter 和 Zigbee 电源我的 analysis.pdf 电源管理 KW45/K32W148-电源管理单元硬件 MCXW71 - 电源管理单元硬件 请找到这个重要链接,使用 KW45/MCX W71 或 KW47/MCX W72 版本 PCB,以及所有与无线电性能和无线电认证 (CE/FCC/IC) 相关的内容: 使用KW45版本 PCB 的最佳方式(汽车配件...-恩智浦社区 首次成功设计 KW47(汽车级)或 MCX W72(物联网 / 工业级)PCB 的最佳方法 产品:K32W0 产品:K32W1 产品:KW 34|35|36 产品:KW 37|38|39 产品:KW41Z |31Z |21Z 产品:QN9080|SIP 产品:QN9090|30 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) 嗨,埃弗雷特、 密码的设置是为了避免在太多细节上出现变化或竞争对手的基准。 很抱歉给您带来不便,但这是不可能的。 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) 你好,克里斯托夫-梅纳德。 @christophe_menard能否提供Sheet 保护 密码 ,非常感谢。 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) 你好 , 我们想使用OneConnectivityPowerProfilingtool_SDK_26_03.zip,但检测到了木马程序。 如何使用这个工具? 感谢您的支持 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) 嗨@pierre_demeyer 我已向IT部门提交了工单以核实此事。 我会尽快通知您最新情况。 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) 嗨@pierre_demeyer 经 IT 部门核实,使用 Crowstrike 或 Defender 软件均未检测到木马病毒。
記事全体を表示
RT1064 I2C communication abnormality at 400kHz The I2C2 interface of the RT1064 device connects to Module A. Communication anomalies occur at 400kHz, but it functions properly at 100kHz 1. Connecting module B of a different model within the same series at 400kHz is no problem 2. In terms of waveform, it is equivalent to an anomaly occurring when the host clock is stretched and then restored after connecting to Module A PS: Implement the I2C driver port of the device to another 1064 device, test module A, no issues at 400k What might be the reason? 1. Figure 1 Module A Abnormal Waveform of Logic Analyzer at 400kHz 2. Figure 2: Waveform of Logic Analyzer for Module A at 100kHz 3. Figure 3: Waveform of Module B at 400kHz i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , Thanks for the additional clarification — this is a very important observation.   From your observations, the issue appears more likely to be related to insufficient 400 kHz I2C timing margin caused by the two-stage ADUM1251 isolation link, rather than an abnormality of Module A itself. Even if the rise time is within spec, on RT1064, we still recommend checking the LPI2C master-side 400 kHz configuration, especially MCFGR2[FILTSCL/FILTSDA] and MCCR0/MCCR1 , because the master synchronization latency on RT1064 is affected not only by rise time, but also by the digital filter and timing parameter settings. We suggest reading out the actual configuration used in your project and comparing it with Table 47-5, “LPI2C Example Timing Configurations,” in Chapter 47 of the RT1064 Reference Manual . In particular, please check whether the following settings match to the example values for your selected clock condition: I2C module clock source Target baud rate: 400Kbps PRESCALE FILTSCL / FILTSDA SETHOLD CLKLO CLKHI DATAVD Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Additional information, there was some progress in positioning yesterday: Our hardware expansion is: Motherboard: RT1064--- ADUM1251    3.3 V to 5 V Subboard: ADUM1251- Module A          5v to 3.3v After verification, it was found that after adding ADUM1251 to the two layers of the hardware link, module A had abnormal communication. However, after removing it, communication returned to normal at 400k. What could be the reason for this? PS: Our hardware engineers believe that ADUM1251 only increases communication latency and has no other impact Re: RT1064 I2C communication abnormality at 400kHz Hi,@mayliu1 Our product is about to be released, and we have been investigating this issue for several days. If we could receive your response as soon as possible, we would greatly appreciate it! Re: RT1064 I2C communication abnormality at 400kHz Hi  Supplementary information 1. Our two hardware engineers checked the waveform of the problem through an oscilloscope, and the rise time met the requirements, within 100+ns 2. I ported I2C initialization and read-write function drivers to another type of RT1064 device,  and tested module A without any issues The following figure shows the waveform of another device module A testing logic analyzer doubt: 1. If the clock recovers abnormally after stretching, what other reasons could be causing it 2. Is there a dedicated function to set settings such as MCFGR2 mentioned in the last reply? I didn't see any interface to be set in the I2C initialization process ----If the rise time is met, do we not need to consider these register settings? Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , Thank you so much for your interest in our products and for using our community. I think that this is most likely not a Module A issue, but a 400 kHz timing-margin issue on that specific RT1064 LPI2C2 bus. On RT1064, LPI2C timing is affected by bus rise time, bus loading, pull-up resistors, and glitch-filter latency.  RT1064RM  reference manual describe  that larger rise time increases synchronization latency.  (refer to chapter 47.3.1.4 Timing Parameters) The master glitch filters MCFGR2[FILTSCL/FILTSDA] must be set so their latency stays below the minimum SCL low/high period, and RT1064 provides example 400 kbps timing settings in MCCR0/MCCR1 .  Please check the Table 47-5. LPI2C Example Timing Configurations So if Module A makes the bus edges slightly slower or changes the effective loading, the bus may fail at 400 kHz but still work at 100 kHz .  Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Below is the configuration for printing. Which parameter may need to be adjusted? PS:apparently due to automatic interface allocation Re: RT1064 I2C communication abnormality at 400kHz A 10 MHz LPI2C functional clock is not listed in the RT1064 Reference Manual example timing configurations for 400 kbps. Although it is possible to generate a 400 kbps baud rate with this clock, the automatically generated timing parameters should be carefully verified against the I2C specification, particularly with respect to tLOW, tHIGH, setup/hold timing, and data valid timing. To reduce design risk, it is recommended to use a validated clock source, such as 48 MHz, as shown in the Reference Manual. Re: RT1064 I2C communication abnormality at 400kHz I tried modifying 60MHz and 8MHz, but it still didn't work. The red box in the figure below shows the values printed after modification, which are different from the manual Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , There are several ways to configure the I2C clock. As a suggestion, you can try 8 MHz and 60 MHz, as these two clock settings are relatively easy to achieve. I am using the SDK demo: "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" Way 1: Configure LPI2C clock source to 60 MHz Simply set the clock divider to 0. Way 2: Configure LPI2C clock source to 8 MHz Use the MCUXpresso IDE Clock Tool and configure it as shown below. Select OSC_CLK as the clock source and set the divider to 3, which will generate an 8 MHz clock for the LPI2C (I2C) module. Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , You may try setting the registers directly. For example, when using a 60 MHz I2C clock, the following configuration can be applied. Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz The current I2C clock is configured based on the sample configuration in the SDK2_13_0-EVK-MIMXRT1064 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c directory, #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); ---How can I modify it to obtain the precise 8MHz or 48MHz? (The clock tree doesn't seem to be visible) Re: RT1064 I2C communication abnormality at 400kHz As shown in the diagram, I tried to modify the register settings to correspond to the parameters, but there was no improvement at 60MHz; Even good modules cannot function properly at 8MHz Re: RT1064 I2C communication abnormality at 400kHz The cause has been identified, and the module with the problem will experience clock stretching at 400k. However, the isolator chip we are using does not support SCL bidirectional. After replacing the isolator chip, the test was normal; This order can be closed
記事全体を表示
Behavior of PMIC using external Watchdog (Wdg_43_VR5510) I have implemented the external watchdog (Wdg_43_VR5510) for PMIC. But it is going into endless loop in Pmic_VR5XX_TimeoutLoops_StateTransistion (refer below). Currently it is in INIT_FS state, as per the state diagram it says we need to have a good watchdog refresh to change the state from INIT_FS to Wait_ABIST2. To Satisfy the first good watchdog refresh within 256ms, we have called watchdog trigger API after Wdg_43_VR5510_Init function during EcuM Initialization. We need to know, how and where to call the first watchdog refresh. So that the state transition happens from INIT_FS to wait_ABIST2. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello @Jerry_cao , Thank you for contacting us. However, the original post has been closed for nearly two years, so we are unable to continue supporting you under that thread. Please create a new post for your issue on S32G - NXP Community, and our team will be happy to assist you further. BR Celeste Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello NXP team, I'm currently debugging the VR5510 PMIC and have run into a real-time scheduling issue related to the watchdog refresh. The MCAL I2C watchdog refresh (feeding the VR5510 watchdog over I2C) is implemented as a synchronous operation. Because we call it from within an interrupt context, the synchronous wait blocks the CPU and degrades the real-time scheduling of other tasks. I noticed there is an asynchronous option in the driver configuration/code. However, in practice it still performs a synchronous busy-wait (it blocks and polls until the I2C transfer completes), so it does not actually decouple the transfer from the caller. My questions: Is there an officially supported way to make the VR5510 watchdog refresh truly non-blocking (e.g. interrupt-driven or DMA-driven I2C), so that it does not stall other tasks? If the asynchronous option is expected to be non-blocking, is the current synchronous busy-wait behavior a known limitation or a configuration issue on my side? Any guidance, reference configuration, or example code would be greatly appreciated. Thank you. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello SagarZala, I wonder if you have tried the two out-of-the-box examples in S32 Design Studio (S32DS)? Will they have the same problem? May be they are very good references for you. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hi, Thanks for the reply. I am using RTD version 4.0.2. I have already configured the I2C at high speed and WD_WINDOW is also configured at 1024ms. But still its not working. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Dear @SagarZala , Thank you for your question. VR5510 is commonly paired with the S32G microprocessor. For this, the available drivers for VR5510 should be provided under the S32G RTD packages. Which RTD version are you using and which specific example is it? Taking the RTD 4.0.0 version as an example, you can find the documents "RTD_WDG_43_VR5510_IM" and "RTD_WDG_43_VR5510_UM" under the path C:\NXP\SW32G_RTD_4.4_4.0.0\eclipse\plugins\Wdg_43_VR5510_TS_T40D11M40I0R0\doc. The document "RTD_WDG_43_VR5510_UM" describes more detail. It is worth mentioning that the watchdog is triggered via the I2c command and it depends on the I2c speed. When the I2c speed is low, the watchdog may not be triggered successfully within the watchdog's window open time. To avoid this problem, we recommend that the user configure I2c with high speed and use a large window period when it is enabled. To set the watchdog refresh, you can configure the WD_WINDOW [3:0] to obtain the refresh time. As shown in the following figure: Refer to "Document VR5510 Product data sheet", page 60, Table 45. Watchdog window period configuration, as shown in the screenshot below. And after setting the correct WD period time, you need to correctly feed the WD. Hope the above information is helpful to you. Best Regards, Celeste
記事全体を表示
i.MX8MP ハードウェア H.264 エンコーダ (VC8000E/Hantro) が動作しない – V4L2 エンコーダ ポーリング エラー「操作が動作しません」 私たちは、Hantro VC8000Eエンコーダーを使ってi.MX8M Plusプラットフォーム上でハードウェアH.264エンコーディングを有効にしようとしています。 カーネル設定が有効になりました CONFIG_VIDEO_IMX8M_VDOA=y CONFIG_MXC_HANTRO=y CONFIG_MXC_HANTRO_V4L2=y CONFIG_MXC_HANTRO_VC8000E=y CONFIG_V4L_MEM2MEM_DRIVERS=y CONFIG_VIDEO_V4L2=y CONFIG_MEDIA_SUPPORT=y デバイスツリー DTSにおいて、VPU/VC8000Eノードが有効になりました。 &vpu_g1 { ステータス = "正常"; };   &vpu_g2 { ステータス = "正常"; };   &vpu_vc8000e { ステータス = "正常"; };   &vpu_v4l2 { ステータス = "正常"; };     使用したテストパイプライン: GST_DEBUG=3 gst-launch-1.0\ videotestsrc !ビデオ変換!v4l2h264enc !フェイクシンク     GST_DEBUG=3 gst-launch-1.0videotestsrc !ビデオ変換!v4l2h264enc !フェイクシンク Fontconfigエラー: 書き込み可能なキャッシュディレクトリがありません Fontconfigエラー: 書き込み可能なキャッシュディレクトリがありません 0:00:01.324000750 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_audio_template_caps:フォーマット0x120000:「AVR(オーディオ Visual Research)」はマッピングされていません 0:00:01.324100250 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_audio_template_caps:フォーマット0x180000:「CAF(Apple Core Audio File)」はマッピングされません 0:00:01.324135000 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_オーディオ_template_caps:フォーマット 0x100000: 'HTK (HMM Tool Kit)' はマッピングされていません 0:00:01.324179500 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_audio_template_caps:フォーマット 0xc0000: 'MAT4 (GNU Octave 2.0 / Matlab 4.2)' は md ではありません 0:00:01.324212875 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_audio_template_caps:フォーマット 0xd0000: 'MAT5 (GNU Octave 2.1 / Matlab 5.0)' は md ではありません 0:00:01.324245125 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_audio_template_caps:フォーマット 0x210000: 'MPC (Akai MPC 2k)' はマッピングされていません 0:00:01.324283000 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_audio_template_caps:フォーマット0xe0000:「PVF(ポータブル音声フォーマット)」はマッピングされません 0:00:01.324318750 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_audio_template_caps:フォーマット 0x160000: 'SD2 (Sound Designer II)' はマッピングされていません 0:00:01.324363125 50377 0xaaaaf19f5a40 WARN default gstsfelement.c:97:gst_sf_create_audio_template_caps:フォーマット 0x190000: 'WVE (Psion Series 3)' はマッピングされていません Fontconfigエラー: 書き込み可能なキャッシュディレクトリがありません Fontconfigエラー: 書き込み可能なキャッシュディレクトリがありません 0:00:06.638305750 50254 0xaaaafd743f80 WARN GST_REGISTRY gstregistry.c:2003:gst_update_registry:レジストリ更新に失敗しました:/home/devuser/.cacyにレジストリキャッシュを書き込む際にエラーが発生しました パイプラインを一時停止状態に設定しています... ====== V4L2ENC: 1.24.0 ビルド、2024年7月24日 02:25:45。====== 0:00:06.800120125 50254 0xaaaafd743f80 WARN v4l2 gstv4l2object.c:5230:gst_v4l2_object_probe_caps: VIDIOC_t でピクセルアスペクト比をプローブできませんでした パイプラインはプリロール中です... 0:00:06.802941500 50254 0xffffb4000b70 FIXME default gstutils.c:4088:gst_element_decorate_stream_id_internal: ランダムストリームIDを作成する際、implemdを考えます。 レイテンシを再分配... 0:00:06.847293500 50254 0xffffb4000b70 WARN v4l2bufferpool gstv4l2bufferpool.c:875:gst_v4l2_buffer_pool_start: バッファが不確実または不足しています。 0:00:06.889086250 50254 0xffffb4000b70 WARN v4l2 gstv4l2object.c:6189:gst_v4l2_object_poll: error: poll error 1: 操作が許可されていません (1) エラー:from element /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0:リソースから読み取れませんでした。 追加のデバッグ情報: /usr/src/debug/gstreamer1.0-plugins-good/1.24.0.imx/sys/v4l2/gstv4l2object.c(6189):gst_v4l2_object_poll (): /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0: ポーリングエラー 1: 操作が許可されていません (1) エラー: パイプラインがプリロールを実行しません。 パイプラインをNULLに設定中... 0:00:06.892575000 50254 0xffffb4000b70 WARN v4l2videoenc gstv4l2videoenc.c:941:gst_v4l2_video_enc_handle_frame: エラー: フレームの処理に失敗しました。 0:00:06.892941125 50254 0xffffb4000b70 WARN v4l2videoenc gstv4l2videoenc.c:941:gst_v4l2_video_enc_handle_frame: エラー: メモリ不足か、fr が原因かもしれません エラー: 要素 /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0 から: フレームの処理に失敗しました。 追加のデバッグ情報: /usr/src/debug/gstreamer1.0-plugins-good/1.24.0.imx/sys/v4l2/gstv4l2videoenc.c(941):gst_v4l2_video_enc_handle_frame (): /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0: メモリ不足かドライバの故障が原因かもしれません エラー:パイプラインがプリロールを行ってくれません。 0:00:06.898059500 50254 0xffffb4000b70 WARN basesrc gstbasesrc.c:3175:gst_base_src_loop: エラー: 内部データストリームエラー。 0:00:06.898398750 50254 0xffffb4000b70 WARN basesrc gstbasesrc.c:3175:gst_base_src_loop: エラー: ストリーミングが停止しました。理由: エラー (-5) エラー: 要素 /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0 から: 内部データストリームエラー。 追加のデバッグ情報: /usr/src/debug/gstreamer1.0/1.24.0.imx/libs/gst/base/gstbasesrc.c(3175):gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: ストリーミングが停止しました。理由:エラー(-5) エラー: パイプラインがプリロールを実行しません。 0:00:06.927425375 50254 0xaaaafd743f80 WARN bufferpool gstbufferpool.c:1429:gst_buffer_pool_set_flushing: 非活性化のフラッシュ状態は変更できません 0:00:06.928232250 50254 0xaaaafd743f80 WARN バッファプール gstbufferpool.c:1429:gst_buffer_pool_set_flushing: 非活性化のフラッシュ状態は変更できません パイプラインの解放... 要求 以下をご提供ください: i.MX8MPハードウェアエンコーディングに必要なカーネル設定の完全なリスト。 VC8000E/Hantroエンコーダに必要なDTSエントリ。 必要なファームウェアファイルとその想定される保存場所。 GStreamerのプラグイン/パッケージが必要でした。 必要なマルチメディアライブラリ(imx-gstプラグイン、vpuラッパーなど)。 CMA/メモリに関する要件はありますか? エンコーダドライバーの初期化を検証する検証手順。 H.264ハードウェアエンコーディングのための推奨テストパイプライン。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano
記事全体を表示
S32DS 3.6.7 RTD 7.0.1 P02 HSE 代码生成错误 我正在尝试使用S32DS 3.6.7为S32K358生成与 HSE 相关的 RTD 代码,但我遇到了一个问题。 首先,我按以下顺序安装了以下更新站点: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip 安装状态如下图所示。 接下来,我通过选择下面显示的 SDK 创建了一个新项目。 然后,我在配置工具中添加了BaseNXP和Hse组件,如下所示。 但是,出现以下验证错误: Issue: Hse is not found in the toolchain/IDE project. The project will not compile! Level: Error Type: Validation Tool: Toolchain/IDE project Origin: Peripherals Target: Toolchain/IDE project: M7_0_0 Resource: platform.driver.Hse 我该如何解决这个问题并成功生成与 HSE 相关的 RTD 代码? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 你好, 我尝试安装了以下软件包后生成代码,但仍然遇到同样的验证错误。 按照您的建议,我首先卸载了所有与RTD相关的扩展程序,然后只安装了以下软件包: - SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip 安装状态如下所示。 但是,这样做之后,我在创建新项目时就无法再选择任何 SDK 了,如下图所示。 我应该如何解决这个问题? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 嗨@wodudwo 为了验证是否缺少软件包,请将您 IDE 中安装的软件包与下图所示的软件包进行比较? 此外,我们来尝试卸载所有与 S32K3 RTD 相关的软件包,然后只重新安装名称中包含“P02”的软件包。 BR,VaneB Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 嗨@wodudwo 我认为安装步骤中可能缺少某个步骤。以下是我成功安装软件包的步骤: 由于您已经安装了一些软件包,我建议您首先卸载所有与 S32K3 设备 RTD 相关的软件包,包括 S32K3 和 S32M 设备的 S32 配置工具 R1.8 NPI 数据包,因为这些软件包依赖于 RTD 软件包。 - 添加以下更新站点: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite_updated_D20260630.zip - 选择并安装名称中包含 P02 的软件包。允许 S32DS 自动选择并安装安装所需的任何其他依赖软件包。 - 等待安装成功完成,并允许 S32DS 重新启动。 - 重启后,选择并安装所有适用于 S32K3 和 S32M 设备的 S32 配置工具 R1.8 NPI 数据包组件。再次允许 S32DS 自动选择任何所需的依赖项。 - 等待安装成功完成,然后让 S32DS 再次重新启动。 按照这些步骤操作后,我的 IDE 中最终安装了六个 RTD 7.0.1 软件包(包括 P02)。通过这种设置,我可以将 HSE 驱动程序添加到我的项目中,而不会出现任何问题。
記事全体を表示
PNEV5180B 2.0 PN5180 Altium Schematics Are the PNEV5180B 2.0 PN5180 schematics available in ALtium format ? ALso PCB would be useful , mainly for the NFC antenna. We want to use the PN5180 and want to get  up and working asap Re: PNEV5180B 2.0 PN5180 Altium Schematics Hello @David-Lightbug Hope you are doing well. Please accept my apologies, PN5180 design files are not available. Perhaps you could refer to the PN5180 Evaluation board quick start guide, which includes some pictures showing the relevant schematics. Also, please refer to the PN5180 Antenna design. If possible, I will recommend considering PN5190 | NFC Frontend for payment. Following design files related to PNEV5190BP are available: - Module board - Base board Regards, Eduardo. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, Going through the altium schematics , they all appear to be the BGA package/  You have the PNEV5190M  (BGA packagein cct diagram) and   PNEV5190BP also BGA. I have found the evaluation board manual, PNEV5180B that shows the QFN package but not the altium files. Can you help. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, We offer a NFC Reader Library for PN5190. This library is designed for some Host MCUs from NXP's portfolio, such as LPC1769 and Kinetis K82; porting the functionality to a third-party platform is out of our support and must be done entirely by the customers. You can refer to the following articles and use them as a reference for the porting: - Using NFC Reader Library with LPC55S69 - NFC Reader Library Porting FRDM_K64F - NFC Reader Library Porting to i.MX RT1050 - NXP Community The available design files for PN5190 are based on our Development Board (PNEV5190BP), which embeds the BGA package. There is also a reference design for the VFLGA40 package: Module board PN5190 HVQFN design files; however, the purpose of this file is to illustrate the required connections for this specific package. Regards, Eduardo. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, Thanks for your quick reply. I will change to use the PN5190. Are the code compatible/ similar to the PN5180 , the reason I am asking is that I have noticed there are Arduino libraries  for the PN5180 but not the PN5180. DO you have libraires - we just want to get up and going quickly with the product.  The board design is likely to be ready and made in less than two weeks. Thanks
記事全体を表示
已安装 HSE 的 S32K311:软件崩溃和 MCU RESET,调试器无法连接 您好,NXP团队, 背景: MCU: S32K311 AUTOSAR RTD MCAL: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 HSE 固件(全内存): s32k3x1_hse_fw_0.12.0_2.55.0_pb250225.bin 完整调查报告以PDF格式附件形式提供。 主要问题 软件在 Clock_Ip_DistributePll() 中崩溃,MCU RESET。此外,调试器有时无法附加。 当我尝试热连接调试器时,复位原因有时会报告为 HSE_CLK_FAIL。 请您主要检查上述流程、IVT 和 DCF 记录,以及有关此问题发生原因及其解决方案的信息。如有任何其他需要的信息,请告知我们。 请您检查 HSE 安装程序、IVT 配置和 DCF 记录,并告知出现此问题的原因以及如何解决? 如有任何其他信息需要提供,请告知我们。 此致, 舒巴姆·帕德西 Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 提到的 70 秒和 20 秒是从 RESET 到 HSE_STATUS_INIT_OK 的时间。所以基本上只包含启动时间,对吗? 在所有设备上的表现都一样吗? Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 你好@davidtosenovjan 我们的软件由 FBL 和 APPL 组成,两者都使用相同的功能复位机制。 当 APPL 发起复位时,不会出现此问题。 当 FBL 发起 RESET 时,软件在 APPL 启动期间于 Clock_Ip_DistributePll() 内部崩溃。 最初,我们在 Mcu_InitClock() 之后、Mcu_DistributePllClock() 之前添加了对 HSE_STATUS_INIT_OK 的检查。这样就避免了车祸。然而,大约 20 秒后 HSE_STATUS_INIT_OK 才被设置,之后 APPL 的实际启动才继续进行。 今天,我们将 HSE_STATUS_INIT_OK 检查移到了 APPL 中的 Mcu_Init() 之前的更早阶段,如附图所示。 通过此序列,HSE_STATUS_INIT_OK 几乎立即被设置,并且不再观察到崩溃。 请问您能否澄清以下问题? 为什么只有当 FBL 发起 RESET 时才会出现这个问题,即使 FBL 和 APPL 使用的是相同的 RESET 机制? 为什么在 Mcu_InitClock() 之后检查 HSE_STATUS_INIT_OK 时大约需要 20 秒,但在 Mcu_Init() 之前检查时几乎立即可用? 为什么 FBL 中不需要 HSE_STATUS_INIT_OK 检查,而 APPL 启动时似乎需要? 请提供清晰的根本原因解释和推荐的初始化顺序。我们需要确保当前解决方案的稳健性,并且不会在生产环境中造成任何问题。 如有任何其他详情或时钟配置详情需要告知,请与我们联系。 此致, 舒巴姆·帕德西
記事全体を表示
PWMキャプチャはfrdm_mcxw72ボードでは動作しません こんにちは、 frdm_mcxw72 ボードで pwm キャプチャ サンプルを試してみましたが、残念ながらシリアル ツールのプリント メッセージには「 capture cycle err -134 」としか表示されません。frdm_mcxw72ボードのPTA21ピンには、1kHz、デューティサイクル50%のPWM信号が注入されているはずです。 デモケースからプロジェクトファイル全体をインポートしましたが、オーバーレイファイルだけを追加しただけで変更はありません。以下にオーバーレイファイルの設定があります。 なぜ正しい印刷情報がないのか、その理由を調べていただけますか?前もって感謝します! Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 あなたの調子が良いといいのですが。どのZephyrリポジトリを使っているのか、教えていただけますか? また、あなたは提示された例を参考にしていますか?何か変更しましたか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルドさん リポジトリのバージョンはV4.4.1.0です。以下は私の手順です 1. リポジトリからキャプチャ例のアプリケーションをインポートする 2. 最初のメッセージで投稿したオーバーレイファイルの内容であるDTSオーバーレイファイルをボードフォルダに追加します。 3. 手元にある frdm_mcxw72 ボードにビルドしてフラッシュすると、プリントメッセージは次のようになります。 「キャプチャサイクルエラー」、PWM信号を注入していないのでボードの状態は問題ないように見えますが、PTA21ピンにPWM信号を注入した後もプリントメッセージは同じです。     Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 どのリポジトリを使っているのか教えていただけますか? アップストリームとダウンストリームのどちらを使用していますか? また、そのサンプルコードは、修正なしでそちら側でも正常に動作しますか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルド リポジトリのバージョンはこちらです オーバーレイファイルだけを更新しますが、このファイルがなければビルドが成功しません。 よろしくお願いいたします! Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 Upstreamを使っているのか、それともDownstreamを使っているのか、教えていただけますか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルドさん すみません、ここでいう「上流」や「下流」が何なのかよく理解できませんでした。下流側であるべきだと思う。それとも別の説明を変えてもらえますか?
記事全体を表示
I need to configure DMA for SPI I am using S32DS IDE and RTD 3.0 can anyone tell me how to start the DMA with SPI with step by step instructions or any other example code if available Re: I need to configure DMA for SPI Thank you for your response Do this work for s32k322 MCU Re: I need to configure DMA for SPI Hi @ershi  Included with the RTDs are provided two example codes for SPI communication using DMA, one using Low-Level Drivers (Ip) and one using High-Level Drivers (MCAL). You can refer to the thread HOWTO: S32 Design Studio - Create a New S32DS Project from Example for guidance on how to import the examples. Also, you can refer to the example provided in the thread Example S32K31 SPI Multiple Packet Transmit & Receive: Solution for DMA Cache Issue. BR, VaneB Re: I need to configure DMA for SPI Hi @ershi  Although the examples are not specifically designed for the S32K322, the functionality is generally the same across the S32K3 family, unless otherwise stated in the Reference Manual Therefore, you can use this project as a reference for your implementation and adapt it as needed for your specific device. Re: I need to configure DMA for SPI I had configurated everything but still it is not working initially it is return as LPSPI_IP_STATUS_SUCCESS  for (Lpspi_Ip_AsyncTransmit )and second time it is showing failed LPSPI_IP_STATUS_FAIL  I can able to send the data through spi using this api without the dma Lpspi_Ip_SyncTransmit() I have attached few configuration screenshot 
記事全体を表示
Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hello NXP Support Team, We are evaluating object detection on the FRDM i.MX95 platform using the Neutron SDK v3.1.3 and are unable to generate an NPU-compatible model. The Neutron converter successfully loads the model, but reports that 0 operators are mapped to the Neutron NPU. Environment Target Board: FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: Tested with both YOLO11 and YOLOv8 eIQ Toolkit: Used for ONNX → TFLite conversion Model: Custom single-class peg detector Training Command $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 Export Command $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml We also tested an alternative workflow: Export PyTorch → ONNX Convert ONNX → INT8 TFLite using the NXP eIQ Toolkit Both workflows produced the same result when compiled with the Neutron SDK.   Neutron Compilation ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter \ --target imx95 \ --input best_int8.tflite \ --output my_model_int8_npu.tflite   Converter Output The converter reports: Operators after import: 341 Operators after optimization: 367 Operators converted: 0 Operator conversion ratio: 0 / 367 Number of Neutron graphs: 0 Warnings: WARNING: None of the operators from the graph was mapped to Neutron. WARNING: The converted model is the same as the input model because no operators were mapped to Neutron. WARNING: Graph has FLOAT operators which are NOT supported! This can result in low conversion ratio. Additional Information We observed the same behavior with: YOLO11 YOLOv8 Direct Ultralytics TFLite export ONNX → eIQ Toolkit → INT8 TFLite All generated TFLite models result in 0 operators being mapped by the Neutron compiler. Questions Are YOLOv8 or YOLO11 object detection models officially supported by the Neutron compiler for the i.MX95? Is there a recommended export pipeline for YOLO models targeting the i.MX95 NPU? Are there any known limitations with the current Neutron SDK (v3.1.3) regarding YOLO detection heads? Does NXP provide a reference YOLOv8/YOLO11 model that successfully compiles for the i.MX95 NPU? Is there any additional compiler option or preprocessing step required to enable operator mapping? We would appreciate any guidance, recommended workflows, or reference models that are known to work with the i.MX95 Neutron NPU. Thank you. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Thank you for your response. I would like to inquire if there is a standard procedure available for training, exporting, and deploying models on the IMX95 board. As we currently have the ARA2, we are looking to fully utilize its capabilities and customize our models. We have upcoming demos for NXP Tech Days, and your assistance in this matter would be greatly appreciated. Thank you for your help. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Tried the yolo8m model from eIQ model zoo on imx95 board with LF 2026 Q2 release image. kernel version is 6.18.20 using neutron SDK 3.1.2. it works.     You can try it firstly by: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model --graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so more info you can refer the README eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo What's more, you can attached model and details log of convert/complier. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Based on the converter log, the first issue to resolve is that the generated TFLite model still contains FLOAT operators:   WARNING: Graph has FLOAT operators which are NOT supported! For i.MX95 Neutron, the input to neutron-converter must be a TFLite model whose operators and quantization format are compatible with the Neutron compiler. In particular, the i.MX95 Neutron flow expects quantized TFLite and symmetric int8 weights. If the model still contains FLOAT operators/tensors after the Ultralytics export or ONNX-to-TFLite conversion, the converter may be unable to create any Neutron-compatible subgraph, which is consistent with the reported result:   Operators converted: 0   Number of Neutron graphs: 0 YOLOv8 has been evaluated on i.MX95 in some flows, but full end-to-end YOLOv8/YOLO11 offload should not be assumed for arbitrary Ultralytics exports. Depending on the exported TFLite graph, only part of the model may be converted to NeutronGraph and unsupported operators will remain on CPU. Therefore, the recommended next step is to inspect/profile the generated TFLite model and confirm: the graph is fully quantized, there are no FLOAT operators, weights are symmetric int8, input/output tensor types are compatible, or converted with the Neutron converter uint8-to-int8 options if applicable, YOLO post-processing such as decode/NMS is kept outside the NPU graph unless the exact operators are confirmed supported by the SDK. Please also ensure that the neutron-converter version and the Neutron runtime/firmware/delegate on the board are from the same compatible SDK/BSP release. As a recommended flow, please try the NXP/eIQ conversion path:   PyTorch -> ONNX with static input shape -> NXP/eIQ quantization with representative calibration data -> quantized TFLite -> neutron-converter --target imx95 If the model has uint8 input/output tensors, please also test:   --convert-inputs-uint8-to-int8   --convert-outputs-uint8-to-int8 If the conversion still reports 0 mapped operators after removing FLOAT operators, please share:   - the complete neutron-converter log with verbose/profiling output if available,   - the TFLite operator list,   - tensor data types and quantization parameters,   - the exact BSP/runtime Neutron delegate/firmware versions on the FRDM i.MX95 board,   - whether the YOLO detection head includes NMS or other post-processing inside the TFLite graph. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi  i am running ubuntu 24.04, but eiq_toolkit is avaialble for only 20.04.03.  how can i use eiqToolkit and Quantization Using eIQ Toolkit Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Recommended End-to-End Workflow Model Training (PC) Train using your preferred framework: Ultralytics YOLOv8 PyTorch TensorFlow ONNX-native workflows For object detection, NXP already provides YOLO reference recipes in the eIQ Model Zoo, including YOLOv8 object detection models. [github.com], [github.com] Example: Shell yolo detect train \ model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ epochs=100 ` Export to ONNX NXP generally recommends using ONNX as the interchange format before quantization and deployment. yolo export \ model=best.pt \ format=onnx The Neutron enablement presentations explicitly describe a flow based on: Plain Text PyTorch ↓ ONNX ↓ Quantization ↓ TFLite ↓ Neutron Converter rather than directly targeting deployment from training artifacts. Quantization Using eIQ Toolkit The Neutron workflow documentation recommends using the eIQ Toolkit quantization utilities: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: `` followed by: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite Show more lines This flow is explicitly documented in the i.MX95 Neutron enablement material. Compile for i.MX95 Neutron NPU neutron-converter \ --target imx95 \ --input model_int8.tflite \ --output model_neutron.tflite The Neutron converter creates Neutron-specific graph partitions that can be offloaded to the NPU. Validate Conversion Ratio A successful NPU deployment should report something similar to: Number of operators converted > 0 Number of Neutron graphs > 0 If you see: Operators converted: 0 Number of Neutron graphs: 0 then the model is not being accelerated by the NPU. Your current issue falls into this category. Deploy on FRDM-i.MX95 Run using TensorFlow Lite with the Neutron delegate: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` or ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so The i.MX Machine Learning User Guide identifies the Neutron Delegate as the acceleration mechanism for i.MX95 TensorFlow Lite models. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU In my test I did not train or export the model myself. I used a pre-generated YOLOv8 model from the eIQ Model Zoo and verified that it runs on the i.MX95 platform. The only command I actually used was: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` with the model: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite For custom models, the recommended NXP flow is: PyTorch ↓ ONNX (static input shape) ↓ eIQ Toolkit ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ Quantized TFLite ↓ neutron-converter --target imx95 Since your model reports: Plain Text Operators converted: 0 Number of Neutron graphs: 0 WARNING: Graph has FLOAT operators which are NOT supported! I suspect your generated TFLite graph is structurally different from the eIQ Model Zoo reference model. The first thing I would recommend is comparing the two models for: Input/output tensor type (INT8 vs UINT8) Presence of FLOAT operators Decode/NMS layers inside the graph Operator list reported by Netron / TFLite analyzer Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Can you please tell me how did you convert yolov8m_full_integer_quant.tflite to be able to run on the imx95 NPU?  Step followed and environment setup data(HOST).. would greatly help us. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Since eIQ Toolkit was validated on Ubuntu 20.04, the safest approach is: Docker Run a Ubuntu 20.04 container on your Ubuntu 24.04 host: docker run -it --name eiq \ ubuntu:20.04 /bin/bash Then install the required dependencies and eIQ Toolkit inside the container. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Unable to preserve confidence output when converting custom YOLOv8 ONNX model using eIQ Toolkit (onnx2quant) Overview Hi NXP Team, I'm trying to deploy a custom YOLOv8 single-class object detection model on the FRDM i.MX95 using the eIQ Toolkit. The complete conversion pipeline runs successfully, but after onnx2quant, the confidence output becomes all zeros while the bounding box outputs remain valid. Environment - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX Runtime 1.21.1 - TensorFlow 2.21 - neutron-converter 3.1.3 - Target: FRDM i.MX95 (tflite_runtime 2.19 + Neutron delegate) Conversion Pipeline 1. Train yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. Export ONNX yolo export model=best.pt format=onnx opset=13 3. Verify ONNX Input : (1,3,640,640) Output: (1,5,8400) ONNX Runtime inference: Confidence Channel Max = 0.773 4. Generate calibration dataset Shape : (1,3,640,640) dtype : float32 Range : 0.0 - 1.0 5. Quantize onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx Also tested: onnx2quant best.onnx -u Both produce the same result. 6. Verify Quantized ONNX Output : (1,5,8400) Bounding box channels remain valid. Confidence: Min = 0 Max = 0 Mean = 0 Decoded detections = 0 7. Convert to TFLite onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite Compilation succeeds. Operator conversion: 278 / 325 (85.5%) Investigation Performed Verified: • PyTorch model works • ONNX export works • ONNX Runtime inference works • Calibration dataset is correct • Real and random calibration produce identical results • TFLite reproduces the Quantized ONNX output • Neutron reproduces the TFLite output The issue first appears after: ONNX ↓ onnx2quant ↓ Quantized ONNX (confidence becomes zero) Additional Observation NXP reference model: Input : (1,640,640,3) INT8 Output: (1,84,8400) INT8 My converted model: Input : (1,3,640,640) FLOAT32 Output: (1,5,8400) FLOAT32 Is there a recommended export or quantization workflow for custom YOLOv8 models that preserves the confidence output? Could this be a limitation or bug in onnx2quant for models with a (1,5,8400) output?
記事全体を表示
IMXRT LPUART 非阻塞传输 API 使得错误处理变得困难。 您好, 我一直在研究 LPUART 的“传输”API,用于基于中断的非阻塞传输。它似乎很好地封装了所有“正常情况”下的 LPUART 中断处理等,并提供了一个良好的高级 API,用于在数据准备就绪时接收数据(即)。处理 IDLE、RX 就绪、TX 完成等状态)。然而,这使得处理 UART 错误变得非常困难。 LPUART_TransferHandleIRQ 函数内部没有错误处理,并且在 fsl_lpuart.c 中紧随其后的是一个虚假的空 LPUART_TransferHandleErrorIRQ 函数,其中包含注释“由用户实现”。这看起来完全是半成品。 处理 UART 错误的唯一方法似乎是覆盖默认的 LPUARTx_IRQHandler 函数,这样就不需要调用 LPUARTx_RX_DriverIRQHandler(或 TX),而是需要调用自己的函数来处理错误,并将“正常情况”中断传递给原始的 LPUARTx_RX/TX_DriverIRQHandler,以便它可以调用 LPUART_TransferHandleErrorIRQ。 此外,您还需要在传输 API 之外通过调用 LPUART_EnableInterrupts 来启用这些错误中断,并在错误处理中调用 LPUART_DisableInterrupts 并处理清除它们等操作。 这样处理错误似乎很麻烦。为什么这项功能没有内置到转账 API 中? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 感谢您提供的详细反馈。我理解 SDK 可能有点含糊不清,因为这些 SDK 的目的是为每个外围设备功能提供常见的用例。我们也一直在努力改进我们的 API,这也要感谢像这样的建议。感谢您的建议,我们希望 LPUART 的错误处理功能能在未来的版本中得到实现。 另一方面,请问您想处理哪些具体的错误状态,以及您使用的是哪款设备?有了这些信息,我可以向您推荐一些与这些错误状态相关的文档,这些文档可能会对您的实施有所帮助。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 所有可能的错误。这几乎适用于所有具有传输 API 但没有错误处理的外围设备(SPI、I2C 等)。IMXRT1172 上的 LPUART 存在帧错误、奇偶校验错误和噪声错误,这些错误无法得到处理。遗憾的是,目前所有这些外围设备都需要一些破解才能处理使用传输 API 时出现的错误。我必须覆盖默认的 IRQ 处理程序,以便在调用 SDK 处理程序之前检查错误。 谢谢! -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 我知道这可能需要额外的开发时间,对此我们深表歉意,我们将继续努力改进我们的SDK。作为参考,您可以查看 SDK(版本 26.6)中名为“LPUART_TransferHandleIRQ”的函数的以下结构,并根据您的应用程序需要实现类似的恢复流程。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 如果您还有其他问题,请告诉我。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 是的,我已经实现了类似的功能。谢谢你发来这个。
記事全体を表示
无法为 i.MX95 Neutron NPU 编译 YOLOv8/YOLO11 TFLite 模型 您好,NXP支持团队, 我们正在使用Neutron SDK v3.1.3在FRDM i.MX95平台上评估目标检测功能。并且无法生成与 NPU 兼容的模型。Neutron 变流器成功加载了模型,但报告称0 个算子映射到 Neutron NPU 。 环境 目标板:FRDM i.MX95 Neutron SDK:3.1.3 Ultralytics:已使用 YOLO11 和 YOLOv8 进行测试 eIQ 工具包:用于 ONNX 到 TFLite 的转换 型号:定制单类钉子检测器 训练司令部 $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 导出命令 $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml 我们还测试了另一种工作流程: 导出 PyTorch → ONNX 使用 NXP eIQ 工具包将 ONNX 转换为 INT8 TFLite 使用 Neutron SDK 编译时,两种工作流程都产生了相同的结果。   中子汇编 〜/下载/eiq-neutron-sdk-linux-3.1.3/bin/neutron-变流器--target imx95 --input best_int8.tflite --output my_model_int8_npu.tflite   变流器输出 变流器报告: 导入后运算符:341 优化后的运算符数:367 已转换运算符:0 操作员转换率:0 / 367 中子图数量:0 警告: 警告:图中所有运算符均未映射到 Neutron。 警告:转换后的模型与输入模型相同,因为没有将任何算符映射到 Neutron。 警告:图表中包含不支持的 FLOAT 运算符!这会导致转化率低。 更多信息 我们观察到以下情况也存在同样的现象: YOLO11 YOLOv8 直接 Ultralytics TFLite 导出 ONNX → eIQ 工具包 → INT8 TFLite 所有生成的 TFLite 模型都导致 Neutron 编译器映射 0 个算符。 问题 Neutron 编译器是否正式支持 i.MX95 的 YOLOv8 或 YOLO11 目标检测模型? 对于目标平台为 i.MX95 NPU 的 YOLO 模型,是否有推荐的导出流程? 当前 Neutron SDK (v3.1.3) 是否存在任何已知限制?关于YOLO检测头? NXP 是否提供可在 i.MX95 NPU 上成功编译的 YOLOv8/YOLO11 参考模型? 启用运算符映射是否需要额外的编译器选项或预处理步骤? 我们非常希望获得任何与 i.MX95 Neutron NPU 兼容的指导、推荐工作流程或参考模型。 谢谢! Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 谢谢你的回复。​​ 我想咨询一下是否有标准程序可用于在IM X95板上进行模型的训练、导出和部署。​​​​​​​​​​​ 由于我们目前拥有ARA2 ,我们正在寻求充分利用其功能并定制我们的模型。我们将在NXP技术日上进行演示,如果您能在这方面提供帮助,我们将不胜感激。​​​​​​​​​​​ 感谢您的帮助。​​ Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 在 imx95 主板上尝试了 eIQ 模型库中的 yolo8m 模型,使用了 LF 2026 Q2 版本镜像。内核版本为 6.18.20,使用 Neutron SDK 3.1.2,运行正常。     您可以先尝试以下方法: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model--graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so 更多信息请参阅 README 文件eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo 此外,您还可以附加转换/编译的模型和详细日志。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 根据变流器日志,首先要解决的问题是生成的 TFLite 模型仍然包含 FLOAT 运算符: 警告:图表中包含不受支持的浮点运算符! 对于 i.MX95 Neutron,中子变流器的输入必须是 TFLite 模型,其算符和量化格式与 Neutron 编译器兼容。具体来说,i.MX95 中子流需要量化的 TFLite 和对称的 int8 权重。如果模型在 Ultralytics 导出或 ONNX 到 TFLite 转换后仍然包含 FLOAT 运算符/张量,则变流器可能无法创建任何 Neutron 兼容的子图,这与报告的结果一致: 已转换运算符:0 中子图数量:0 YOLOv8 已在 i.MX95 上进行过一些流程的评估,但对于任意 Ultralytics 导出,不应假定完全端到端的 YOLOv8/YOLO11 卸载。根据导出的 TFLite 图,模型可能只有一部分会转换为 NeutronGraph,而不支持的操作符将保留在 CPU 上。因此,建议的下一步是检查/分析生成的 TFLite 模型并确认: 该图已完全量化。 没有浮动操作商。 权重是对称的int8, 输入/输出张量类型兼容,或者如果适用,可以使用 Neutron 变流器 uint8 到 int8 选项进行转换。 除非 SDK 确认支持确切的操作符,否则 YOLO 后处理(例如解码/NMS)将保留在 NPU 图之外。 另外,请确保板上的 Neutron 变流器版本和 Neutron 运行时/固件/委托来自同一个兼容的 SDK/电路板支持包 版本。 建议采用 NXP/eIQ 转换路径: PyTorch -> ONNX(静态输入形状) -> NXP/eIQ 量化(使用代表性校准数据) -> 量化后的 TFLite -> 中子变流器 --target imx95 如果模型具有 uint8 输入/输出张量,请同时进行以下测试: --将输入的 uint8 转换为 int8 --convert-outputs-uint8-to-int8 如果移除浮点运算符后,转换结果仍然显示 0 个已映射运算符,请分享: - 完整的 中子变流器 日志,如有详细/分析输出,请提供。 - TFLite 操作员列表, - 张量数据类型和量化参数, - FRDM i.MX95 板上确切的 电路板支持包/运行时 Neutron 代理/固件版本, - YOLO 检测头是否包含 NMS 或 TFLite 图中的其他后处理。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 在我的测试中,我没有自己训练或导出模型。我使用了 eIQ 模型库中预先生成的 YOLOv8 模型,并验证了它在 i.MX95 平台上运行。 我实际使用的唯一命令是: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` 以该模型为例: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite 对于定制模型,NXP 推荐的流程如下: PyTorch ↓ ONNX(静态输入形状) ↓ eIQ 工具包 ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ 量化 TFLite ↓ 中子变流器 --target imx95 由于您的模型报告: 纯文本 已转换运算符:0 中子图数量:0 警告:图表中包含不支持的 FLOAT 运算符! 我怀疑您生成的 TFLite 图在结构上与 eIQ 模型库参考模型不同。我首先建议做的是比较这两个型号的以下方面: 输入/输出张量类型(INT8 与 UINT8) 浮式经营者的存在 图内的解码/NMS层 Netron/TFLite 分析器报告的运营商列表 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 你好 我运行的是 ubuntu 24.04,但是 eiq_toolkit 仅适用于 20.04.03 版本。 如何使用 eiqToolkit 和使用 eIQ Toolkit 进行量化 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 请问您是如何将 yolov8m_full_integer_quant.tflite 转换为能够在 imx95 NPU 上运行的? 以下步骤和环境设置数据(主机)将对我们非常有帮助。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 推荐的端到端工作流程 模型训练(PC) 使用您偏好的框架进行训练: Ultralytics YOLOv8 PyTorch Tensorflow ONNX原生工作流 对于目标检测,NXP 已经在 eIQ 模型库中提供了 YOLO 参考配方,包括 YOLOv8 目标检测模型。[github.com] ,[github.com] 示例: shell yolo 检测训练 \ model=yolov8n.pt \ data=dataset.yaml imgsz=640 \ epochs=100 ` 导出到 ONNX NXP 通常建议在量化和部署之前使用 ONNX 作为交换格式。 yolo 导出 \ model=best.pt \ format=onnx Neutron 启用演示文稿明确描述了基于以下流程的说明: 纯文本 PyTorch ↓ ONNX ↓ 量子化 ↓ TFLite ↓ 中子变流器 而不是直接从训练工件中寻找部署目标。 使用 eIQ 工具包进行量化 Neutron 工作流程文档建议使用 eIQ Toolkit 量化工具: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c 输入:: `` 其次是: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite 显示更多行 该流程在 i.MX95 Neutron 实现材料中有明确记录。 为 i.MX95 Neutron NPU 编译 中子变流器 --target imx95 \ --输入 model_int8.tflite \ --输出 model_neutron.tflite Neutron 变流器创建 Neutron 特有的图分区,这些分区可以卸载到 NPU 上。 验证转化率 NPU 部署成功后,应报告类似以下内容: 转换的操作员数量 > 0 中子图数量 > 0 如果你看到: 已转换运算符:0 中子图数量:0 那么该模型就没有被NPU加速。 你目前的问题就属于这一类。 部署在 FRDM-i.MX95 上 使用 TensorFlow Lite 和 Neutron 委托运行: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` 或 ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so i.MX 机器学习用户指南将Neutron Delegate定义为 i.MX95 TensorFlow Lite 模型的加速机制。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 由于 eIQ Toolkit 已在 Ubuntu 20.04 上验证过,因此最安全的方法是: Docker 在 Ubuntu 24.04 主机上运行 Ubuntu 20.04 容器: docker run -it --name eiq \ ubuntu:20.04 /bin/bash 然后,在容器内安装所需的依赖项和 eIQ Toolkit。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 使用 eIQ Toolkit (onnx2quant) 转换自定义 YOLOv8 ONNX 模型时,无法保留置信度输出。 概述 NXP团队您好, 我正在尝试使用 eIQ Toolkit 在 FRDM i.MX95 上部署自定义 YOLOv8 单类目标检测模型。 整个转换流程运行成功,但在 onnx2quant 之后,置信度输出全部变为零,而边界框输出仍然有效。 环境 - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX 运行时 1.21.1 - TensorFlow 2.21 - 中子变流器 3.1.3 - 目标:FRDM i.MX95(tflite_runtime 2.19 + Neutron delegate) 转换管道 1. 火车 yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. 导出 ONNX yolo export model=best.pt format=onnx opset=13 3. 验证 ONNX 输入:(1,3,640,640) 输出:(1,5,8400) ONNX 运行时推理: 置信度通道最大值 = 0.773 4. 生成校准数据集 形状:(1,3,640,640) 数据类型:float32 范围:0.0 - 1.0 5. 量化 onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx 同时测试了: onnx2quant 最佳.onnx -u 两者产生的结果相同。 6. 验证量化的 ONNX 输出:(1,5,8400) 边界框通道仍然有效。 信心: 最小值 = 0 最大值 = 0 平均值 = 0 解码检测结果 = 0 7. 转换为 TFLite 格式 onnx2tflite best_quant.onnx -o best.tflite 8. 为 Neutron 编译 neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite 编译成功。 操作员转化率:278 / 325 (85.5%) 已展开调查 已核实: • PyTorch 模型有效 • ONNX 导出工作 • ONNX 运行时推理功能正常 • 校准数据集正确 • 真实校准和随机校准产生相同的结果 • TFLite 重现量化的 ONNX 输出 • Neutron 可以重现 TFLite 的输出 该问题首次出现于以下情况: ONNX ↓ onnx2quant ↓ 量化 ONNX(置信度变为零) 补充观察 恩智浦参考模型: 输入:(1,640,640,3) INT8 输出:(1,84,8400) INT8 我转换后的模型: 输入:(1,3,640,640) FLOAT32 输出:(1,5,8400) FLOAT32 对于自定义 YOLOv8 模型,是否有推荐的导出或量化工作流程,能够保留置信度输出? 对于输出为 (1,5,8400) 的模型,这可能是 onnx2quant 的一个限制或错误吗?
記事全体を表示