Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
Request for Assistance: S32 Design Studio for ARM License Renewal Error Dear NXP Support Team, Hello, I am writing to request support regarding an error encountered while trying to renew the license for S32 Design Studio for S32. Below are the details of my license and the error message received: < License Information > ssean_0-1784761042324.png < Error Message > ssean_1-1784761084965.png ssean_2-1784761092125.png Could you please advise on how to resolve this issue and successfully extend/renew the license? Thank you for your time and assistance. Best regards, Suhyun Sung Re: Request for Assistance: S32 Design Studio for ARM License Renewal Error Hi,  please try the activation again. I returned old licenses.  Re: Request for Assistance: S32 Design Studio for ARM License Renewal Error @jiri_kral  The license is now active and working fine. Thanks for your help! BRs, Sean Sung
View full article
S32K312 セキュアブートとフラッシュメモリのプログラム 添付されたCMMファイルは、FBLとアプリをS32K312 MCUに書き込み、その後SecureBoot、SecureDebug、Configuration Lockを起動するスクリプトです。 このCMMの実行時に発生するHardFaultの問題について、見直しと改善をお願いしたいと思います。 以前のスクリーンショットに示すように、JTAGクロックを5MHzに設定した状態で「Go」を実行した際に、FBLとアプリをインポートした後にハードフォルトが発生しました。 変更点として、アプリファイルをインポートした後、SYStem.JtagClockを1MHzに設定しました。この変更により、CMM実行時に「Go」ステップでハードフォールトが発生することは稀になったため、JTAGクロック速度を下げることが効果的な方法であると結論づけました。しかし、修正されたCMMを適用すると、FBLとアプリがインポートされた後、「Go」の段階で「stopped by vectbl」エラーが時折発生します。 CMM全体が安定して動作できるように見直し、また「vectblによって停止」エラーが全く出ないよう改善方法についてご質問いただきたいと思います。 オリジナルCMM:GN7_PE_MAIN_G_SECURE_260412.cmm 変更されたCMM(JTAGクロックを1MHzに変更):GN7_PE_MAIN_G_SECURE_260412_0714RE.cmm さらに、SecureBootを有効にした後で、別のFBLをインポートしたいと考えています。SecureBootが有効になっている状態で、別のFBLをインポートする方法はありますか?可能であれば、ガイドをご提供していただけるとありがたいです。 Re: S32K312 Secureboot and Program Flash こんにちは、 @jeongwoo 私が思う主な問題はこうです: lukaszadrapa_0-1784181532767.png つまり、ピンク色のファイルをロードして、デバイスをリセットするということです。このリセット後、SBAFはHSEファームウェアをインストールするはずです。しかし重要な点は、この操作は約1秒で完了するということです。しかし、0.1秒後にMCUをリセットすると、すぐにfblでピンクファイルを0x40_0000で再プログラムします。待ち時間を少なくとも1.3秒に増やしてください。そうしないと、SBAFがHSE FWをインストールしようとし、同時にfblの再プログラミングも試みることになります。 よろしくお願いいたします。 ルーカス Re: S32K312 Secureboot and Program Flash こんにちは、ご返信ありがとうございます。 HSEを追加してから遅延時間が0.1秒に設定されている部分については、時間が短く設定されてもコントローラに書き込まれるプログラム機能に問題はありません。遅延時間を1秒に延長することが本当に必要なのかどうかをお伺いしたいです。 Re: S32K312 Secureboot and Program Flash HSEファームウェアがまだインストールされていないデバイスでテストしましたか?これはうまくいかないと思います。インストールには1秒強しかかかりません。0.1秒後にリセットしてインストールをカットし、その直後にピンクファイルを消去すると、SBAFはファームウェアをインストールできません。 Re: S32K312 Secureboot and Program Flash こんにちは、 まず、既存の0.1秒設定でCMMを構成して書き込みを行った場合、Trace32にハードフォルトが発生するものの、ファームウェアの機能には影響がないことを確認しました。FBLとAPPは正常に実行されたようです。 SBAFやHSEが正常に動作しているかを確認するために使えるレジスタアドレス値はありますか? さらに、あなたが言及したHSE申請期間を考慮したCMMについてですが、「vectblで停止」は実行時に表示されませんでした。しかし、APP Import 中に FLASH.ReProgram ALL の後に「wait 3s」を「wait 2s」に変更しても、「stopped by vectbl」がまだ表示されることを確認しました。APPインポートの時間を短縮することも影響を与えるでしょうか? jeongwoo_0-1784707488443.png Re: S32K312 Secureboot and Program Flash こんにちは、 @jeongwoo スクリプトに潜在的な問題点を見つけたかもしれません。 lukaszadrapa_0-1784819781177.png fbl_m4をロードした後、Goコマンドを使用してブートローダーを起動します。スクリプトはその後ループに入り、定期的にブート構成ワードを読み取り、値0x9を待ちます。これは、スクリプトがブートローダーがセキュアブートを初期化し、ブート構成ワードのBOOT_SEQビットを更新するのを待っていることを意味します。しかし、この更新を実行するにはブートローダーがフラッシュセクター全体を消去・再プログラムする必要があり、かなりの時間がかかることがあります。 その期間中、デバッガは同じフラッシュメモリの位置を繰り返し読み取ります。これは、読み取り同時書き込みの競合を引き起こす可能性があります。フラッシュブロックが消去またはプログラムされている間は、通常同時に読み取ることはできません。その結果、デバッガはアクセスエラーに遭遇し、観察された挙動の説明がつくかもしれません。 よりスマートな解決策としては、フラッシュメモリに保存された値をポーリングする代わりに、RAMに格納されたステータス変数を使用することです。ブートローダーがすべてのセキュアブート設定ステップを完了したら、専用のRAM変数を更新できます。デバッガは定期的にこのRAM位置を読み取ることができました。RAMアクセスはフラッシュ消去やプログラム操作に干渉しないため、この方法は書き込み時の読み込み問題を回避します。 また、同じ方法がスクリプト全体で何度も使われているのに気づいたので、この特定のものだけでなく、すべての類似したステータスチェックを見直して更新することをおすすめします。 HSE(環境・安全・衛生)の状況に関して: HSEファームウェアがインストールされているかどうかを確認するには、アドレス0x4039C028にあるHSE GPRレジスタのビット0を確認してください。このビットが1の場合、HSEファームウェアが存在します。 HSEファームウェアの初期化が完了し、要求を受け付ける準備が整っているかどうかを確認するには、MU0 FSRレジスタのHSE_STATUS_INIT_OKフラグ(ビット24)を確認します。このビットが設定されると、HSEの初期化が完了し、サービスが利用可能になります。 Re: S32K312 Secureboot and Program Flash こんにちは、ルーカスさん。 ご返信よろしくお願いします。 私の理解では、ブートローダーが初期値(0x1)で一度アップロードされた後、再度消去・書き込みサイクルを行い、セキュアブート(0x1 → 0x9の変更)を適用します。この過程でポーリングメソッドがそのアドレス値を読み取ろうとした際にエラーが発生したようです。 jeongwoo_0-1784877741730.png ご指摘いただいたとおり、RAMに格納されているステータス変数を使用してみました。ただし、私たちはソフトウェアを16進形ファイルとして配布しています。この場合、.mapで定義されたアドレスを使うとファイル、RAMアドレスはプログラムごとに異なるため、書き込みスクリプトを統一することが困難です。その結果、スクリプト内でセキュアブート、セキュアデバッグ、および構成ロックの状態を確認するには、IVTで定義されている値を使用する必要があるという結論に至りました。 したがって、ご意見をもとに、HSEアップロード後に1.5秒の遅延を適用する代わりに、MU0 FSRレジスタのHSE_STATUS_INIT_OKフラグ(ビット24)をチェックする方法を適用しました。既存の固定待ち時間(例:1.5秒待機、3秒待機)を廃止し、リセット後はフラッシュ書き込み(FBL/APP読み込み)を進めるまでポーリングを行うスクリプトを修正しました。この方法はシステムリセットとSys.UPの後のすべての段階に追加しました。さらに、各ステータスの状態確認のためのポーリング間隔を0.5秒から1.5秒に変更する予定です。また、Go命令後の最初の読み取りの前に待機時間を追加しました。これらのタイミング設定が不十分かどうかについて、ご意見をいただければ幸いです。これまでのところ、このスクリプトでの書き込みは異常なく正常に完了し、書き込み後にGOを実行するとデバイスが正しく動作していることを確認しています。 (アドレス0x400004の値が0x1から0x9に変化するのにかかる時間は約800msであることを確認しました。) 以前ご指摘いただいた、HSEのアップロードから0.1秒後にFBLをロードした際にハードフォルトが発生した件について:ご指摘いただいたHSEステータス値を確認したところ、すべて正常と報告されていることを確認いたしました。プログラムの機能も正しく実行されているようです。このエラー(HardFault)は、HSE → FBL → APP を経由してすべてをロードし、GO を実行したときに発生します。この状況を踏まえ、ご提案の通り、GOを執筆後に実行するために遅延時間を延ばすのが望ましいかどうか、ご意見をいただけるとありがたいです。 よろしくお願いいたします。 Re: S32K312 Secureboot and Program Flash はい、sys.up の実行後、他のプログラミング操作を開始する前に HSE_STATUS_INIT_OK を待つのは良い方法です。これにより、HSEとアプリケーションコア/プログラミングツール間で読み書きの競合がなくなります。 BOOT_SEQビットのチェックに使われるタイムアウトがプログラミング操作がすでに完了しているのに十分な長さであれば、この方法も有効です。しかし、RAMにフラグを使用する方がより簡潔な解決策となるだろう。 万能的な解決策が必要な場合、共通セクションに標準的なグローバル変数を配置するのは理想的ではありません。なぜなら、そのアドレスが異なるアプリケーション間で一定であることが保証されていないからです。代わりに、固定アドレスに専用RAMセクションを定義し、そこにフラグを配置するか、未使用のRAMを固定アドレスに予約してポインタから直接アクセスする方法があります。 どちらのアプローチも、アプリケーションのメモリレイアウトとは独立して共有可能な安定した場所を提供します。 よろしくお願いいたします。 ルーカス Re: S32K312 Secureboot and Program Flash こんにちは、ルーカス。 以前ご提供いただいたガイダンスに従って、イメージファイル(.elf)はvectblによって停止されることなく正常に実行されるようになりました(「実行中」)。しかし、アプリをアップロードした後、GOを実行すると、バイナリファイル(.hex)で依然として「stopped by vectbl」エラーが発生します。 これは、「アプリが実行フロー内で無効なアドレスにジャンプし、その場所にある命令を取得しようとした際に失敗する」という症状のようです。この問題を解決する方法はありますか? vectblエラーが発生しても、通常の書き込みはPOR(Power-On Reset)時に元々意図した通り正しく完了しているように見えますが、このエラーが安全に無視できるものかどうか確認する必要があります。 引き続きご支援いただきありがとうございます。 よろしくお願いいたします。 jeongwoo_0-1785298132030.png
View full article
How do you optimize IPTV playback performance on i.MX8 Android devices? Hello everyone, I'm currently evaluating IPTV playback on Android devices based on the i.MX8 platform and would like to learn from the community's experience. During testing, I noticed that playback quality can vary depending on several factors, including: Hardware video decoding configuration Network stability (Ethernet vs. Wi-Fi) Buffer size for live HLS streams ExoPlayer or VLC configuration CPU and memory usage during playback For those working with i.MX processors, what settings or optimizations have produced the most stable results for live TV streaming? Specifically, I'm interested in: Recommended ExoPlayer buffer settings Hardware decoder best practices Tips for reducing buffering during live events Performance tuning for Android TV devices Network troubleshooting methods I'd appreciate hearing about your real-world experience and any recommendations that have improved playback stability. Thank you! Re: How do you optimize IPTV playback performance on i.MX8 Android devices? Hi, The NXP BSP does not provide any officially recommended IPTV parameters. NXP's Android releases include integrated multimedia frameworks, codecs, and platform optimizations for i.MX processors. Please use a recent BSP version is generally recommended when evaluating multimedia performance. Best Regards, Zhiming
View full article
请求协助:S32 Design Studio for ARM 许可证续订错误 尊敬的恩智浦技术支持团队: 你好, 我写信请求支持,因为我在尝试续订 S32 Design Studio for S32 的许可证时遇到了错误。 以下是我的驾照详情和收到的错误信息: < License Information > ssean_0-1784761042324.png < Error Message > ssean_1-1784761084965.png ssean_2-1784761092125.png 请问如何解决此问题并成功延长/续订许可证? 感谢您抽出时间提供帮助。 顺祝商祺! 成秀贤 Re: Request for Assistance: S32 Design Studio for ARM License Renewal Error @jiri_kral 许可证现已激活并运行正常。 感谢您的帮助! BRs, 宋 Re: Request for Assistance: S32 Design Studio for ARM License Renewal Error 你好, 请再次尝试激活。我归还了旧的驾照。
View full article
imx93 无法加载 mcimx93evk_ethosu_apps.elf,如果 mcimx93evk_ethosu_apps.elf 需要 OCRAM。 我正在尝试示例代码。 mcimx93evk_ethosu_apps。在这种情况下,elf 需要使用 OCRAM(某些变量太大)。 在精灵建造完成后。我将这个 elf 文件加载到 m33 中。 它总是失败: remoteproc remoteproc0:已注册的例外情况不符合请求要求 remoteproc remoteproc0:错误的 phdr da 0x20480000 mem 0x60000 remoteproc remoteproc0:加载程序段失败:-22 远程进程 remoteproc0:启动失败:-22 可能是由于冲突导致内存分配失败。 为什么? 示例代码如下: 来自 sdk_examples 的 mcimx93evk_ethosu_apps。请您查看一下这个示例好吗? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. NXP 网站上的 SDK 版本为: 2.14.xx 有人成功将 mcimx93evk_ethosu_apps 加载到 m33 吗? 如何在m33中成功运行mcimx93evk_ethosu_apps? 谢谢。 Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. 我没有修改ld。 m_ocram(RW):ORIGIN = 0x20480000,LENGTH = 0x00060000 __attribute__ ((section(".bss.tensor_arena_ocram"),aligned(32))) uint8_t inferenceProcessTensorArena[TENSOR_ARENA_SIZE]; 将 elf 文件加载到 m33 后的结果: remoteproc remoteproc0:错误的 phdr da 0x20480000 mem 0x60000 Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. Hi, 这个app仅适合在Uboot中加载。对于remoteproc,drivers/remoteproc/imx_rproc.c中并未定义OCRAM的memory属性。 Zhiming_Liu_0-1785301592854.png Best Regards, Zhiming
View full article
mcimx93evk_ethosu_apps.elf に OCRAM が必要な場合、imx93 は mcimx93evk_ethosu_apps.elf の読み込みに失敗しました。 サンプルコードを試しています。 mcimx93evk_ethosu_apps。 この場合、エルフはOCRAMを使う必要があります(変数が大きすぎると言われます)。 エルフが完成した後。私はこのelfファイルをm33にロードします。 それは常に失敗した: remoteproc remoteproc0: 登録されたカーブアウトが要求に適合しません remoteproc remoteproc0: 不良なphdr da 0x20480000 mem 0x60000 remoteproc remoteproc0: プログラムセグメントの読み込みに失敗しました: -22 remoteproc remoteproc0: ブート失敗: -22 メモリ割り当てが競合により失敗した可能性があります。 なぜ? このサンプルコードは次のとおりです。 sdk_examples の mcimx93evk_ethosu_apps。このサンプルを確認していただけますか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. NXPサイトからのSDKバージョンは以下の通りです: 2.14.xx M33にmcimx93evk_ethosu_appsをロードできた人はいますか? M33でmcimx93evk_ethosu_appsをうまく動かすにはどうすればいいですか? ありがとうございます。 Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. 私はldを修正しませんでした m_ocram (RW) : ORIGIN = 0x20480000、LENGTH = 0x00060000 __attribute__ ((section(".bss.tensor_arena_ocram")、aligned(32))) uint8_t inferenceProcessTensorArena[TENSOR_ARENA_SIZE]; elfをm33にロードした結果: remoteproc remoteproc0: 不良なphdr da 0x20480000 mem 0x60000 Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. こんにちは、 このアプリはU-Bootでのロードにのみ適しています。remoteprocの場合、OCRAMメモリ属性はdrivers/remoteproc/imx_rproc.cで定義されていません。 Zhiming_Liu_0-1785301592854.png よろしくお願いします、 志明
View full article
The S32DS software has expired. I would like to inquire: The license for the S32DS software is about to expire. How can I renew it? Re: The S32DS software has expired. Hello, It is now extended. Best regards, Peter
View full article
S32DS软件已过期。 我想咨询一下:S32DS软件的许可证即将到期。我该如何续订? Re: The S32DS software has expired. 你好, 现在已扩展。 顺祝商祺! Peter
View full article
[RTD600 MCAL] Example FRDM-A-S32K358 EMAC lwIP FreeRTOS S32DS 3.6 RTD 6.0.0 * Detailed Description: * Updated the example lwip_FreeRTOS_s32K358 to enable pinging the lwIP stack from the command window * * ping 192.168.0.200 * * Pinging 192.168.0.200 with 32 bytes of data: * * Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * * Ping statistics for 192.168.0.200: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), * Approximate round trip times in milli-seconds: * Minimum = 0ms, Maximum = 1ms, Average = 0ms * * FRDM-A-S32K358: * - All jumpers in default positions. * * Configuration: * - Updated pin configuration * - Updated clock configuration * - IP address left as default (192.168.0.200) and enabled UDP_ECHO. * - Added DIO flip API. * * main.c * - Updated only the header * * test.c * - Commented out the code that shuts down the TCP/IP stack after its predefined timeout * - Added LED task * * Test HW: FRDM-A-S32K358 SCH-96522 Rev. A PDF: SPF-96522 * MCU: S32K358 * Debugger: PEmicro * Target: internal_FLASH * EVB connection: EMAC J7 Ethernet RJ45 connector <-> Laptop DELL, Windows 11 * or EMAC <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11 * * Revision History: * Ver Date Author Description of Changes * 1.0 Jul-29-2026 Julián Aragón Initial version FRDM-A-S32K358 LwIP enablement with RTD 6.0.0.
View full article
Getting Started with USB Audio on i.MX boards Introduction.  USB is a highly efficient interface for transporting audio and voice data, offering sufficient bandwidth for applications from voice telephony to high-quality audio playback and recording. To ensure compatibility between devices, the USB Audio Class specification defines standardized mechanisms for audio transport and control, allowing audio peripherals to operate with generic drivers and minimizing platform software requirements.    For i.MX processors, this article describes how an i.MX board can function as a standard USB audio device, enabling audio data to be streamed through the USB port to a host computer. This capability is important for applications such as USB microphones, speakers, audio gateways, and voice-processing systems.   As a result, developers can efficiently implement real time audio transfer between i.MX boards and host systems using standard USB audio drivers without requiring additional proprietary interfaces.   Required equipment. i.MX95 FRDM board (this is the selected board for this post, it works for others). Debug USB-C cable. Data USB-C cable. USB-C power supply. Ethernet cable. Speakers or headphones with 3.5mm input plug. Personal computer. To start, we need to flash our Linux BSP into the board. You can build it by yourself or use the pre-built BSP to facilitate the process. This post was tested with Linux 6.18.20_2.0.0, if you have issues to flash the board, please refer to this article: Flashing Linux BSP using UUU This is how my hardware setup looks: Media.jpg USB gadget setup. The following script configures the board to work as an USB audio gadget in Linux. This setup allows the board to be detected as a standard audio device, enabling audio streaming over the USB connection without requiring a custom USB protocol on the host side. The script creates the USB gadget configuration, assigns the required USB descriptors, with predefined audio parameters such as 16 kHz sample rate, 32-bit sample size, and single-channel capture/playback support. This example is useful for applications such as voice capture, audio processing, USB microphones, or embedded audio demos. #!/bin/sh # USB gadget ConfigFS paths CONFIGFS=/sys/kernel/config/usb_gadget GADGET=$CONFIGFS/g1 CONFIG=$GADGET/configs/c.1 FUNCTIONS=$GADGET/functions # USB device descriptors and audio configuration VID="0x1fc9" PID="0x0330" SERIALNUMBER="0123456789" MANUFACTURER="NXP Semiconductors" PRODUCT="i.MX USB Audio Gadget" SAMPLE_RATE=16000 SAMPLE_SIZE=4 # 32-bit audio samples echo "Setting up USB gadget with the following parameters:" echo " Vendor ID: $VID" echo " Product ID: $PID" echo " Serial Number: $SERIALNUMBER" echo " Manufacturer: $MANUFACTURER" echo " Product: $PRODUCT" echo " Sample Rate: $SAMPLE_RATE Hz" function add_uac2_function() { # Create a USB Audio Class function instance mkdir $FUNCTIONS/uac2.$1 echo "$PRODUCT $1" > $FUNCTIONS/uac2.$1/function_name # c_* parameters configure USB Capture # p_* parameters configure USB Playback # Audio sample rate configuration echo $SAMPLE_RATE > $FUNCTIONS/uac2.$1/c_srate echo $SAMPLE_RATE > $FUNCTIONS/uac2.$1/p_srate # Audio sample size in bytes echo $SAMPLE_SIZE > $FUNCTIONS/uac2.$1/c_ssize echo $SAMPLE_SIZE > $FUNCTIONS/uac2.$1/p_ssize echo $2 > $FUNCTIONS/uac2.$1/c_chmask echo $3 > $FUNCTIONS/uac2.$1/p_chmask # Enable mute and volume controls visible to the USB host echo 0x1 > $FUNCTIONS/uac2.$1/c_mute_present echo 0x1 > $FUNCTIONS/uac2.$1/c_volume_present echo 0x1 > $FUNCTIONS/uac2.$1/p_mute_present echo 0x1 > $FUNCTIONS/uac2.$1/p_volume_present # Add the UAC2 function to the active USB configuration ln -s $FUNCTIONS/uac2.$1 $CONFIG } function create_config() { # Create the USB gadget device mkdir $GADGET # Set USB Vendor ID and Product ID echo $VID > $GADGET/idVendor echo $PID > $GADGET/idProduct # Standard USB string descriptors mkdir $GADGET/strings/0x409 echo $SERIALNUMBER > $GADGET/strings/0x409/serialnumber echo $MANUFACTURER > $GADGET/strings/0x409/manufacturer echo $PRODUCT > $GADGET/strings/0x409/product # Create USB configuration description mkdir -p $CONFIG/strings/0x409 echo $1 > $CONFIG/strings/0x409/configuration } # Create a UAC2 audio gadget with mono capture and mono playback create_config "UAC2" add_uac2_function "Active" 0x1 0x1 echo "Done" Clean USB gadget. If you need to free up the USB port, it is necessary to run the following script. #!/bin/sh # USB gadget ConfigFS paths CONFIGFS=/sys/kernel/config/usb_gadget GADGET=$CONFIGFS/g1 CONFIG=$GADGET/configs/c.1 FUNCTIONS=$GADGET/functions # Verify that the gadget exists before attempting cleanup if [ ! -d "$GADGET" ]; then echo "Gadget does not exist" exit 0 fi # Disconnects the gadget from the host before removal. echo "" > $GADGET/UDC 2>/dev/null # Remove UAC2 function links from the configuration rm -f $CONFIG/uac2.* 2>/dev/null # Remove UAC2 function instances rmdir $FUNCTIONS/uac2.* 2>/dev/null # Remove configuration strings and configuration directory rmdir $CONFIG/strings/0x409 2>/dev/null rmdir $CONFIG/strings 2>/dev/null rmdir $CONFIG 2>/dev/null # Remove gadget string descriptors rmdir $GADGET/strings/0x409 2>/dev/null rmdir $GADGET/strings 2>/dev/null # Remove the gadget itself rmdir $GADGET 2>/dev/null echo "Cleanup completed" Testing. Both scripts can be created into the board using nano or a similar text editor through the console but is easier to do it in your host machine and send it for example using SCP. After you created both scripts you can send them with the next command: scp @ : Once you connected the Ethernet cable in any of the available RJ45 connectors in your board, you can get the IP address with the next command: ifconfig Now, in your host machine, you can go to the path where are your USB scripts and send them: scp cleanup_usb_gadget.sh root@ :~/ scp setup_usb_gadget.sh root@ :~/ After transfer the scripts to the board, you need to change file permissions to execute the scripts with chmod and run USB gadget setup script to configure the board as a USB audio interface. chmod u+x *_usb_gadget.sh JorgeCas_0-1782324986101.png Once this script have been executed you can see the USB port in ALSA as a sink/source device: JorgeCas_2-1782325559529.png Then, you need to connect the USB port to a host computer and will be recognized as an USB interface: JorgeCas_4-1782325847685.png You can validate that the device is working according to the configuration defined in setup script: Screenshot 2026-07-29 104314.png I will use Audacity to test audio transfer from on board microphones, in Edit -> Preferences -> Audio settings select i.MX Active as recording device: JorgeCas_5-1782326183462.png Note: Use the same sample rate of setup_usb_gadget.sh configuration to avoid errors with the DAW. In the board, I will start the recording by running the following GStreamer pipeline, which captures audio from the onboard microphones and streams it through the USB port: gst-launch-1.0 alsasrc device=hw:micfilaudio,0 ! queue ! audioconvert ! audio/x-raw,channels=1,rate=16000,format=F32LE ! audioconvert ! alsasink device=hw:UAC2Gadget,0 After this configuration, add an audio track and now, is possible to get the audio and record it directly in the DAW: JorgeCas_0-1782327009216.png If you want to play audio from host PC trough the i.MX board, you need to run the next command before start the audio playback in host. Make sure that the audio card selected is not busy: gst-launch-1.0 -v alsasrc device=hw:UAC2Gadget,0 ! audio/x-raw,format=S32LE,rate=16000,channels=1 ! audioconvert ! audioresample ! audio/x-raw,format=S16LE,rate=48000,channels=2 ! audioconvert ! alsasink device=plughw:mqsaudio,0 In this case, I selected the MQS output in 3.5mm output jack, you can connect the speakers or headphones with this connector. After run the clean USB gadget script, the USB audio device is not longer detected in host PC and the board output is the next: JorgeCas_3-1782325608663.png References. USB Implementers Forum. (1998, March 18). Universal Serial Bus device class definition for audio devices (Release 1.0) [PDF]. USB-IF. https://www.usb.org/sites/default/files/audio10.pdf   
View full article
i.MX93 AHAB セキュアブート、RSA-PSS署名、およびHSMモード こんにちは、 i.MX93-evkプラットフォームでのRSA-PSS署名認証に関してCSTで遭遇した問題を報告したいと思います。これはバグだと思います。以下に、私がこの発見に至るまでの手順を説明します。 現在、i.MX93-EVKプラットフォーム上でセキュアブート手順を実装しており、標準で文書化されたCST v4.0.1を使って動作させることに成功しました。 次に、CST の外で OpenSSL を直接使用して、さまざまなバイナリに署名したいと考えました (注: これは PKCS#11 の設定ではなく、OpenSSL CLI/API で独自の RSA キーを使用しているだけです)。私が実現したかったことをまさに説明している以下の手順書を見つけました: AHABデバイスでのコード署名のためのHSMモードの使用.pdf これは、コード署名ツール(CST)が提供するahab_pki_treeツールを使用して生成されたキーと、以下のパラメータでうまく機能します。 既存のCAキーを使用する:n キータイプ: rsa-pss 鍵長:4096ビット ダイジェストアルゴリズム: sha384 しかし、私がCST以外でバイナリに署名したい理由は、すでに他の様々な成果物の署名に使用しているRSA鍵を持っているからです。このキーを使用してさまざまなバイナリファイルに署名し、リンク先のプロセスで説明されているように署名済みハッシュを再統合しようとすると、次のエラーが発生します(CST v4.0.1)。 [ERROR] CST: The signature file spl_data.sig is not valid 全てが正しいことを再確認した後、OpenSSLを使用して署名を検証するテストも以下のように行いました。 $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK 予想と実際: OpenSSLが署名が有効なPSS署名であることを確認したので、CSTも再統合時にそれを受け入れると予想していました。しかし、CSTはそれを無効として拒否します。 CSTのソースコードを詳しく調べ始めたところ、OpenSSLによる検証は成功しているにもかかわらず、署名が無効であると誤って報告されていた理由が分かりました。 CSTが署名を確認する際、以下の処理を行います。 OpenSSL API呼び出しを使用して、公開鍵から「公開鍵アルゴリズム」フィールドを取得します。 このフィールドに基づいて、別の OpenSSL API 呼び出しを使用して、基本的に「指定された署名ファイルは、使用されている公開鍵アルゴリズムに対応していますか?」と問い合わせます。 NXPのドキュメントで「RSA-PSS」キーと呼ばれているものを生成・使用する場合、「公開鍵アルゴリズム」フィールドは rsassaPssと等しく、上記のチェックは正しく動作します。 しかし、汎用RSA鍵を使用する場合、「公開鍵アルゴリズム」フィールドはrsaEncryptionとなり、CSTはこれをPKCS#1 v1.5と誤って解釈しますが、実際にはPKCS#1 v2.1(PSS)形式で署名することも可能です。 私は、自分の署名がPSS署名であることをCSTのソースコードにハードコーディングすることで、この誤った仮定を検証しました。その結果、CSTによって署名が正常に検証され、最終バイナリに再挿入されることができました。その後、閉じた状態のデバイスでは期待どおりに動作しました。 必要であれば、特に関連するOpenSSLの各種関数呼び出しに関して、さらに詳しい情報を提供いたします。 これがCSTの既知の制限なのか、それとも汎用RSAキーで署名を生成・使用している点に何か見落としているのか確認してもらえますか? 余談ですが、HSDKも試しました。これはNXPがAHABベースのプラットフォーム向けに推奨している新しいツールのようですが、署名したいバイナリをエクスポートして手動で署名し、CSTの手順に似た方法で再挿入する方法が見つかりませんでした。これは実現可能かどうかご存知ですか? よろしくお願いいたします。 Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode こんにちは、 実際、あなたが使っている文書は正しいです。これは、まだCSTを利用しているお客様に推奨されるアプローチです。AHABおよび特に新しいi.MX9ファミリーのお客様には、セキュリティのイネーブルメントのためにSPSDKへの移行を推奨しています。 SO、あなたが踏んだ手順やツールの変更点をCAN共有してください。必要ならSO内部チームと確認・共有CAN。 また、SPSDKについては、以下も参考にしてください。 https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html お役に立てば幸いです。 よろしくお願いいたします。 アルド。
View full article
MPC8308CVMAGDA 例外 0055255 谁能解释一下上述零件编号的例外情况。我们需要 MPC8308CVMAGDA,但收到的零件标有 SPC8308CVMAFDA ,AF 零件编号结尾表示 333Mhz,但所需零件编号表示 400Mhz。该设备的右上角还有一个我之前没见过的 “M” 标记,这是否是例外情况的一部分?部件的功能是否相同? 我附上了设备照片和收到的标签。 Re: MPC8308CVMAGDA EXCEPTION 0055255 您可以询问供应商是否有 COC 证书。只有拥有COC证书的供应商才是真正的原始供应商。 Re: MPC8308CVMAGDA EXCEPTION 0055255 你买了假货立即归还。 这是一个骗局。 我可以把正确的图片发给你。我们的 PCB 工厂会拍照。 1.png Re: MPC8308CVMAGDA EXCEPTION 0055255 您好, 我们的情况也一样。你的案子进展如何?NXP 是否确认MPC8308CVMAGDA 和S PC8308CVMA F DA 是相同的? 谢谢!
View full article
MPC8308CVMAGDA EXCEPTION 0055255 Does anyone have an explanation for the exception on the part number above. We require MPC8308CVMAGDA, however the parts received are marked with SPC8308CVMAFDA, AF part number ending indicates 333Mhz but the required part number denotes 400Mhz. The device also has an addition 'M' marking in the top right corner which i haven't see previously, has this been added as part of the exception? Will the part have the same functionality?  I have attached a photo of the device and the label received.  Re: MPC8308CVMAGDA EXCEPTION 0055255 You can ask the supplier if they have COC certificate. Only the supplier with COC certificate is the real original supplier. Re: MPC8308CVMAGDA EXCEPTION 0055255 You bought a fake product. Return it immediately. This is a scam. I can send you the correct images. Our PCB factory takes photos. 1.png Re: MPC8308CVMAGDA EXCEPTION 0055255 hi, We have the same scenario. How did you move forward in your case?. Did NXP confirm that MPC8308CVMAGDA and SPC8308CVMAFDA are identical? Thank you.
View full article
MPC8308CVMAGDA例外0055255 上記の部品番号の例外について説明できる人はいますか。MPC8308CVMAGDA が必要ですが、受け取った部品にはS PC8308CVMA F DA とマークされており、AF 部品番号の末尾は 333Mhz を示していますが、必要な部品番号は 400Mhz を示しています。デバイスの右上隅には、以前は見たことのない「M」マークも追加されていますが、これは例外の一部として追加されたのでしょうか?その部品は同じ機能を持ちますか? 受け取ったデバイスとラベリングの写真を添付しました。 Re: MPC8308CVMAGDA EXCEPTION 0055255 サプライヤーに COC 証明書があるかCAN尋ねることができます。COC 証明書を持つサプライヤーだけが真の正規サプライヤーです。 Re: MPC8308CVMAGDA EXCEPTION 0055255 偽造品を購入しました。すぐに返却してください。 これは詐欺です。 正しい画像をCANお送りします。当社のPCB工場では写真を撮ります。 1.png Re: MPC8308CVMAGDA EXCEPTION 0055255 こんにちは、 私たちも同じ状況です。あなたはCASEをどのように進めましたか?NXPは、MPC8308CVMAGDAとS PC8308CVMA F DAが同一であることを確認しましたか? よろしくお願いします。
View full article
i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode Hello, I'd like to report an issue I encountered with CST regarding RSA-PSS signature verification on an i.MX93-evk platform, which I believe is a bug. Below, I describe the steps that led me to this discovery. I'm currently implementing the secure boot procedure on an i.MX93-EVK platform and successfully got it working with the standard, documented procedure using CST v4.0.1. I then wanted to sign the various binaries outside of CST, using OpenSSL directly (note: this is not a PKCS#11 setup, I'm just using my own RSA key with the OpenSSL CLI/API). I came across the following procedure, which describes exactly what I wanted to achieve: Using HSM mode for code signing in AHAB devices.pdf This works well with keys generated using the ahab_pki_tree tool provided by the Code Signing Tool (CST), with the following parameters: use an existing CA key: n key type: rsa-pss key length: 4096-bit digest algorithm: sha384 However, the reason I want to sign binaries outside of CST is that I already have an RSA key that is used for signing various other artifacts. When I use this key to sign the various bin files and then try to reintegrate the signed hashes as described in the linked procedure, I get the following error (CST v4.0.1): [ERROR] CST: The signature file spl_data.sig is not valid After double-checking that everything was correct, I also tested verifying my signature using OpenSSL as follows: $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK Expected vs actual: since OpenSSL confirms the signature is a valid PSS signature, I expected CST to accept it during reintegration as well. Instead, CST rejects it as invalid. I started digging into the CST source code and found why it was incorrectly reporting the signature as invalid, even though it was successfully verified by OpenSSL. When CST checks the signature, it does the following: Using OpenSSL API calls, it retrieves the "Public Key Algorithm" field from the public key. Based on this field, it uses another OpenSSL API call to essentially ask: "Does the given signature file correspond to the public key algorithm used?" When generating/using what the NXP documentation calls "RSA-PSS" keys, the "Public Key Algorithm" field is equal to rsassaPss and the checks above work correctly. However, when using a generic RSA key, the "Public Key Algorithm" field is equal to rsaEncryption, and CST wrongly assumes this means the signature format is PKCS#1 v1.5, even though it's entirely possible to sign using the PKCS#1 v2.1 (PSS) format. I confirmed this incorrect assumption by hardcoding into the CST source code that my signature was a PSS one, and I was then able to get my signature successfully verified and reinserted by CST into the final binary. It then worked as expected on my closed device. I'm happy to provide more details if needed, especially regarding the various OpenSSL function calls involved. Could you confirm whether this is a known limitation of CST, or if I might be missing something in how I'm generating/using the signature with a generic RSA key? As a side question, I also tried using SPSDK, which seems to be the new tool NXP is promoting for AHAB-based platforms, but I couldn't find a way to export the binaries to be signed, sign them manually, and then reinsert them, similar to the CST procedure. Do you know if this is feasible? Thanks in advance. Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode Hello, Actually the document that you are using is correct, is the aproach we suggest for customers that are still using CST. For AHAB, and specially new i.MX9 familly we suggest customers to move to the SPSDK as this is the tool we are using for enablement on security. Even so you can share the steps you have followed and the changes you made to the tool, so I can review and share with internal team if needed. Also, for the SPSDK you may have a look to the following: https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html Hope this helps, Best regards/Saludos, Aldo.
View full article
i.MX93 AHAB 安全启动、RSA-PSS 签名和 HSM 模式 你好, 我想报告我在 i.MX93-evk 平台上使用 CST 进行 RSA-PSS 签名验证时遇到的问题,我认为这是一个 bug。下面我将描述我得出这一发现的步骤。 我目前正在 i.MX93-EVK 平台上实施安全启动程序,并已使用 CST v4.0.1 按照标准、有记录的程序成功使其工作。 然后,我想在 CST 之外对各种二进制文件进行签名,直接使用 OpenSSL(注意:这不是 PKCS#11 设置,我只是使用我自己的 RSA 密钥和 OpenSSL CLI/API)。我找到了以下步骤,它恰好描述了我想要实现的目标:在 AHAB 设备中使用 HSM 模式进行代码签名.pdf 这对于使用代码签名工具 (CST) 提供的ahab_pki_tree工具生成的密钥效果很好,参数如下: 使用现有 CA 密钥:否 密钥类型:rsa-pss 密钥长度:4096 位 摘要算法:sha384 但是,我想要在 CST 之外对二进制文件进行签名的原因是,我已经有一个 RSA 密钥,该密钥用于对各种其他工件进行签名。当我使用此密钥对各种 bin 文件进行签名,然后尝试按照链接中的步骤重新集成签名哈希值时,出现以下错误(CST v4.0.1): [ERROR] CST: The signature file spl_data.sig is not valid 在仔细检查确认一切无误后,我还使用 OpenSSL 测试了签名验证,步骤如下: $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK 预期与实际情况:由于 OpenSSL 确认该签名是有效的 PSS 签名,我预期 CST 在重新集成期间也会接受它。CST 却将其判定为无效并拒绝接受。 我开始深入研究 CST 源代码,并发现了它错误地将签名报告为无效的原因,即使 OpenSSL 已成功验证了该签名。 CST 检查签名时,会执行以下操作: 它使用 OpenSSL API 调用,从公钥中检索“公钥算法”字段。 根据该字段,它使用另一个 OpenSSL API 调用来询问:“给定的签名文件是否与所使用的公钥算法相符?” 当生成/使用 NXP 文档中称为“RSA-PSS”的密钥时,“公钥算法”字段等于rsassaPss ,并且上述检查工作正常。 然而,当使用通用 RSA 密钥时,“公钥算法”字段等于rsaEncryption ,CST 错误地认为这意味着签名格式为 PKCS#1 v1.5,即使完全可以使用 PKCS#1 v2.1 (PSS) 格式进行签名。 我通过在 CST 源代码中硬编码我的签名是 PSS 签名来证实了这个错误的假设,然后我成功地让 CST 验证了我的签名并将其重新插入到最终的二进制文件中。然后它在我的封闭设备上运行正常。 如有需要,我很乐意提供更多细节,特别是关于所涉及的各种 OpenSSL 函数调用。 能否确认这是否是 CST 的已知限制,或者我在使用通用 RSA 密钥生成/使用签名时是否遗漏了某些内容? 另外,我还尝试使用 SPSDK,这似乎是 NXP 为基于 AHAB 的平台推广的新工具,但我找不到导出要签名的二进制文件、手动签名,然后再重新插入的方法,类似于 CST 过程。你知道这是否可行吗? 先行致谢。 Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode 你好, 实际上,您正在使用的文档是正确的,这是我们建议仍然使用 CST 的客户采用的方法。对于 AHAB,特别是新的 i.MX9 系列,我们建议客户迁移到 SPSDK,因为这是我们用于启用网络安全的工具。 即便如此,您仍然可以分享您遵循的步骤以及您对工具所做的更改,以便我进行审核,并在需要时与内部团队分享。 另外,关于SPSDK,您可以参考以下内容: https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html 希望这能帮到你。 此致敬礼/Saludos, 阿尔多。
View full article
ARA240(.dvm)用のカスタムONNX/TFLiteモデルをコンパイルする方法は?(搬送波はi.MX95 FRDMを使用しています) 私はi.MX95 FRDMのARA240 M.2アクセラレータを評価しています。 ランタイムは正常に動作しています。 ARA240はPCIe経由で検出されます。 nnapp は提供された .dvm を正常に実行しますモデル. ランタイムSDKs(rt-sdk-ara240)とPython DVAPIバインディングがインストールされています。 しかし、自分でMobileNetモデルを展開したいのですが、モデルを.dvmにコンパイルするためのツールチェーンが見つかりません形式。 私の質問は以下のとおりです。 カスタムONNX/TFLiteモデルを.dvmにコンパイルする際のサポートワークフローは何ですか?ARA240用ですか? Ara2コンバータ(またはdvconvert/dvnc)は公開されているのか、それともRuntime SDKsとは別に配布されているのか? NXPがサポートするカスタムCNNモデルを展開する方法はありますか(例:MobileNet) を ARA240 に移植する際に、私が見落としている点はありますか? どんなガイダンスやドキュメントでも大変ありがたいです。 よろしくお願いします! Re: How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) CNNモデルには、公式ウェブサイトからダウンロードできるAra2ランタイムパッケージが役立つかもしれません Ara240のランタイム環境を提供します。Ara240モジュール上で事前コンパイルされたCNNおよびGenAIモデルをダウンロードし実行するためのスクリプトを提供します。ご質問への回答は、下記のAIによる回答をご参照ください。お役に立てれば幸いです。 =========================================================================== まず、重要な背景説明から始めましょう。 ARA240(旧名:キナラ・アラ2).dvm= Kinara DNN 仮想マシンのバイナリモデル、このDNPU用の独自のコンパイルされたグラフ形式。 rt-sdk-ara2 (target runtime + DVAPI) ≠ コンパイラツールチェーン. i.MX95には推論ランタイムのみがインストールされています。オフラインモデルコンパイラは別のソフトウェアです。 1. サポートされているワークフロー: ONNX / TFLite → .dvm 公式なエンドツーエンドの流れ: PyTorch/TensorFlow → ONNX / TFLite → Ara2オフラインコンパイラ(dvconvert / dvnc、Ara2コンバーター) → 量子化(MobileNetのようなCNNではint8推奨) → 最適化された.dvmバイナリ → .dvm を i.MX95 FRDM にデプロイする → PCIe経由でARA240にDVAPI / nnapp / libaraclientをロードして実行する 重要な制約:コンパイルはi.MX95ターゲットボード上で実行できません。 コンパイラはホスト側のLinux x86_64ツールチェーンで、外部のPC/ワークステーション上で実行されます。 2. dvconvert / Ara2 Converterは公開されているのでしょうか? いいえ。コンバーターは一般にダウンロードできません。 NXP GitHubでホストされているrt-sdk-ara2 Debianパッケージには、ターゲットランタイム、DVAPI Pythonバインディング、事前構築済みのデモ.dvmのみが含まれていますモデル.コンパイラバイナリは含まれていません。 Ara2コンパイラスイート(dvconvert、dvnc)はNXPの制限付きソフトウェアアクセスのもとで別途配布されています。 このツールチェーンはキナラに起源を持ち、NXPがキナラを買収した後は、NXPの営業/CAS(お客様アプリケーションサポート)を通じてアクセス管理が行われました。 3. NXPが公式にサポートするカスタムCNN(MobileNet)の導入方法はありますか? はい、ただしAra SDKコンパイラへのアクセスを正式に申請する必要があります: コンバータを入手するための公式なルート お近くのNXP FAE / NXP CASサポートチケットにお問い合わせください: ハードウェア: FRDM i.MX95 + ARA240 M.2 DNPU リクエスト:カスタムONNX/TFLite CNNコンパイルを.dvmにするためのAra SDKオフラインモデルコンパイラ(dvconvert)へのアクセス 制限付きAraツールについてはNXPのソフトウェアライセンス契約に署名する必要があります。 NXPは当初、更新されたeIQ Toolkit(2026年中頃予定)と並行してより広範なリリースを計画していました。現在はサポートされている評価お客様向けにゲートされています。 ツールアクセスを待つ間の回避策と代替案 カスタム.dvmは生成できませんdvconvertを使用せずにローカルで実行します。ARA240.dvm用のオープンソースのサードパーティ製コンバーターは存在しません。 オプションA:早期アクセス評価の一環としてNXPのエンジニアリングサポートにモデルコンパイルを依頼する。 オプションB:一時的にワークロードを分散:未コンパイルのONNXをi.MX95オンボードeIQ Neutron上で実行し、Araコンパイラへのアクセスを待つ間に実行します(これはARA240へのオフロードなし)。 注意:i.MX95の内蔵Neutron NPU(.neutronモデル)と外部のARA240 DNPU(.dvm)を混同しないでください。彼らは完全に互換性のないバイナリフォーマットを使っています。 4. 避けるべき主な落とし穴 rt-sdk-ara2内にはPaddle2ONNX / ONNXコンバーターユーティリティはありません。 事前に構築されたデモ用.dvmファイルSDKに付属して配布されたファイルは、変換ロジックを抽出するためにリバースエンジニアリングすることはできません。 現在、ARA240用のウェブベースのモデルコンバーターは利用できません。 MobileNet v1/v2は、ツールチェーンを入手すればdvconvertによって完全にサポートされるアーキテクチャです。ONNXがクリーンアップされていることを確認してください(未使用のノードを削除し、入力形状を固定し、標準演算のみを使用する)。 NXPサポートチケットに直接送る提案文言 FRDM i.MX95上でARA240 M.2モジュールを評価しています。PCIe列挙、サンプル.dvmを提供実行、rt-sdk-ara2、DVAPIは機能します。カスタムMobileNet ONNXモデルを.dvmにコンパイルするには、Ara2オフラインコンパイラ(dvconvert/dvnc)へのアクセスが必要ですバイナリ。ホスト側のAra SDKモデル変換ツールチェーンを取得する手順を共有してください。
View full article
How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) I'm evaluating the ARA240 M.2 accelerator on the i.MX95 FRDM. The runtime is working correctly: ARA240 is detected over PCIe. nnapp successfully runs the provided .dvm models. The Runtime SDK (rt-sdk-ara240) and Python DVAPI bindings are installed. However, I would like to deploy my own MobileNet model, and I'm unable to find the toolchain required to compile models into the .dvm format. My questions are: What is the supported workflow to compile a custom ONNX/TFLite model into .dvm for ARA240? Is the Ara2 Converter (or dvconvert/dvnc) publicly available, or is it distributed separately from the Runtime SDK? Is there an NXP-supported way to deploy custom CNN models (e.g. MobileNet) onto ARA240, that I am missing? Any guidance or documentation would be greatly appreciated. Thanks! Re: How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) For CNN model,Ara2 Runtime Package could be helpful which can downloaded from the official website Provides a runtime environment for Ara240.Provides scripts to download and run pre-compiled CNN and GenAI models on Ara240 modules. For your question, please refer to the AI generated answer as below, hope it helps  =========================================================================== First, critical background: ARA240 (formerly Kinara Ara-2) .dvm = Kinara DNN Virtual Machine binary model, proprietary compiled graph format for this DNPU. rt-sdk-ara2 (target runtime + DVAPI) ≠ compiler toolchain. You have only the inference runtime installed on i.MX95; the offline model compiler is separate software. 1. Supported workflow: ONNX / TFLite → .dvm Official end-to-end flow: PyTorch/TensorFlow → ONNX / TFLite → Ara2 Offline Compiler (dvconvert / dvnc, Ara2 Converter) → Quantization (int8 preferred for CNN like MobileNet) → Optimized .dvm binary → Deploy .dvm to i.MX95 FRDM → Load & run via DVAPI / nnapp / libaraclient over PCIe to ARA240 Important constraint: Compilation cannot run on the i.MX95 target board. The compiler is a host-side Linux x86_64 toolchain, executed on an external PC/workstation. 2. Is dvconvert / Ara2 Converter public? NO. The converter is NOT publicly downloadable. The rt-sdk-ara2 Debian packages hosted on NXP GitHub only contain target runtime, DVAPI Python bindings, prebuilt demo .dvm models. No compiler binaries included. The Ara2 compiler suite (dvconvert, dvnc) is distributed separately under NXP restricted software access. This toolchain originated from Kinara; after NXP acquired Kinara, access is managed via NXP sales / CAS (Customer Application Support). 3. Is there an official NXP-supported path to deploy custom CNN (MobileNet)? Yes, but you need to formally request access to the Ara SDK compiler: Official route to obtain the converter Contact your local NXP FAE / NXP CAS support ticket referencing: Hardware: FRDM i.MX95 + ARA240 M.2 DNPU Request: Access to Ara SDK offline model compiler (dvconvert) for custom ONNX/TFLite CNN compilation to .dvm You will need to sign NXP’s software license agreement for restricted Ara tooling. NXP originally planned wider release alongside updated eIQ Toolkit (previously scheduled mid-2026); at present, it remains gated to supported evaluation customers. Workarounds & alternatives while waiting for tool access You cannot generate custom .dvm locally without dvconvert. There is no open-source third-party converter for ARA240 .dvm. Option A: Ask NXP engineering support to perform model compilation as part of your early access evaluation. Option B: Split workload temporarily: run uncompiled ONNX via CPU/Neutron NPU on i.MX95 onboard eIQ Neutron while waiting for Ara compiler access (this does not offload to ARA240). Note: Do not confuse i.MX95’s built-in Neutron NPU (.neutron model) with external ARA240 DNPU (.dvm). They use completely incompatible binary formats. 4. Key pitfalls to avoid There is no Paddle2ONNX / ONNX converter utility inside rt-sdk-ara2. Prebuilt demo .dvm files distributed with the SDK cannot be reverse-engineered to extract conversion logic. No web-based model converter available for ARA240 today. MobileNet v1/v2 are fully supported architectures by dvconvert once you receive the toolchain; ensure ONNX is cleaned (remove unused nodes, fixed input shape, standard ops only). Suggested wording you can directly send to NXP support ticket We are evaluating ARA240 M.2 module on FRDM i.MX95. PCIe enumeration, provided sample .dvm execution, rt-sdk-ara2 and DVAPI are functional. We require access to the Ara2 offline compiler (dvconvert/dvnc) to compile custom MobileNet ONNX models into .dvm binaries. Please share procedure to obtain the host-side Ara SDK model conversion toolchain.
View full article
如何为 ARA240 (.dvm) 编译自定义 ONNX/TFLite 模型?(载板型号为 i.MX95 FRDM) 我正在评估 i.MX95 FRDM 上的 ARA240 M.2 加速器。 运行时运行正常: 通过 PCIe 检测到 ARA240。 nnapp 成功运行提供的 .dvm 文件模型。 已安装运行时 SDK (rt-sdk-ara240) 和 Python DVAPI 绑定。 但是,我想部署我自己的 MobileNet 模型,却找不到将模型编译成 .dvm 文件所需的工具链。格式。 我的问题是: 将自定义 ONNX/TFLite 模型编译成 .dvm 文件的受支持工作流程是什么?适用于 ARA240? Ara2 变流器(或 dvconvert/dvnc)是公开提供的,还是与运行时 SDK 分开分发的? NXP 是否支持部署自定义 CNN 模型(例如)MobileNet) 到 ARA240,我漏掉了什么吗? 任何指导或文件都将不胜感激。 谢谢您! Re: How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) 对于 CNN 模型,Ara2 运行时代码包,软件包可能很有帮助,可以从官方网站下载。 为 Ara240 提供运行时环境。提供脚本以下载并在 Ara240 模块上运行预编译的 CNN 和 GenAI 模型。关于您的问题,请参考下方人工智能生成的答案,希望对您有所帮助。 =========================================================================== 首先,需要一些关键背景信息: ARA240(原名 Kinara Ara-2).dvm= Kinara DNN 虚拟机二进制模型,此 DNPU 的专有编译图格式。 rt-sdk-ara2(目标运行时 + DVAPI)≠ 编译器工具链。 i.MX95 上只安装了推理运行时;离线模型编译器是单独的软件。 1. 支持的工作流程:ONNX / TFLite → .dvm 官方端到端流程: PyTorch/TensorFlow → ONNX / TFLite → Ara2 离线编译器(dvconvert / dvnc,Ara2 变流器) → 量化(对于像 MobileNet 这样的 CNN,首选 int8) → 优化后的 .dvm二进制 → 将 .dvm 文件部署到 i.MX95 FRDM → 通过 PCIe 经由 DVAPI / nnapp / libaraclient 加载并运行至 ARA240 重要限制:编译无法在 i.MX95 目标板上运行。 该编译器是主机端 Linux x86_64 工具链,在外部 PC/工作站上执行。 2. dvconvert / Ara2 变流器 是公开的吗? 不。该变流器不可公开下载。 NXP GitHub 上托管的 rt-sdk-ara2 Debian 软件包仅包含目标运行时、DVAPI Python 绑定和预构建的演示 .dvm 文件。模型。不包含编译器二进制文件。 Ara2 编译器套件(dvconvert、dvnc)根据 NXP 限制软件访问权限单独分发。 该工具链源自 Kinara;NXP 收购 Kinara 后,访问权限由 NXP 销售/CAS(客户应用支持)管理。 3. NXP 是否有官方支持的途径来部署自定义 CNN(MobileNet)? 是的,但您需要正式申请访问 Ara SDK 编译器: 获取变流器的官方途径 请联系您当地的 NXP FAE / NXP CAS 支持团队,并参考,引用: 硬件:FRDM i.MX95 + ARA240 M.2 DNPU 请求:提供 Ara SDK 离线模型编译器 (dvconvert) 的访问权限,以便将自定义 ONNX/TFLite CNN 文件编译为 .dvm 文件。 您需要签署 NXP 的受限 Ara 工具软件许可协议。 NXP 最初计划与更新后的 eIQ Toolkit(原计划于 2026 年年中发布)一同进行更广泛的版本;目前,它仍然只对受支持的评估客户开放。 等待工具访问期间的变通方法和替代方案 您无法生成自定义 .dvm 文件。本地不使用 dvconvert。目前没有适用于 ARA240 .dvm 的开源第三方变流器。 方案 A:请 NXP 工程支持部门执行模型编译,作为您早期访问评估的一部分。 选项 B:暂时拆分工作负载:在等待 Ara 编译器访问期间,通过 i.MX95 板载 eIQ Neutron 上的 CPU/Neutron NPU 运行未编译的 ONNX(这不会卸载到 ARA240)。 注意:不要将 i.MX95 内置的 Neutron NPU(.neutron 型号)与外部 ARA240 DNPU(.dvm)混淆。它们使用完全不兼容的二进制格式。 4. 需要避免的关键陷阱 rt-sdk-ara2 中没有 Paddle2ONNX / ONNX 变流器实用程序。 预构建演示 .dvmSDK 中分发的文件无法通过逆向工程提取转换逻辑。 目前还没有适用于 ARA240 的基于网络的模型变流器。 一旦您收到工具链,dvconvert 将完全支持 MobileNet v1/v2 架构;确保 ONNX 已清理(删除未使用的节点、固定输入形状、仅使用标准操作)。 您可以直接将以下措辞发送给恩智浦技术支持工单。 我们正在对 FRDM i.MX95 上的 ARA240 M.2 模块进行评估。PCIe 枚举,提供示例 .dvm执行方面,rt-sdk-ara2 和 DVAPI 功能正常。我们需要访问 Ara2 离线编译器 (dvconvert/dvnc) 来将自定义 MobileNet ONNX 模型编译成 .dvm 文件。二进制.请分享获取主机端 Ara SDK 模型转换工具链的步骤。
View full article
Create a new model and configure it for NXP Hardware 1 Table of Contents • Introduction • Prerequisites • Creating a New Simulink Model • Configure the Model for NXP Hardware • Add Simulink Blocks • Build the Model • Flash and Run on Hardware • References • Conclusion 2 Introduction Developing embedded applications for NXP microcontrollers—especially platforms like the S32K series—involves using tools such as MATLAB/Simulink (MBDT – Model-Based Design Toolbox), S32 Design Studio (S32DS), and EB tresos. This article walks through the key steps involved in creating a new model and configuring it properly for NXP hardware, focusing on a practical workflow used in automotive and embedded systems projects. 3 Prerequisites Before starting, ensure the following tools are installed and correctly configured: MATLAB & Simulink NXP MBDT S32 Design Studio / EB tresos NXP RTD drivers USB / JTAG debugger (e.g., PEMicro) Target hardware (e.g., S32K344, S32K358) In addition to having the required tools installed, it is important to ensure that all components are properly integrated and compatible with each other. This includes matching the MATLAB/Simulink version with the supported release of the NXP MBDT, as well as aligning the RTD package with the selected microcontroller and AUTOSAR version. Environment variables, compiler paths, and licensing (for MATLAB, Simulink, and EB tresos) should also be verified prior to starting development. From a hardware perspective, make sure that the evaluation board or target ECU is correctly powered and that the debug interface (such as PEMicro) is functioning. Installing the appropriate USB drivers and checking connection through debug tools can prevent communication issues later in the workflow. Finally, it is recommended to validate the toolchain setup by running a simple example, such as a GPIO toggle or LED blink application, either directly in S32DS or through an existing Simulink example provided by MBDT. This step helps confirm that code generation, compilation, flashing, and execution on the target hardware are all working correctly before moving on to a more complex development. 4 Creating a New Simulink Model Step 1: Launch Simulink Open MATLAB Type simulink in the command window Select Blank Model Sebastian13_0-1784719500241.png Step 2: Save the Model Save with a clear naming convention, e.g. s32k344_led_blink.mdl 5 Configure the Model for NXP Hardware Step 3: Open Model Configuration Parameters Navigate to Model Settings ( Ctrl + E ) → Hardware Implementation Step 4: Select Hardware Board Set Hardware board to the appropriate NXP target For example, NXP S32Kxx Step 5: Select a Configuration Template Set Configuration Project Template to the appropriate NXP target For example, S32K344-Q172 S32 Config Tool If the board is not visible, ensure MBDT is properly installed. Sebastian13_1-1784719557125.png 6 Add Simulink Blocks Using the Library Browser, configure hardware peripherals. Sebastian13_3-1784719625876.png Step 6: Configure GPIO for LED Add a Dio block Configure: Function: Dio_FlipChannel Channel: e.g. DioLed0 Step 7: Add Level Variable Add Data Store Memory and Data Store Write blocks Connect the Dio block to the Data Store Write This will blink an LED because the Dio_FlipChannel function toggles the logical state of the selected GPIO pin every time it is executed. By connecting it to a Data Store Write, you are effectively allowing the system to store or propagate the updated state within the model. The blinking frequency is directly controlled by the task rate of your model, which makes it easy to adjust the LED behavior simply by changing the sample time, without modifying the core logic. In the Library Browser you will find numerous example projects that may be helpful (for example, s32k3xx_dio_s32ct ). Sebastian13_4-1784719654387.png 7 Build the Model Step 8: Generate Code Click Build Model ( Ctrl + B ) Sebastian13_5-1784719707916.png When you press the build button, Simulink automatically translates your model into C code and prepares it for execution on the target microcontroller. The generated files can be found in the project folder, where you can explore how each block was converted into embedded code. After generation, the toolchain creates an executable file and attempts to deploy it directly to the target board. 8 Flash and Run on Hardware Step 9: Connect Target Board Connect via debugger (USB / JTAG) Step 10: Deploy From Simulink (External Mode or Build & Deploy) Or manually via S32 Design Studio 9 References Quick Start Guide for S32K3X4EVB Board Model-Based Design Toolbox (MBDT) – How To 10 Conclusion Creating a new model and configuring it for NXP hardware involves: Setting up the Simulink model Configuring hardware-specific parameters Adding peripheral blocks Generating and deploying embedded code This workflow enables rapid prototyping and production-ready embedded development, especially in automotive systems leveraging AUTOSAR and NXP platforms. Developing embedded applications for NXP microcontrollers—especially platforms like the S32K series—often involves using tools such as MATLAB/Simulink (MBDT – Model-Based Design Toolbox), S32 Design Studio (S32DS), and AUTOSAR tools like EB tresos. This article walks through the key steps involved in creating a new model and configuring it properly for NXP hardware, focusing on a practical workflow used in automotive and embedded systems projects.
View full article