Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
无法检测到 LPC18xx 的看门狗复位 我无法检测看门狗何时RESET。我目前正在按照用户指南中的步骤操作,指南中指出: 看门狗超时标志(WDTOF)经过检查后可确定看门狗是否导致了复位条件。 WDTOF标志必须通过软件清零。 虽然设备重置成功,但之后该标志似乎并未被设置。 我看到之前有一个关于 LPC4357 类似问题的帖子(已解决:LPC4357:无法检测到看门狗 RESET - NXP 社区),但我没有在 LPC18xx 勘误表中看到任何相关信息。 请问LPC18xx是否存在与上述相同的问题? LPC18xx Re: Cannot detect watchdog reset for LPC18xx 嗨@ejg 谢谢你的帖子! 请问您使用的是哪一款LPC18xx? 另外,你们是在什么时候审查国旗的? 如果从lpc18xx_wwdt.h调用WWDT_Init函数,它会清除中断标志,因此需要先读取WDTOF。 Re: Cannot detect watchdog reset for LPC18xx 嗨@carlos_o ,谢谢你的回复。 我正在使用LPC1837。 启动时,在与任何其他 WWDT 寄存器交互之前,会检查该标志。CMSIS SystemInit 完成后,我设置了系统同步,然后检查此标志。 Re: Cannot detect watchdog reset for LPC18xx 嗨@ejg 是的,LPC18xx 与 LPC43xx 存在同样的问题。 要确定核心复位的原因,请参阅 LPC18xx 用户手册中的第 14.5.1 节“确定核心复位的原因”。 BR 爱丽丝
View full article
Cannot detect watchdog reset for LPC18xx I have a problem detecting when a watchdog reset has occurred. I am currently following the steps listed in the user guide which states: The Watchdog time-out flag (WDTOF) can be examined to determine if the Watchdog has caused the reset condition. The WDTOF flag must be cleared by software. Although the device resets correctly, the flag doesn't appear to be set afterwards. I saw there was an old post related to a similar issue on the LPC4357 (Solved: LPC4357: Cannot detect watchdog reset - NXP Community), but I couldn't see anything listed in the LPC18xx errata. Please could you confirm whether the LPC18xx suffers from the same issue as above? lpc18xx Re: Cannot detect watchdog reset for LPC18xx Hi @ejg  Thank you for the post! Could you please specify which LPC18xx are you using?  Also, at what time did you review the Flag? If you call the WWDT_Init function from lpc18xx_wwdt.h it clears the interrupt flags, so the WDTOF needs to be read before.  Re: Cannot detect watchdog reset for LPC18xx Hi @carlos_o , thank you for your reply. I am using LPC1837. The flag is checked at startup before interacting with any other WWDT registers. After CMSIS SystemInit completes, I setup the systick, and then check this flag. Re: Cannot detect watchdog reset for LPC18xx Hi @ejg  Yes, LPC18xx has the same issue as LPC43xx. To determine the cause of the core reset, please refer to Section 14.5.1, "Determine the Cause of a Core Reset," in the LPC18xx User Manual. BR Alic
View full article
S32K144EVB-Q100 Rev D 回路図 こんにちは。S32K144EVB-Q100 Rev Dの回路図を探しています。ボードにCANメッセージを送らせることができません。そのボードのCAN 0にメッセージを送信するためのサンプルコードはありますか?SPIを使ってCANトランシーバが強制ノーマルモードになっていることを確認でき、CANは動作しているはずです。 Re: S32K144EVB-Q100 Rev D Schematic S32DSのサンプルコードでご確認くださいS32K144EVB...もし見つからなかったら教えてください... Re: S32K144EVB-Q100 Rev D Schematic こんにちは、 @db16122 さん。 もしリバS32K144EVB Dのデザインファイルが必要なら、ぜひお知らせください。 よろしくお願いします、 ジュリアン Re: S32K144EVB-Q100 Rev D Schematic こんにちは、@rosejp03 さん。 デザインファイルについてコミュニティにプライベートメッセージを送りました。 CAN機能についてですが、Rev. C(現在使っているボード)とRev. Dは全く同じCAN設計とトランシーバー(UJA1169)を持っています: S32K144EVB-Q100 Rev. DS32K144EVB-Q100 Rev. D S32K144EVB Rev. C1S32K144EVB Rev. C1 既存の例を使用していますか?AN5413: S32K1xxシリーズの料理本か、RTDパッケージに含まれるもののどちらかですか? 12Vジャックコネクタを使用していますか?J107の位置を1-2に変更し、ボードに12Vの電源を入れてください。 CANコミュニケーションはどのようにテストしていますか?他のEVBやCANアナライザー、その他何かを使っていますか?バスのスコープを試してみてくれない? よろしくお願いします、 ジュリアン
View full article
ARM 2018.R1用S32 Design Studioのライセンス延長申請 現在、私たちの製品の一つには ARM 2018.R1(Windows)用のS32 Design Studio を使用しています 。ライセンスは最近期限切れとなり、ソフトウェアのアクティベートができません。 アクティベーションコードを使ってアクティベーションキーを生成しようとすると、生成されたキーも期限切れと報告され、IDEの使用ができません。 当社の認証コードは以下のとおりです。 アクティベーションコード: FF6A-EDA4-CDF0-7186 このアクティベーションコードに関連するライセンスの延長または更新、またはソフトウェアへのアクセスを取り戻すための適切な手順についてアドバイスをいただけますか? このプロジェクトはこの開発環境に依存しているため、皆様のご協力は大変ありがたいです。 よろしくお願いします。 Re: Request to Extend License for S32 Design Studio for ARM 2018.R1 こんにちは、 お客様のS32DSライセンスが延長されました。 Re: Request to Extend License for S32 Design Studio for ARM 2018.R1 ありがとう。しかし、まだソフトウェアを有効化できません。オンラインとオフラインの両方でアクティベーションを試しましたが、どちらも失敗しました。エラーメッセージは以下のとおりです。
View full article
Version 2 issues: C code generation, preview Hi! I started testing GUI Guider version 2, and I found a couple of issues (starting with an empty template, Windows simulator). I started defining the content of the top layer putting an image button, creating an event handler to switch state when the button is long pressed. The generated the code has some errors, like: gg_event_layer_top.c:   static void lv_layer_top()_event_handler(lv_event_t * e) {     ...   } void gg_event_init_layer_top(gg_ui_t * ui😞   lv_obj_add_event_cb(ui->layer_top.lv_layer_top(),  lv_layer_top()_event_handler, LV_EVENT_ALL, ui); (parenthesis create a parsing error) Manually removing the parenthesis, the error below is generated: .../generated/events/gg_event_layer_top.c:59:38: error: 'gg_layer_top_t' has no member named 'lv_layer_top' (gg_layer_top_t definition doesn't include that member) Am I missing some definition to make a correct generation of those functions? Re: Version 2 issues: C code generation, preview Hi @poldo  May i ask how can i reproduce this issue? BR Harry Re: Version 2 issues: C code generation, preview Hi @Harry_Zhang , thank you for your reply. This is what I did: - On layer_top (clickable flag added, is this necessary?) I created a container for my buttons (no clickable flag added)  - Inside the container I created an image button (clickable flag added)  - I attached the event "Long Pressed" to the button Generated code contains the syntax errors above. // In gg_event_layer_top.c static void lv_layer_top()_event_handler(lv_event_t * e) { gg_ui_t * ui = lv_event_get_user_data(e); lv_event_code_t code = lv_event_get_code(e); switch(code) { default: break; } } void gg_event_init_layer_top(gg_ui_t * ui) { lv_obj_add_event_cb(ui->layer_top.lv_layer_top(), lv_layer_top()_event_handler, LV_EVENT_ALL, ui); lv_obj_add_event_cb(ui->layer_top.Keypad_btnEnable, Keypad_btnEnable_event_handler, LV_EVENT_ALL, ui); } Removing the parenthesis the syntax error is about the member lv_layer_top not existing: // In custom.h typedef struct { lv_obj_t * Keypad; lv_obj_t * Keypad_btnEnable; } gg_layer_top_t; BR Poldo Re: Version 2 issues: C code generation, preview Hi @poldo  I tried to reproduce this issue. The generated code is correct. May I ask what I missed? BR Harry Re: Version 2 issues: C code generation, preview Hi @Harry_Zhang . The issue is when you create objects on the top layr. I'm attaching my file for your review and test. Re: Version 2 issues: C code generation, preview Hi @poldo  Thanks for your project, we have reproduced this issue. This is a bug. We will fix it in the next version. Thank you for your understanding. BR Harry Re: Version 2 issues: C code generation, preview Thank you, @Harry_Zhang . Is there a workaround that could be used while waiting for the update? BR Re: Version 2 issues: C code generation, preview This is a bug, and the fix is simple. Find your guiguider file and open it in text mode. Locate the event_list, remove any extra content, and then use the guider to reload the project. The generated code will return to normal.
View full article
バージョン2の問題点:Cコード生成、プレビュー こんにちは! GUI Guiderバージョン2のテストを始め、いくつかの問題(まずは空のテンプレート、Windowsシミュレータ)に気づきました。 トップレイヤーの内容を定義し、画像ボタンを入れ、ボタンを長押ししたときに状態を切り替えるイベントハンドラを作成し始めました。 生成されたコードには、次のようなエラーがあります。 gg_event_layer_top.c: 静的虚無 lv_layer_top()_event_handler(lv_event_t * e) { ... } void gg_event_init_layer_top ( gg_ui_t * ui😞 lv_obj_add_event_cb(ui->layer_top.lv_layer_top(), lv_layer_top()_event_handler, LV_EVENT_ALL, ui); (括弧は構文解析エラーの原因となります) 括弧を手動で削除すると、以下のエラーが発生します。 .../generated/events/gg_event_layer_top.c:59:38: エラー:「gg_layer_top_t」に「lv_layer_top」という名前のメンバーがいません (gg_layer_top_t の定義にはそのメンバーは含まれていません) これらの関数を正しく生成するために必要な定義が何か見落とされているのでしょうか? Re: Version 2 issues: C code generation, preview こんにちは、 @poldo さん。 この問題を再現するにはどうすればよいか教えていただけますか? BR ハリー Re: Version 2 issues: C code generation, preview こんにちは、 @Harry_Zhang さん、ご返信ありがとうございます。 私がやったことはこうです。 - layer_top にクリック可能なフラグを追加しましたが、これは必要でしょうか?ボタン用のコンテナを作成しました(クリック可能なフラグは追加していません) - コンテナ内で画像ボタンを作成しました(クリック可能なフラグが追加されました) - 「Long Pressed」というイベントをボタンに付けました 生成されたコードには上記の構文エラーが含まれています。 // In gg_event_layer_top.c static void lv_layer_top()_event_handler(lv_event_t * e) { gg_ui_t * ui = lv_event_get_user_data(e); lv_event_code_t code = lv_event_get_code(e); switch(code) { default: break; } } void gg_event_init_layer_top(gg_ui_t * ui) { lv_obj_add_event_cb(ui->layer_top.lv_layer_top(), lv_layer_top()_event_handler, LV_EVENT_ALL, ui); lv_obj_add_event_cb(ui->layer_top.Keypad_btnEnable, Keypad_btnEnable_event_handler, LV_EVENT_ALL, ui); } 括弧を削除すると、構文エラーはメンバーlv_layer_topが存在しないことに関するものです。 // In custom.h typedef struct { lv_obj_t * Keypad; lv_obj_t * Keypad_btnEnable; } gg_layer_top_t; BR ポルド Re: Version 2 issues: C code generation, preview こんにちは、 @poldo さん。 この問題を再現しようと試みました。 生成されたコードは正しいです。 私が何か見逃した点があれば教えていただけますか? BR ハリー Re: Version 2 issues: C code generation, preview こんにちは、 @Harry_Zhang さん。 問題は、最上層にオブジェクトを作成する場合です。レビューとテストのためにファイルを添付します。 Re: Version 2 issues: C code generation, preview こんにちは、 @poldo さん。 プロジェクトをありがとうございます。この問題を再現できました。 これはバグです。 次期バージョンで修正します。 ご理解いただきありがとうございます。 BR ハリー Re: Version 2 issues: C code generation, preview これはバグであり、修正方法は簡単です。guiguiderファイルを見つけて、テキストモードで開いてください。event_list を見つけて、不要なコンテンツを削除してから、ガイドを使用してプロジェクトを再読み込みしてください。生成されたコードは正常に戻ります。 Re: Version 2 issues: C code generation, preview ハリー・チャンさん、ありがとうございます。 アップデートを待つ間に使える回避策はありますか? BR
View full article
GuiGuiDer2.0.0构建目标设备时出错 我现在创建了一个基于frdm_mcx947的guiguider工程,使用的版本是2.0.0,选用的ARM GCC为14.4.1。 我已经配置好了arm gcc工具。 编译时报错信息如下:C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe 11:41:00INFObuild-target Started11:41:00INFOTarget Executor initialized11:41:00INFOBuilding target with armgcc toolchain...11:41:00INFOStarting ARM GCC build...11:41:00INFOSearching for ARM GCC toolchain in system PATH...11:41:00INFOExecuting: where arm-none-eabi-gcc11:41:00INFO'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ���11:41:00ERRORARM GCC not found in system PATH: Command failed with code 1: 'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ��� 11:41:00ERRORARM GCC build error: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERRORBuild failed: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERROROperation failed: ARM GCC toolchain not found. Please install it and add to system PATH. 我使用在cmd中查找编译工具是成功的: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe
View full article
对 Guiguider 许可证合规性的担忧 尊敬的恩智浦半导体公司: 我写信是为了举报贵公司 Guider 软件可能违反许可协议的情况。 据我们了解,您的 Guider 软件许可明确禁止将其用于基于非 NXP 系列芯片的产品开发中的商业用途。然而,一家大型跨国公司目前正在使用该软件开发基于瑞芯微系列主控芯片的商业产品,这显然违反了您的许可条款。 我想请问:NXP是否计划采取任何强制措施来保护其在此事中的知识产权?此外,如果我要就此违规行为提出正式投诉,您需要哪些具体证据才能启动调查? 期待您的回复。 回复: Concern about Guiguider License Compliance guiguider违反许可证使用问题。 贵公司的guider软件许可证明确禁止使用于非nxp系列芯片的商业开发。现有某大型跨国企业公司违反了该许可证条例,将该软件应用于瑞芯微系列主控芯片的商业产品上。贵公司是否会展开维权活动?如果我想举报,应该提供什么证据。
View full article
i.MX RT1050 ダウンロードアルゴリズム 現在使用している開発環境は、i.MX RT1050 を使用した MCUXPRESSO IDE です。i.MX RT1050 には内蔵フラッシュメモリがないため、外部フラッシュメモリを使用する際にはアルゴリズムをダウンロードする必要があることは理解しています。しかし、ダウンロードするアルゴリズムは使用するフラッシュメモリによって異なります。公式ドキュメントには、目的のアルゴリズムを迅速かつ容易に入手する方法が記載されていますか? Re: i.MX RT1050 下载算法 こんにちは、SDFDSFSFさん、 以下の順序で行うことをお勧めします。 1. プロジェクトのプロパティで、外部のFlashダウンロードアルゴリズムを選択します。NXPは、いくつかの主要なFlashダウンロードアルゴリズムを提供しています。 プロジェクトを右クリックして「プロパティ」→「MCU設定」→「メモリの詳細」を選択し、NXPがサポートするフラッシュドライバを選択してください。 MCUXpresso 用のフラッシュドライバは通常、nxp\LinkServer_xx.x.xx\binaries\Flash ディレクトリにあり、拡張子は .cfx です。 2. 選択したフラッシュメモリがSFDPをサポートしている場合は、まずSFDPドライバを試してください。 MCUXpressoでは、MIMXRT1050_SFDP_QSPI.cfxのようなドライバを選択できます。このタイプのSFDPドライバの重要な点は、フラッシュメモリに自己記述パラメータを組み込むことで、特定の部品番号固有のアルゴリズムへの依存度を低減できることです。 3. テンプレートを使って自分で作成する。 アプリケーションマニュアルを参照してください:https://www.nxp.com/docs/en/application-note/AN13386.pdfカスタムCFXファイルを生成します。変更する際は、主要なパラメータは、外部フラッシュデータシートのテスト結果とSDKに含まれるflexspi_nor_pollingデモから取得する必要があります。 ダウンロードアルゴリズムに加えて、XIP/ブートヘッダーの設定も必要です。詳細については、「解決済み:フラッシュインターフェースの初期化 - NXPコミュニティ」を参照してください。 上記は基本的な方法です。使用しているFlashの機種や、現時点でどのような問題に直面しているかなど、より詳細な情報を提供していただければ、より的確なサポートを提供できます。 よろしくお願いします、 シェリー・チャン i.MX RT1050 下载算法 J-Linkを使用しており、 MCUXpressoでMIMXRT1050_SFDP_QSPI.cfxを選択しました。ダウンロードに失敗しました。 Re: i.MX RT1050 下载算法 MCUXpresso IDEでIMXRT1052用の独自のJ-Linkアルゴリズムを作成するにはどうすればよいですか? 私のFlashファイルはWINBOD 25Q256JVEQです。 現在使用しているMCUXpresso IDEのバージョンはMCUXpresso IDE v25.6です。SDK_EVBKのバージョンは26.06.00です。どのサンプルプログラムを修正すれば、目的のダウンロードアルゴリズムを生成できるのか分かりません。 Re: i.MX RT1050 下载算法 お使いのハードウェアのピン構成が評価ボードと異なる可能性があります。iMXRT1050_QSPIプロジェクトを修正して、cfxファイルを独自に生成することをお勧めします。 Re: i.MX RT1050 下载算法 MCUXpresso IDEでJ-Linkを使用しても問題ないでしょうか? MCUXpresso IDEのアルゴリズムはCMSIS-DAPタイプのエミュレータでしか使用できないという意見も見かけたのですが。 Re: i.MX RT1050 下载算法 @SDFDSFSF様、 参考例は、nxp/LinkServer ディレクトリにあり、プロジェクト名は iMXRT1050_QSPI です。 ピン配置が評価ボードと異なる場合は、ピン配置構成を変更する必要があります。フラッシュメモリ構成もデータシートに従って変更する必要があります。 以下の点をご確認ください。 1. フラッシュハードウェアのピンが正しく設定されているか確認してください。FlexSPIピンはRT1050ハードウェア開発マニュアルに従って設定する必要があります。 グループAまたはグループBのいずれか一方のみを選択でき、FlexSPI_DQSは選択解除せずにそのままにしておく必要があります。 2. evkbimxrt1050_flexspi_nor_polling_transfer サンプルを SDK にインポートし、フラッシュデータシートに従ってフラッシュ構成を変更します。(この手順は省略可能です。フラッシュ構成が正しいことを確認するためだけのものです。) 3. iMXRT1050_QSPIプロジェクトで、正しいフラッシュ構成に変更します。この手順については、以下を参照してください。 https://www.nxp.com/docs/en/application-note/AN13386.pdf よろしくお願いします、 シェリー・チャン
View full article
PTE4ABTE-32GX eMMC 我们计划将 PHISON 的这款 eMMC PTE4ABTE-32GX与 IMX8M 处理器一起使用。请确认这是否支持启动。附上数据手册供参考。 Re: PTE4ABTE-32GX eMMC 是的,根据数据手册,只要按照 i.MX8M 硬件设计指南连接到 USDHC 接口,PHISON PTE4ABTE-32GX 就应该支持在 i.MX8M 系列(i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP)上启动。 Re: PTE4ABTE-32GX eMMC @yipingwang谢谢你的回复。 我们使用的是 MIMX8ML5CVNKZAB ,它是一款 i.MX8ML 设备。而您的回复中只 提到了 i.MX8M 系列(i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP) 。 请问 根据硬件设计指南,当 PHISON PTE4ABTE-32GX 连接到 USDHC 接口时, 是否 也支持使用 i.MX8ML 设备启动? Re: PTE4ABTE-32GX eMMC 是的,i.MX8ML (MIMX8ML5CVNKZAB) 支持从通过 USDHC 接口连接的 eMMC 设备启动。PHISON PTE4ABTE-32GX 是一款 eMMC 5.1 设备,按照 i.MX8M 硬件设计指南进行连接和配置后,预计可与 i.MX8ML 启动流程兼容。
View full article
RD33772C14VEVM RESET 指示灯反复闪烁且 TRACE32 连接失败 你好, 我的名字是张慧云(Hye-Woon Jang),我目前正在使用RD33772C14VEVM开发板。 购买板后,我将其连接到直流电源,如图所示。由于我目前没有合适的 12V 电池,所以我改用电源适配器提供 12V 电压。 连接方式如下: 12V+:VBAT+,K30_12V_L 12V - : VBAT-, GND_KL31_DOWN 我联系您是因为,即使只连接电源,红色 RESET LED 也会亮起,并以大约 0.5 到 1 秒的间隔持续闪烁,如附图所示。 我是否应该将这种现象理解为电路板反复RESET? 我这样问是因为 LED 的亮度似乎与我手动按下 RESET 按钮时的亮度不同。 我想使用 TRACE32 运行一个模型。但是,当电路板连接到 TRACE32 时,TRACE32 中的 RESET 指示与电路板上的 RESET LED 同时闪烁,因此 TRACE32 似乎无法与目标建立连接。 如果您能确认这种 RESET LED 指示灯亮起的情况是否正常,并告知我如何解决这个问题,我将不胜感激。谢谢你的帮助。 此致, 张慧云 #rd33772c14vevm #s32k344 #JTAG #MBDT #RESET #T32 #TRACE32 Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure 请问如何才能阻止这种反复重置的行为?谢谢。 Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure 当我购买 RD33772C14VEVM 板时,随附的 J5 电缆组件在电缆末端包含一个标有“PWA, X-14VBMS-EMU (700-50656)”的板。 我的理解是,当提供 12V 电压时,该板可以模拟电池的电压和温度,具体功能如下: *12V + 至 K30_12V_L *12V - 至 GND_K31_DOWN 能否使用这款模拟器板来代替将至少三个实际电池单元连接到 MC33772C? Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure 张你好 请参阅MC33772C 数据手册中的 13.2.2 节。至少需要 3 个细胞填充 MC33772C。 建议RD33772C14VEVM使用4个电池。然后,细胞必须提供 MC33772C。如果未安装元件,仅通过外部电源为 MC33772C 供电将无法工作。 另请参阅附件 AN12536。 最诚挚的问候, 约瑟夫 Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure 这样理解是否正确? 12V 电源(-) → B− → 分流 → VBAT− → X-14VBMS-EMU GND_KL31_DOWN Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure 张你好 谢谢你指出X-14VBMS-EMU,我现在明白了。我发现连接可能存在问题。请将 X-14VBMS-EMU 的负极连接到分流电阻的另一个引脚,这样电流就会流过分流电阻,并被 ISENSE 引脚感知到。请参考附件中的RD33772C14VEVM原理图。 请检查 J1 连接器是否已连接,以便将 FS26 设置为 DEBUG 模式。 请按照电源接通顺序操作。首先请将 12V 连接到 B+ 和 B-。 然后将连接器连接到 J6。 将电池模拟电缆连接到 J5,并将电源(+12V 连接到 BAT+ (K30),分流电阻的负极连接到 BAT- (K31))。 最诚挚的问候, 约瑟夫 Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure 张你好 这样理解是否正确? 12V 电源(-) → B− → 分流 → VBAT− → X-14VBMS-EMU GND_KL31_DOWN [A] 是的,RD33772C14VEVM 板原理图中就是这样描述的。 最诚挚的问候, 约瑟夫 Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure 你好 JozefKozon, 感谢您的反馈, 根据你的解释和 RD33772C14VEVM 板原理图,我按如下方式连接:12V 电源 -> 分流器 -> EMU。但是,重置行为仍然相同。 请您回答以下问题? 我已将直流电源设置为 12V 1.5A 并开始供电。但是,我确认实际流入电路板的电流为 12V 0.04A。这会不会有问题? 如果问题 1 中的问题确实存在,我应该怎么做才能使 1.5 A 的电流流入板? 正如您所解释的,我配置了设置,使电源的导线经过分流电阻器,然后连接到 EMU。请您确认一下,附图所示的设置是否正确? 当 TRACE32 连接时,似乎每 0.5 秒就会发生一次 RESET,由于这种现象,我无法将 TRACE32 连接到电路板上。有什么方法可以确认主板是否真的在执行重置操作?当我测量 JTAG 引脚 10 和 GND 之间的电压时,电压为 4.9 V。但是,由于我没有示波器,因此通过 JTAG 引脚确认复位行为存在局限性。 如果有什么方法可以阻止这种重置行为,即使可能不太方便,也请您详细解释一下。 由于我们尚未能获得 12V 电池,因此我们在进行测试时,VBAT 端子保持未连接状态。当向 B+ 和 B− 供电 12 V 时,我们确认 VBAT 端子处有 12 V 电压。VBAT未连接是否会导致此问题? 期待您的回复。 谢谢!
View full article
KinetisのMCUを使っている方はいらっしゃいますか? 現在、USB搭載のMCUをいくつか評価していて、Kinetisシリーズの機能セットが目に留まりました。いくつかサンプル(メインのものはK22FN1M0VLH12にしたいと思っています)、ヘッダー付きのブレイクアウトに置き、EzPortやSPIを使ってコードをブートストラップする方法も考え出しましたが、今は本格的なファームウェア開発を始める段階に来ています。ソフトウェア開発は経験がありますが、組み込みプラットフォームの仕事はあまりありません。Freescaleがここ数ヶ月リリースした新しいEclipseベースのツールチェーンとProcessor Expertの見た目が気に入っています。なぜなら、ペリフェラルの初期化を多く処理してくれるからです。しかし、その方法やGCCベースのツールチェーンでKinetisを使うことについての情報が本当に不足しているのを見かけます。出回っている情報(ごくわずかだが)は、FRDMボードに関するものに限られているようで、それらは安価ではあるものの、同社の製品ラインナップのごく一部に限定されている。 最近Kinetisで何か仕事をした方はいらっしゃいますか?もしそうなら、どのツールチェーンを使いましたか? 他のベンダーの類似ARMチップと比べて、Kinetisのデバイスやドキュメント、ツールについての一般的な印象はどうですか? もしK20 FRDMボードを手に入れた場合、得られた知識は実際のアプリケーションで使いたいK22Fチップに比較的ポータブルになると思いますか?K22F FRDMボードもあるが、価格は2倍で、その差額はSTM32開発ボードを購入して比較評価するのにちょうど足りる金額だ。 また、一般的に、開発用ボードからカスタムボードにコードを移植するのはどれくらい簡単なのでしょうか?開発ボードからカスタム回路への移行におけるあなたのアプローチは何ですか? 質問が多くて申し訳ありませんが、皆さんの知恵を拝借できればと思っています。 Re: Anybody using Kinetis MCUs? こんにちは、 @lukutu さん、 投稿ありがとうございます。 実は、あなたが言及したEclipseベースのツールチェーンについてですが、おそらくKinetis Design Studio(KDS)やProcessor Expertのことを指しているのだと思います。これらのツールは現在レガシー製品であり、現在は積極的にサポートされていません。 Kinetis Design Studioの後継として、NXPは MCUXpresso IDEを導入しました。KDSと同様に、MCUXpresso IDEもEclipseベースで、GNUツールチェーン、SDKサンプルインポート、ピン/クロック/周辺機器設定ツール、フラッシュプログラミング機能、シームレスなSDK統合を統合し、よりモダンで完全にサポートされた開発環境を提供します。 MCUXPresso SDKはこちらからダウンロードできます:MCUXpresso SDK Builder 設定ツールの使い方については、MCUXpresso IDEのMCUXpresso Config Toolを参照してください。   ハードウェアの選定に関しては、 FRDM-K22Fボードを検討することをお勧めします。K20 FRDMプラットフォームとは大きく異なり、さらに追加の利点があります。 購入後、注文確認メールに返信して無料のFRDM-MCXE31B、FRDM-MCXN236、FRDM-MCXA153、またはFRDM-MCXA156クーポンを申請し、MCXマイクロコントローラを評価することができます。 MCXファミリーはNXPの最新のMCUポートフォリオであり、新しいデザインに対してより長い製品ライフサイクルを提供します。USBを含む FRDM-MCXA156を検討してみると良いでしょう。将来の開発や評価に良い選択肢になるかもしれません。 開発ボードからカスタムボードへのコード移植については、MCUXPressoを使えば簡単に実現できます。以下の記事をご参照ください。 実践形式ワークショップ:デバイス用のカスタムボードSDK作成 カスタムボードMCUXpresso SDKの作成方法 他に質問がありましたら、お気軽にお知らせください。喜んでお手伝いします。 BR セレステ
View full article
GuiGuiDer2.0.0を使用してターゲットデバイスを構築中にエラーが発生しました。 バージョン2.0.0を使用し、ARMを選択してfrdm_mcx947をベースにしたguiguiderプロジェクトを作成しました。GCCのバージョンは14.4.1です。 既にarm gccツールを設定済みです。 コンパイル中に次のエラーメッセージが発生しました: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe 11:41:00INFObuild-target Started11:41:00INFOTarget Executor initialized11:41:00INFOBuilding target with armgcc toolchain...11:41:00INFOStarting ARM GCC build...11:41:00INFOSearching for ARM GCC toolchain in system PATH...11:41:00INFOExecuting: where arm-none-eabi-gcc11:41:00INFO'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ���11:41:00ERRORARM GCC not found in system PATH: Command failed with code 1: 'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ��� 11:41:00ERRORARM GCC build error: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERRORBuild failed: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERROROperation failed: ARM GCC toolchain not found. Please install it and add to system PATH. cmdを使ってコンパイラツールを見つけることに成功しました。 C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe
View full article
TPL+33664+33774 I have been working on a BMS project recently and encountered the following issues.   The publicly available MC33664 datasheet downloaded from NXP’s official website does not contain any register descriptions for the MC33664 transceiver. In addition, the official demo code package I downloaded also lacks any routines for accessing and operating MC33664 internal registers. Does TPL3 communication require read/write access to MC33664’s registers?   If register operations are mandatory, could anyone share a complete MC33664 datasheet with full register specifications, as well as a sample demo project that implements MC33664 register read/write logic? Many thanks! Re: TPL+33664+33774 Hi, The datasheet you have downloaded is already the complete, full document. The MC33664 does not contain any internal registers and therefore does not require register read/write operations for TPL communication. The device acts as a transparent TPL physical-layer transceiver. It converts the MCU SPI transmit stream into TPL pulse-encoded signals and converts received TPL traffic back into SPI signals. As a result, communication with devices on the TPL network is performed by sending and receiving TPL frames through the SPI interface. You may be referring to the newer MC33665A gateway device, which does include internal registers, message queues, routing functions and a register-access protocol. The MC33665A full datasheet (available as a Secure file under NDA) therefore contains extensive register descriptions. We have SW device drivers available for both the MC33664 and MC33665 as part of the Gen1 SDK. As for the MC33664, the CDD layer on the MCU handles tasks such as pin timing to execute a wake-up sequence, configuring and managing two independent SPI blocks on the MCU simultaneously, interrupt routing etc. BRs, Tomas
View full article
无法为 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 的一个限制或错误吗? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 与AE团队讨论。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Ara240 的端到端性能是否已经过评估?数据手册中提到了两个矢量核心,可以执行诸如 sigmoid 和 NMS 之类的后处理操作。编译器能否将 NMS 操作映射到向量核心? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 抱歉耽搁了。我正在尝试重现转换工作流程。 现在有一个问题,为什么转换后的模型的数据类型是 FLOAT32?你试过转换成 INT8 类型吗?Neutron NPU 需要 INT8 类型作为输入数据。我在其他模型转换中也遇到过类似的错误,根本原因是数据类型错误。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 由于对 YOLOv8 的输出张量应用了完全 INT8 量化( inference_output_type=tf.int8 )这一根本限制,置信度输出丢失了。 YOLOv8 将边界框坐标和置信度分数打包成形状为 (1, 5, 8400) 的单个输出张量。bbox 值具有较大的动态范围(~640 像素),而置信度得分在 ~0 到 1 的范围内。当整个输出张量共享一个量化尺度时,该尺度主要由较大的边界框值(~640)构成,只剩下一个整数级别的一小部分来表示整个置信范围(~1)。因此,经过 INT8 量化后,所有置信值实际上都被四舍五入为零。 推荐解决方案 而不是通过  onnx2quant ,直接从您训练好的数据中导出 INT8 TFLite。  .pt  使用 Ultralytics 建模,然后将其输入到  neutron-变流器 : # 直接导出 INT8 TFLite 数据(校准使用您的训练数据集) yolo export model=best.pt \ format=liter \ imgsz=640 \ 量化=8 data=dataset.yaml 分数=0.1 #为Neutron 编译(未更改) neutron-变流器 --target imx95 --input best_int8.tflite --output best_neutron.tflite 请确保输入和输出数据类型为 np.int8: interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors()inp_d = interp.get_input_details()[0]out_ds = interp.get_output_details()inp_scale, inp_zp = inp_d[ "量化" ] out_d = out_ds[0] out_scale, out_zp = out_d[ "量化" ] print(f " 输入数据类型={inp_d['dtype']} 形状={inp_d['shape'].tolist()}" f " quant=(scale={inp_scale:.6f}, zp={inp_zp})" ) print(f " 输出 dtype={out_d['dtype']} shape={out_d['shape'].tolist()}" f " quant=(scale={out_scale:.6f}, zp={out_zp})" )# 根据形状确定输入格式 in_shape = inp_d[ "shape" ].tolist()# [1,3,640,640] 或 [1,640,640,3] 如果in_shape[1] == 3: # NCHW src=img_nchw 别的: # NHWC src=img_nhwcif inp_d[ "dtype" ] == np.int8: src_int8 = np.clip(np.round(src/ inp_scale + inp_zp), -128, 127).astype(np.int8) interp.set_tensor(inp_d[ “索引” ],src_int8) 别的: interp.set_tensor(inp_d[ “索引” ],src.astype(np.float32))interp.invoke()raw_out = interp.get_tensor(out_d[ "index" ])# 如果 out_d[ "dtype" ] == np.int8,则可能是 int8 或 float32: dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale 别的: dq_out = raw_out.astype(np.float32)dq_out= dq_out[0] # (5, 8400) 归一化 # 将边界框重新缩放回像素坐标以便显示 BBOX_SCALE = 640.0tfl_bbox = dq_out[:4] * BBOX_SCALE # (4, 8400) tfl_conf = dq_out[4] # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 您好,我尝试了您分享的命令…… 但是中子变流器无法转换模型…… 请查收附件日志,供您参考,引用。
View full article
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? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Discussing with the AE team. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Has end-to-end been evaluated for the Ara240? The datasheet mentions two vector cores that can execute post-processing ops such as sigmoid and NMS. Could the compiler map NMS ops to the vector cores? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Sorry for the delay. I am trying to reproduce the conversion workflow.  One question for now, why the converted model's data type is FLOAT32? Have you tried to convert to INT8? The Neutron NPU requires the INT8 type as input data. I met the similar error on other models conversion and the root cause is the data type. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU The confidence output is lost due to a fundamental limitation of full INT8 quantization ( inference_output_type=tf.int8 ) applied to YOLOv8's output tensor. YOLOv8 packs bounding box coordinates and confidence scores into a single output tensor of shape  (1, 5, 8400) . The bbox values have a large dynamic range (~640 pixels), while the confidence scores are in the range of ~0 to 1. When the entire output tensor shares a single quantization scale, that scale is dominated by the large bbox values (~640), leaving only a fraction of one integer level to represent the entire confidence range (~1). As a result, all confidence values are effectively rounded to zero after INT8 quantization. Recommended Solution Instead of going through  onnx2quant , export INT8 TFLite directly from your trained  .pt  model using Ultralytics, then feed it into  neutron-converter : # Export INT8 TFLite directly (calibration uses your training dataset) yolo export model=best.pt \ format=litert \ imgsz=640 \ quantize=8 \ data=dataset.yaml \ fraction=0.1 # Compile for Neutron (unchanged) neutron-converter --target imx95 --input best_int8.tflite --output best_neutron.tflite For the input and output data type, please ensure they are np.int8: interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors() inp_d  = interp.get_input_details()[0] out_ds = interp.get_output_details() inp_scale, inp_zp = inp_d["quantization"] out_d = out_ds[0] out_scale, out_zp = out_d["quantization"] print(f"  Input  dtype={inp_d['dtype']}  shape={inp_d['shape'].tolist()}"       f"  quant=(scale={inp_scale:.6f}, zp={inp_zp})") print(f"  Output dtype={out_d['dtype']}  shape={out_d['shape'].tolist()}"       f"  quant=(scale={out_scale:.6f}, zp={out_zp})")# Determine input format from shape in_shape = inp_d["shape"].tolist()   # [1,3,640,640] or [1,640,640,3] if in_shape[1] == 3:     # NCHW     src=img_nchw else:     # NHWC     src=img_nhwcif inp_d["dtype"] == np.int8:     src_int8 = np.clip(np.round(src / inp_scale + inp_zp), -128, 127).astype(np.int8)     interp.set_tensor(inp_d["index"], src_int8) else:     interp.set_tensor(inp_d["index"], src.astype(np.float32))interp.invoke() raw_out = interp.get_tensor(out_d["index"])  # may be int8 or float32if out_d["dtype"] == np.int8:     dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale else:     dq_out = raw_out.astype(np.float32)dq_out = dq_out[0]   # (5, 8400) normalized# Rescale bbox back to pixel coords for display BBOX_SCALE = 640.0 tfl_bbox = dq_out[:4] * BBOX_SCALE   # (4, 8400) tfl_conf = dq_out[4]                  # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi Tried the commands you shared... But neutron-converter is failing to convert the model... please find the log attached for your reference
View full article
An error occurred while building the target device using GuiGuiDer2.0.0. I have now created a guiguider project based on frdm_mcx947, using version 2.0.0, and selected ARM. The GCC version is 14.4.1. I have already configured the arm gcc tool. The following error message occurred during compilation: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe 11:41:00INFObuild-target Started11:41:00INFOTarget Executor initialized11:41:00INFOBuilding target with armgcc toolchain...11:41:00INFOStarting ARM GCC build...11:41:00INFOSearching for ARM GCC toolchain in system PATH...11:41:00INFOExecuting: where arm-none-eabi-gcc11:41:00INFO'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ���11:41:00ERRORARM GCC not found in system PATH: Command failed with code 1: 'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ��� 11:41:00ERRORARM GCC build error: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERRORBuild failed: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERROROperation failed: ARM GCC toolchain not found. Please install it and add to system PATH. I was successful in finding the compiler tools using cmd: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe
View full article
GuiGuiDer2.0.0是否只支持LVGL9.4了? GuiGuiDer2.0.0是否只支持LVGL9.4了? 没有V8.3.11或者V8.4的支持了吗 回复: GuiGuiDer2.0.0是否只支持LVGL9.4了? 你好@wqy1103 是的,GUI Guider2.0.0 是为与 LVGL 9.4.0 一起使用而设计的。 BR 哈里
View full article
TPL+33664+33774 最近、BMSプロジェクトに取り組んでいて、以下の問題に遭遇しました。   NXPの公式ウェブサイトからダウンロードされた公開MC33664データシートには、MC33664トランシーバのレジスタ説明は含まれていません。さらに、私がダウンロードした公式デモコードパッケージには、内部レジスタへのアクセスや操作MC33664ルーチンが一切含まれていません。 TPL3の通信にはMC33664のレジスタへの読み書きアクセスが必要ですか?   レジスタ操作が必須なら、完全なMC33664データシートと、レジスタ読み書きロジックを実装したサンプルデモプロジェクトMC33664誰か共有できますか?どうもありがとうございました! Re: TPL+33664+33774 こんにちは、 ダウンロードされたデータシートは、既に完全な文書です。MC33664には内部レジスタが含まれていないため、TPL通信においてレジスタの読み書き操作は必要ありません。 このデバイスは透過的なTPL物理層トランシーバとして機能します。MCU SPIの送信ストリームをTPLパルス符号化信号に変換し、受信したTPLトラフィックを再びSPI信号に変換します。その結果、TPLネットワーク上のデバイスとの通信は、TPIインターフェースを通じてTPLフレームの送受信によって行われます。 あなたが言及しているのは、内部レジスタ、メッセージキュー、ルーティング機能、レジスタアクセスプロトコルを含む新しいMC33665Aゲートウェイデバイスのことかもしれません。そのため、MC33665Aの完全なデータシート(NDAに基づきセキュアファイルとして入手可能)には、詳細なレジスタの説明が含まれています。 Gen1 SDKの一部として、MC33664とMC33665の両方にSWデバイスドライバーを提供しています。MC33664については、MCUのCDD層が、ウェイクアップシーケンスを実行するピンタイミング、MCU上の2つの独立したSPIブロックを同時に設定・管理、割り込みルーティングなどのタスクを処理します。 BRs、トーマス
View full article
Does GuiGuiDer 2.0.0 only support LVGL 9.4? Does GuiGuiDer 2.0.0 only support LVGL 9.4? Is there no support for V8.3.11 or V8.4? 回复: GuiGuiDer2.0.0是否只支持LVGL9.4了? Hi @wqy1103  Yes, GUI Guider2.0.0 is designed for use with LVGL 9.4.0. BR Harry
View full article