Ara240 Run Time Environment (rt-sdk-ara2) The Runtime SDK for AI/ML acceleration using the Ara240 NPU on NXP i.MX SoCs, provides the runtime environment for the Ara‑2 NPU.   Main Purpose of the Package    1. Provide the runtime environment for the Ara‑2 NPU This runtime sdk package installs everything needed for an i.MX system to communicate with and utilize the Ara240 NPU hardware, including: NPU drivers  Low‑level utilities (metrics, hardware bring‑up, flash tools) Proxy services that interface applications with the NPU Firmware loaders and NPU configuration files 2. Allow users to run AI/ML inference models on the NPU The Ara240 runtime environment includes tools for: Downloading pre‑compiled AI/ML models Running performance tests on the NPU Running classification, detection, pose, and segmentation models Inspecting HW IPS (inference/second) and real hardware performance   Scripts such as: fetch_models.sh ara_metrics.sh chip_info.sh program_flash.sh run_models_perf.sh 3. Automatically configure and optimize the i.MX system Installation does the following automatically: Expands system partition to handle large models (LLMs/VLMs) Sets up an 8GB SWAP for devices with limited RAM Prepares the runtime environment for AI workloads 4. Manage and update Ara‑2 firmware The package contains scripts to: Check the installed firmware version ( chip_info.sh ) Update firmware if needed ( program_flash.sh ) 5. Provide systemd service for automatic startup The SDK installs: A systemd service: rt‑sdk‑ara2.service   Walkthrough Video Below is the walkthrough video for this package (function() { var wrapper = document.getElementById('lia-vid-6396594498112w960h540r402'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) ARA2-M2-16G-GT ARA240 Hands-On Training

Motor synchronous control demonstration using EtherCAT with i.MX RT1180 (Japanese blog) We will demonstrate an integrated EtherCAT and motor control system, and introduce the high-performance microcontroller i.MX RT1180 that makes this possible. This demonstration showcases the synchronization capabilities of EtherCAT and the high-precision motor control that accompanies it. Motor synchronous control demonstration using EtherCAT Explanation of how the demo works The board configuration consists of three boards: one EtherCAT master board and two EtherCAT slave boards, which together achieve EtherCAT synchronization. The slave boards are equipped with motor drivers, and each slave board controls two motors, for a total of four motors. The two motors at each end are controlled by slave board 1 and slave board 2 respectively, which adjust the left-right position of the two motors in the center. The two motors in the center are also controlled by slave board 1 and slave board 2 respectively, and are responsible for meshing the gears together . Initially, the two central motors rotate synchronously with their gears meshed together, and then gradually separate to disengage. After the deactivation, the two central motors rotate at different speeds and approach each other again. The moment the gears mesh again, the two motors rapidly synchronize, achieving precise gear engagement. At the same time, the motors on both sides adjust the position of the two central motors to prevent them from colliding. After that, the separation, approach, and interlocking process is repeated. Now, let me explain why such advanced control is possible with the RT1180 microcontroller. i.MX RT1180 behavior First, within the i.MX RT1180 microcontroller, each core has a specific role. The M33 core (300MHz) is responsible for EtherCAT communication, and the M7 core (800MHz) is responsible for motor control. The M33 core runs on an EtherCAT stack, achieving faster read/write speeds, lower costs, energy efficiency, and higher communication and response speeds compared to external devices. The M7 core performs motor calculations (PWM) within 1.4 μs. This completes the update + ADC sample + closed loop vector control. The dual-core cooperative operation of the M33 and M7 ensures superior point control performance and guarantees the operation of high-performance motors. Furthermore, the generous 1.5MB of RAM memory improves work efficiency and leaves room for further customization by the user.   summary Based on these points, we believe the i.MX RT1180 is an optimal choice for those considering servo applications. The source code for this demo is available on NXP's Application Code Hub. Please see the link below for details. How to set up the motion control reference design on iMX.RT1180 =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making inquiries.(If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) We will demonstrate an integrated EtherCAT and motor control system, and introduce the high-performance microcontroller i.MX RT1180 that makes this possible. This demonstration showcases the synchronization capabilities of EtherCAT and the high-precision motor control that accompanies it. (Reading time: 10 minutes) i.MX RT Processors MCUXpresso Motor Control Technology Focus Japanese Blog

S32DS v3.6.6 S32K5 development package missing pins in package view for S32K566_437BGA In the S32DS Configuration Tool for the Pins, the S32K566_437BGA view is missing a number of pins in the package view. Is this my installation or a general issue?  Is there a plan to fix that? Re: S32DS v3.6.6 S32K5 development package missing pins in package view for S32K566_437BGA Hello @DirkEtzler , I hope this email finds you well. I am writing to you in regard to a product currently in your possession – an NPI (New Product Introduction) which has not been officially launched yet. Please be advised that customers who have been granted early access to such products have assigned their field engineers. Your designated field engineer should serve as your primary support channel for any issues, concerns or queries you may have about this product. Our online support team will be opening a wider range of support for this product once it has been officially released. Until then, they will not be equipped to provide the desired assistance. We appreciate your understanding in this matter and look forward to further enhance our partnership with you. Should you have any questions, please feel free to connect with your field engineer, or contact my team and me directly. Thank you for your understanding. Best regards, Pavel

MPX4115AP 端口 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> MPX4115 系列的数据表将MPX4115AP 列为"端口元件"。谁能帮我弄明白这意味着什么，端口的具体用途是什么。 Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 非常感谢您！ Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，梅加、 零件号中的字母 “A” 表示 “绝对”，因此施加在 P1 上的压力是根据密封在 P2 侧的真空参考测量的： 我们的压差传感器可通过部件编号中的字母 "D "来识别（例如MPX5100DP）和两个输入端口： 请仔细阅读这篇文章，以便更好地了解恩智浦压力传感器的压力测量和集成水平。 顺祝商祺！ 托马斯 Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，托马斯、 非常感谢你的答复。再澄清一点。与软管/导管连接的接口是否意味着传感器可以用作差分传感器？ Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，梅加、 移植版本（带有 AP、AS 或 ASX 后缀）允许通过软管/管道连接将压力连接到设备。 顺祝商祺！ 托马斯

imx93 m33 rpmsg hello_world 测试 板/设置 CPU：i.mx93 启动媒体：SD (mmc 1) 目标：运行 CM33 RPMSG-Lite 字符串回声演示并从 Linux (A55) 进行通信 问题摘要我也想启动 Cortex-M33 RPMSG 演示： ： 当尝试访问某些 CM33 别名地址（例如0x1ffe0000 / 0x0ffc0000) Linux remoteproc 试图加载 rpmsg_lite_str_echo_rtos_remote.bin，但以错误 -2 失败（未找到文件），然后退回到 sysfs 回退。 我不确定 i.MX93 上的 CM33 的正确内存复制地址和启动地址应该是多少（系统地址与别名地址），以及如何使 U‑Boot boot bootaux 流程与 Linux remoteproc 流程保持一致。 我测试的 SD 分区布局和启动文件 U‑Boot 显示 SD 是 mmc 1： u-boot= > mmc 列表 FSL_SDHC：0 (eMMC) FSL_SDHC：1 (SD) 分区表： u-boot= > 零件清单 mmc 1 MMC 设备 1 的分区图-分区类型：DOS 部件起始扇区号扇区 UUID 类型 1 16384 681574 076c4a2a-01 0c 启动 2 704512 5769534 076c4a2a-02 83 启动分区内容包括 DTB 和 mcore-demos/ 目录： u-boot= > fatls mmc 1:1... mcore-demo/... 我可以加载演示版： u-boot= > fatload mmc 1:1 ${loadaddr} mcore-demos/rpmsg_lite_str_echo_rtos_remote.bin 3 毫秒内读取 39004 字节 u-boot= > echo ${loadaddr} 0x80 400000 u-boot= > echo ${filesize} 985c 前两个字看起来像一个有效的 CM33 向量表： u-boot= > md.l ${loadaddr} 2 80400000：2001e000 0ffe0595 读取 0x1ffe0000 会导致中止： Linux 端：remoteproc 固件加载失败 在 Linux 中，remoteproc0 开机后会尝试加载固件： [ 84.714629] remoteproc remoteproc0: powering up imx-rproc [ 84.721926] remoteproc remoteproc0: Direct firmware load for rpmsg_lite_str_echo_rtos_remote.bin failed with error -2 [ 84.732549] remoteproc remoteproc0: Falling back to sysfs fallback for: rpmsg_lite_str_echo_rtos_remote.bin 这里是预留内存： reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; linux,cma { compatible = "shared-dma-pool"; reg = <0 0x88000000 0 0x04000000>; /* 64 MB @ 0x8800_0000 */ reusable; linux,cma-default; }; /* Ethos-U: move away from the kernel boot (32 MB) */ ethosu_mem: ethosu_region@8c000000 { compatible = "shared-dma-pool"; reg = <0 0x8c000000 0 0x02000000>; no-map; }; vdev0vring0: vdev0vring0@84000000 { reg = <0 0x84000000 0 0x00008000>; no-map; }; vdev0vring1: vdev0vring1@84008000 { reg = <0 0x84008000 0 0x00008000>; no-map; }; vdev1vring0: vdev1vring0@84010000 { reg = <0 0x84010000 0 0x00008000>; no-map; }; vdev1vring1: vdev1vring1@84018000 { reg = <0 0x84018000 0 0x00008000>; no-map; }; rsc_table: rsc-table@2021e000 { reg = <0 0x2021e000 0 0x00001000>; no-map; }; /* OCRAM */ vdevbuffer: vdevbuffer@84020000 { compatible = "shared-dma-pool"; reg = <0 0x84020000 0 0x00100000>; /* 1 MB */ no-map; }; ele_reserved: ele-reserved@90000000 { compatible = "shared-dma-pool"; reg = <0 0x90000000 0 0x00100000>; /* 1 MB @ 0x9000_0000 */ no-map; }; }; ethosu { compatible = "arm,ethosu"; fsl,cm33-proc = <&cm33>; memory-region = <&ethosu_mem>; power-domains = <&mlmix>; }; 从 U-Boot 在 i.MX93 上启动 CM33 RPMsg 演示的正确步骤是什么？ 如果 CM33 由 U-Boot (bootaux) 启动，建议的 Linux 配置是什么？ Re: imx93 m33 rpmsg hello_world test 你好，电路板支持包 版本是 VERSION= " 6.6-scarthgap(scarthgap)" 我使用内存为 512MB 的 imx93 自定义板但没有 hello_world .elf 这些都在 /lib/firmware 下 imx93-11x11-evk_m33_TCM_low_power_wakeword.elf imx93-11x11-evk_m33_TCM_power_mode_switch.elf imx93-11x11-evk_m33_TCM_rpmsg_lite_pingpong_rtos_linux_remote.elf imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf imx93-11x11-evk_m33_tcm_sai_low_power_audio.elf 经过测试 u-boot= > fatload mmc 1:1 80000000 mcore-demos/rpmsg_lite_str_echo_rtos_remote.bin 在 3 毫秒内读取 39004 字节 (12.4 MiB/s) u-boot= > cp.b 0x80000000 0x201e0000 0x10000 u-boot= > bootaux 0x1ffe0000 0 ## 启动辅助内核 addr = 0x1ffe0000... 它无法启动，它会冻结。 Re: imx93 m33 rpmsg hello_world test 您好， 感谢您对恩智浦半导体产品的关注， 使用预建的 Cortex-M 演示版是一个很好的起点，你使用的是 i.MX 93 EVK 还是带有预建映像的自定义板？ 你在用什么电路板支持包？ 要在 u-boot 中运行 Cortex-M 演示，你可以使用以下代码片段： u-boot=> fatload mmc 1:1 80000000 sdk20-app.bin u-boot=> cp.b 0x80000000 0x201e0000 0x10000 u-boot=> bootaux 0x1ffe0000 0 RPMSG 必须在 Linux RPROC 框架下运行，因为您必须在 DTB 中为 RPMSG 预留内存，而且 Cortex-A RPMSG 通信是通过 Linux 驱动程序进行的。 root@imx93evk:~# echo hello_world.elf > /sys/class/remoteproc/remoteproc0/ firmware root@imx93evk:~# echo start > /sys/class/remoteproc/remoteproc0/state 此致 Re: imx93 m33 rpmsg hello_world test 你好，@bora、 请尝试使用 imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf 这是你正在测试的二进制文件，请参阅 SDK 中的可用示例： SDK_24_12_00_MCIMX93-EVK\板\mcimx93evk\多核_示例 - rpmsg_lite_pingpong_rtos_linux - rpmsg_lite_str_echo_rtos 此致 Re: imx93 m33 rpmsg hello_world test 您好， 我试过了结果就是这样， root @imx93 -11x11-lpddr4x-evk：~# echo start > /sys/class/remoteproc/remoteproc0/state [105.274513] remoteproc remoteproc remoteproc 0/state [105.274513] remoteproc remoteproc remoteproc 0/state [105.274513] remoteproc remoteproc remoteproc 0：启动 imx93-11x11-EVKK _m33_tcm_rpmsg_lite_str_echo_ rtos.elf， size 59028 [ 105.294019] remoteproc remoteproc0: Registered carveout doesn't fit len request [ 105.301405] rproc-virtio: probe of rproc-virtio.1.auto失败，错误 -12 [ 105.309101] remoteproc remoteproc0: 注册的分割不适合 len 请求 [ 105.316561] rproc-virtio: probe of rproc-virtio.2.auto failed with error -12 [ 105.830361] remoteproc remoteproc0: 远程处理器 imx-rproc 现在已启动 Re: imx93 m33 rpmsg hello_world test 您好， 我可以在 LF-6.12.49 EVK 上通过以下步骤重现该功能 Cortex-A U-启动 Hit any key to stop autoboot: 0 u-boot=> fatload mmc 0:1 ${loadaddr} mcore-demos/imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.bin 19816 bytes read in 18 ms (1 MiB/s) u-boot=> cp.b ${loadaddr} 0x201e0000 0x20000 u-boot=> bootaux 0x1ffe0000 0 ## Starting auxiliary core addr = 0x1FFE0000... u-boot=> pri mmcargs mmcargs=setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot} u-boot=> editenv m mfgtool_args mmcargs mmcautodetect mmcboot mmcdev mmcpart mmcroot u-boot=> editenv mmcargs edit: setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot} clk_ignore_unused u-boot=> boot Cortex-A Linux root@imx93evk:~# lsmod | grep -i imx_rpmsg_tty root@imx93evk:~# modprobe imx_rpmsg_tty 从 U-boot 到 Linux 的 Cortex-M RPMSG String Echo FreeRTOS RTOS API Demo... Nameservice sent, ready for incoming messages... Get Message From Master Side : "hello world!" [len : 12] 此致 Re: imx93 m33 rpmsg hello_world test 我也进行了测试，但没有结果，我仍然无法与 m33 通信。我用的是自定义板而不是 imx93-11x11-evk，我用 uart1 没有 uart2，对于 m33 我有 JTAG。 Re: imx93 m33 rpmsg hello_world test 我也没有在 /dev 下看到任何 ttyRPMSG 文件 Re: imx93 m33 rpmsg hello_world test 在 u-boot 上我开始工作了但是在 linux 中是通过 .elf文件，我得到 imx_rproc_kick：失败 (0, err:-62)

ICODE SLIタグはwrite_single_blockコマンドに対して64 01エラーを返します 私は Windows 11 ノートPCと ACS ACR1552 リーダーを使用しています。 ACS スクリプト ツール (v5.02) を使用して、APDU を NXP ICODE SLI タグに送信しています。 透過セッションを作成し、プロトコルを 15693/Layer3 に設定し、透過交換カプセル化を使用して APDU をタグに送信します。 GET_SYSTEM_INFO と READ_SINGLE_BLOCK は正常に動作するようです。 WRITE_SINGLE_BLOCK は「64 01」エラーを返しますが、実際にデータを書き込んでいるように見えます。 この 64 01 応答の意味や原因に関する情報は見つかりませんでした。 誰かこれについて説明できますか? 私が使用している APDU のシーケンスは次のとおりです。 APDU #4はブロック0のデータを11 22 33 44として読み取ります。 APDU #5はブロック0のデータを12 34 56 78に書き込みますが、64 01エラーが発生します。 APDU #6 はブロック 0 のデータを 12 34 56 78 として読み取ります。これは、前の書き込みが実際に機能したことを示しています。 （１）透過的なセッションを確立する < FF C2 00 00 02 81 00 00 > C0 03 00 90 00 90 00 ; （2）透過的な交換 - スイッチプロトコルをSwitchProtocolRf::ISO15693 SwitchProtocolLayer::PART3へ < FF C2 00 02 04 8F 02 02 03 > C0 03 00 90 00 8F 01 00 90 00 ; （3）システム情報を取得する < FF C2 00 01 04 95 02 02 2B 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 0F 00 0F 2E 98 5C 8A 00 01 04 E0 00 00 1B 03 01 90 00 ; （4）セキュリティステータスを含むユーザーブロック0の読み取り < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 06 00 00 00 11 22 33 90 00 （５）ブロック０に１２３４５６７８を書き込む < FF C2 00 01 09 95 07 02 21 00 12 34 56 78 00 > C0 03 01 64 01 90 00 ; （6）セキュリティステータス付きユーザーブロック0の読み取り < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 06 00 00 12 34 56 78 90 00 （７）透過セッションを終了する < FF C2 00 00 02 82 00 00 > C0 03 00 90 00 90 00 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command icode SLIX/SLIX2 タグの読み取り/書き込み時にもまったく同じ問題が発生しました。書き込みは機能していましたが、64 01 タイムアウトが発生しました。 書き込みと同じトランザクション内にタイマー オプションを含めることで、コマンドのタイムアウトを調整することで、この問題を解決できました。 例: ブロック0に「00 01 02 03」を書き込む > ff c2 00 01 10 5f 46 04 40 42 0f 00 95 07 02 21 00 00 01 02 03 00 透過コマンド コマンドのサイズ（0x10 = 16バイトが続く） タイムアウトコマンド デバイスへのコマンド ご覧のとおり、応答は正しくなりました。 このコマンドは、基本的に元の投稿者の質問に示されているものと同じですが、緑のセクションが追加されています。ドキュメントに従って、1 秒のタイムアウトを設定します (これはおそらく過剰です)。 5f 46 = タイマーデータオブジェクト 04 = 長さ 40 42 0f 00 = 1,000,000 (マイクロ秒、LSBが先頭)、つまり 000f4240h = 1,000,000 おそらく元の投稿者にとっては役に立たないかもしれませんが、これによって私が費やした 2 ～ 3 時間を他の誰かが節約できるかもしれません。 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command ありがとう@jimmychan 。はい、6401 を含むエラー コードと説明のリストを確認しました。元の投稿に記載した APDU シーケンスを考慮して、このエラーの原因を理解しようとしています。   タグがユーザーメモリへの単一ブロック書き込みコマンドに応答しない理由をご存知ですか?私が考えた例としては、書き込み操作にリーダーが待機している時間よりも時間がかかる可能性があるということです。リーダーをより長く待機するように設定してみましたが、これまでのところ、この方法で問題を解決することはできませんでした。また、SLI または DNA の仕様書にはこれに関する言及がないので、これが問題であるとは思えません。   繰り返しになりますが、タグが応答しない理由を理解するためのご助力いただければ幸いです。   ありがとう - ドリュー Re: ICODE SLI tag returns a 64 01 error for a write_single_block command リファレンス・マニュアル REF-ACR1552U-Series-1.06.pdf を確認してください。43ページ。 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command こんにちは@jimmychan - リーダーのドキュメントを読みました。そのドキュメントから、私が使用しているコマンド構文を取得しました。私の知る限り、コマンド構文は正しいです。6401 エラーはリーダーから発生しているということですか?ドキュメントの中で、特に確認すべき部分はありますか? ご協力に感謝します。 ドリュー Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 読者の方はドキュメントをお読みください。 ACR1552U - USB NFCリーダ IV | ACS

ICODE SLI 标签在执行 write_single_block 命令时返回 64 01 错误 我使用的是 Windows 11 笔记本电脑和 ACS ACR1552 阅读器。 我正在使用 ACS 脚本工具（v5.02）向恩智浦 ICODE SLI 标签发送 APDU。 我正在创建一个透明会话，将协议设置为 15693/Layer3，然后使用透明交换封装向标签发送 APDU。 GET_SYSTEM_INFO 和 READ_SINGLE_BLOCK 似乎工作正常。 WRITE_SINGLE_BLOCK 返回"64 01" 错误，但似乎确实写入了数据。 我没有找到任何关于 64 01 响应的含义或原因的信息。 有谁能对此提供一些信息？ 以下是我正在处理的 APDU 序列。 APDU #4 读取数据块 0 的数据为 11 22 33 44 APDU #5 将数据块 0 的数据写入 12 34 56 78 - 但收到 64 01 错误 APDU #6 读取的 0 号数据块数据为 12 34 56 78 --这说明之前的写入实际上起了作用？ ; (1) 建立透明会话 < FF C2 00 00 02 81 00 00 > C0 03 00 90 00 90 00 ; (2) 透明交换 - 将协议切换到 SwitchProtocolRf::ISO15693 SwitchProtocolLayer::PART3 < FF C2 00 02 04 8F 02 02 03 > C0 03 00 90 00 8F 01 00 90 00 ; (3) get sys info < FF C2 00 01 04 95 02 02 2B 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 0F 00 0F 2E 98 5C 8A 00 01 04 E0 00 00 1B 03 01 90 00 ; (4) 读取具有安全状态的用户屏蔽 0 < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 92 01 00 96 02 00 00 97 06 00 00 00 00 97 06 00 00 00 11 22 33 90 00 ; (5) 用 12 34 56 78 < FF C2 00 01 09 95 07 02 21 0012 34 56 7800 > C0 03 01 64 01 90 00 ; (6) 读取具有网络安全状态的用户屏蔽 0 < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 92 01 00 96 02 00 00 97 06 00 00 97 06 00 00 12 34 56 78 90 00 ; (7) 结束透明会话 < FF C2 00 00 02 82 00 00 > C0 03 00 90 00 90 00 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 我在读取/写入 icode SLIX/SLIX2 标签时也遇到了同样的问题，写入正常，但出现了 64 01 超时。 我通过在写入的同一事务中加入计时器选项，调整命令的超时时间，从而解决了这个问题。 例如将"00 01 02 03" 写入 0 号区块 > FF C2 00 01 10 5F 46 04 40 42 0F 00 95 07 02 21 00 01 02 0300 透明命令 命令 大小（0x10 = 接下来是 16 字节） 超时 命令 到 设备 可以看出，现在答案是正确的。 该命令与原作者问题中的命令基本相同，只是增加了绿色部分，根据文档，该部分设置了 1 秒超时（可能过长）。 5f 46 = 计时器数据对象 04 = 长度 40 42 0f 00 = 1,000,000（微秒，LSB 优先），即 000f4240h = 1,000,000 可能太晚了，对最初的发帖人没用，但也许这能帮其他人省下我花费的两三个小时。 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 谢谢@jimmychan。 是的，我见过错误代码和描述列表，包括 6401。 鉴于我在原帖中提供的 APDU 序列，我想弄明白是什么原因导致该错误。   您知道标签不响应向用户内存写入单块命令的原因吗？ 我想过的一个例子是，写入操作可能比读者等待的时间更长。 我曾尝试配置阅读器，让它等待更长的时间，但到目前为止，我还没能解决这个问题。 另外，我在 SLI 或 DNA 规格表中没有看到任何参考，所以我怀疑这是问题所在。   如果您能帮助我们了解标签为何没有反应，我们将再次不胜感激。   谢谢 - 德鲁 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 你可以查看参考手册 ref-ACR1552U-Series-1.06.pdf。第 43 页。 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 你好@jimmychan- 我已经阅读了阅读器的文档，这就是我使用的命令语法。据我所知，我的命令语法是正确的。你是说 6401 错误来自读卡器？您有什么具体的文件需要我查看吗？ 感谢您的帮助。 德鲁 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 请阅读读者文件。 ACR1552U - USB NFC 阅读器 IV | ACS

シングルチャネルABS SB0401監視モジュールの問題 こんにちは@nxp 、 私は SPI マスターとして NXP S32K31xEVB-Q48 MCU を搭載した SB0401 シングル チャネル ABS モジュール IC を使用しています。監視/モジュール データを 10 ミリ秒ごとに送信していますが、SB0401 監視モジュールは繰り返しリセット/再起動しているように見えます (約 50 ミリ秒ごとに 1 回)。これに伴い、SPI 転送ごとに SPI「エラー数」が増加します。 以下にセットアップと具体的な質問を示します。 ハードウェア/ソフトウェアのセットアップ MCU（SPIマスター）：S32K31xEVB-Q48（S32K31xファミリ） デバイス: SB0401 (シングルチャネルABSモジュールIC) インターフェース: SPI (LPSPI) (DMA ベースの転送) 定期送信: 10 ミリ秒ごと 観察された問題: SB0401 監視モジュールが約 50 ミリ秒ごとにリセット/再起動する (添付のログを参照) 観察された行動 エラー カウンターは、SPI バイト/ワード転送ごとに増加します。 SB0401 メッセージ 18 から AR (シード) を読み取り、その AR に基づいて MR を計算します。 定期的にフレームを送信しているにもかかわらず、SB0401 監視モジュールはリセット/再起動します。 質問 MR計算とAR計算（メッセージ18） SPI 転送ごとにエラー数が増加します。 SB0401 メッセージ 18 から受信した AR 値を使用して MR を計算します。 この状況では、転送ごとにエラー カウンターが増加することが予想されますか、それとも MR/AR ロジックが正しくないことを示しているのでしょうか。 AR (メッセージ 18) に対する正しい MR 計算フロー/タイミングと、よくある落とし穴 (古い AR の使用、間違ったバイト/ビット抽出、タイミング ウィンドウ、カウンター アライメントなど) を確認してください。 メッセージ0を書き込むときのACK位置 TxBuf[0] の メッセージ0 にデータを書き込む場合 、確認応答をどこで確認すればよいですか？ 例: TxBuf[0] への書き込みの場合 、ACKは RxBuf[0](同じワード) に表示されますか、それとも RxBuf[1](次のワード) に表示されますか? 「次の SPI ワード/フレームで ACK が発生する」というルールが定義されている場合は、正確なマッピングを共有してください。 リファレンスSW / CDDドライバ SB0401 のリファレンス CDD / サンプル ドライバ (C ソースまたは AUTOSAR スタイルの CDD 統合) があり、ガイダンスとして共有できますか? 共有できない場合は、公式の SB0401 ソフトウェア パッケージ / アプリケーション ノート / リファレンス実装の詳細を推奨していただけますか? Re: Single channel ABS SB0401 Monitoring Module Issue こんにちは@guoweisun はい、わかりました。 NXPについて: Ettiksoft technologies Pvt ltd. プロジェクト: 二輪車用シングルチャネル ABS。 Re: Single channel ABS SB0401 Monitoring Module Issue ハイ ここであなたの会社やプロジェクトの情報を表示することは可能ですか? Re: Single channel ABS SB0401 Monitoring Module Issue こんにちは@guoweisun わかりました。このモジュールの動作のような他の参照コードも存在します。 Re: Single channel ABS SB0401 Monitoring Module Issue この特殊部品に関する参照コードをもう一度確認してみましょう。 Re: Single channel ABS SB0401 Monitoring Module Issue この部品には CDD やその他のソフトウェア ドライブがないため、参照回路図もお客様が NDA に署名してから共有する必要があります。 Re: Single channel ABS SB0401 Monitoring Module Issue ここに投稿できないサンプルコードについては、CASEポートからチケットを送信していただけますか? 家庭用

FTM 定时器混乱 我试图启动 FTM0/FTM1 定时器，但在运行定时器代码时却出现了 HardFault 故障，为什么？ 无法运行的代码 #include "MKE02Z4.h" /* ================= GLOBALS ================= */ volatile uint8_t uartFlag = 0; /* ================= PROTOTYPES ================= */ void init_clock(void); void init_uart0(void); void init_FTM1(void); void UART_Send(const char *s); /* ================= FTM1 ISR ================= */ void FTM1_IRQHandler(void) { /* Clear overflow flag (write 0 while set) */ FTM1->SC &= ~FTM_SC_TOF_MASK; uartFlag = 1; } /* ================= MAIN ================= */ int main(void) { init_clock(); init_uart0(); init_FTM1(); UART_Send("FTM1 Initialized\r\n"); while (1) { if (uartFlag) { uartFlag = 0; UART_Send("A\r\n"); } __WFI(); /* wait for interrupt */ } } /* ================= CLOCK INIT ================= */ void init_clock(void) { /* * Assume internal clock already configured by SDK startup * Bus clock = 32 MHz */ SIM->BUSDIV = 0x01; /* divide by 1 */ } /* ================= UART0 INIT ================= */ void init_uart0(void) { /* Enable UART0 clock */ SIM->SCGC |= SIM_SCGC_UART0_MASK; /* UART0 pin select (TX/RX) */ SIM->PINSEL |= SIM_PINSEL_UART0PS_MASK; /* Disable TX inversion (important!) */ SIM->SOPT &= ~SIM_SOPT_TXDME_MASK; /* * 9600 baud @ 32 MHz * SBR = 32e6 / (16 * 9600) ≈ 208 */ UART0->BDH = 0x00; UART0->BDL = 53; UART0->C1 = 0x00; UART0->C2 = UART_C2_TE_MASK | UART_C2_RE_MASK; } /* ================= FTM1 INIT ================= */ void init_FTM1(void) { /* Enable FTM1 clock */ SIM->SCGC |= SIM_SCGC_FTM1_MASK; __DSB(); /* ---- VERY IMPORTANT ORDER (KE02 SAFE) ---- */ /* Stop counter completely */ FTM1->SC = 0; /* Disable write protection (WRITE ONCE) */ FTM1->MODE = FTM_MODE_WPDIS_MASK; /* Reset counter */ FTM1->CNTIN = 0; FTM1->CNT = 0; /* * 32 MHz / 128 = 250 kHz * 250000 ticks = 1 second */ FTM1->MOD = 249999; /* Enable overflow interrupt, prescaler = 128 */ FTM1->SC = FTM_SC_PS(7) | FTM_SC_TOIE_MASK; /* Enable NVIC */ NVIC_EnableIRQ(FTM1_IRQn); /* START TIMER (LAST STEP ONLY) */ FTM1->SC |= FTM_SC_CLKS(1); } /* ================= UART SEND ================= */ void UART_Send(const char *s) { while (*s) { while (!(UART0->S1 & UART_S1_TDRE_MASK)); UART0->D = *s++; } } 工作代码 #include "MKE02Z4.h" /* ================= GLOBALS ================= */ volatile uint8_t uartFlag = 0; /* ================= PROTOTYPES ================= */ void init_clock(void); void init_uart0(void); void init_FTM2(void); void UART_Send(const char *s); /* ================= FTM2 ISR ================= */ void FTM2_IRQHandler(void) { /* Clear overflow flag (write 0 while set) */ FTM2->SC &= ~FTM_SC_TOF_MASK; uartFlag = 1; } /* ================= MAIN ================= */ int main(void) { init_clock(); init_uart0(); init_FTM2(); UART_Send("FTM2 Initialized\r\n"); while (1) { if (uartFlag) { uartFlag = 0; UART_Send("A\r\n"); } __WFI(); /* wait for interrupt */ } } /* ================= CLOCK INIT ================= */ void init_clock(void) { /* * Assume internal clock already configured by SDK startup * Bus clock = 32 MHz */ SIM->BUSDIV = 0x01; /* divide by 1 */ } /* ================= UART0 INIT ================= */ void init_uart0(void) { /* Enable UART0 clock */ SIM->SCGC |= SIM_SCGC_UART0_MASK; /* UART0 pin select (TX/RX) */ SIM->PINSEL |= SIM_PINSEL_UART0PS_MASK; /* Disable TX inversion (important!) */ SIM->SOPT &= ~SIM_SOPT_TXDME_MASK; /* * 9600 baud @ 32 MHz * SBR = 32e6 / (16 * 9600) ≈ 208 */ UART0->BDH = 0x00; UART0->BDL = 53; UART0->C1 = 0x00; UART0->C2 = UART_C2_TE_MASK | UART_C2_RE_MASK; } /* ================= FTM2 INIT ================= */ void init_FTM2(void) { /* Enable FTM2 clock */ SIM->SCGC |= SIM_SCGC_FTM2_MASK; __DSB(); /* ---- VERY IMPORTANT ORDER (KE02 SAFE) ---- */ /* Stop counter completely */ FTM2->SC = 0; /* Disable write protection (WRITE ONCE) */ FTM2->MODE = FTM_MODE_WPDIS_MASK; /* Reset counter */ FTM2->CNTIN = 0; FTM2->CNT = 0; /* * 32 MHz / 128 = 250 kHz * 250000 ticks = 1 second */ FTM2->MOD = 249999; /* Enable overflow interrupt, prescaler = 128 */ FTM2->SC = FTM_SC_PS(7) | FTM_SC_TOIE_MASK; /* Enable NVIC */ NVIC_EnableIRQ(FTM2_IRQn); /* START TIMER (LAST STEP ONLY) */ FTM2->SC |= FTM_SC_CLKS(1); } /* ================= UART SEND ================= */ void UART_Send(const char *s) { while (*s) { while (!(UART0->S1 & UART_S1_TDRE_MASK)); UART0->D = *s++; } }   Re: FTM Timer Confusion 你好@Jana_muralidharan 请调试检查 FTM1 时钟是否启用，并验证计数寄存器是否正常工作。   BR 爱丽丝 Re: FTM Timer Confusion 实际上，我发现了错误 这是因为我使用了仅适用于 FTM2 的寄存器、 因此，在删除不需要的寄存器后，它就能正常工作了。 我发现HardFault Error 只有在以下情况下才会发生、 我们使用了原本不存在的寄存器。 嘿，感谢您对这个问题的关注，谢谢.....。

8x DPDMUXで静的DPLをロードできませんでした こんにちは、コミュニティの皆様 DPDMUX と DPNI の動的作成を正常に使用し、次のコマンドで DPL を生成します。 8x ls-addni --fs-entries=8 --num-queues=8 -n ソース /usr/local/dpdk/dpaa2/dynamic_dpl.sh ... 8x restool dpdmux create 8x restool dprc connect dprc.1 --endpoint1= .n.0/1/2 --endpoint2= / /dpni.k> dprc を復元して、dpl dprc.1 > dpl-8-dpdmux.dts を生成 uboot が MC レイアウトを開始できるように、静的 DPL を dpl-8-dpdmux.dtb (dtc ツールによって生成) で更新します。 エラーは次のように表示されます: [E, mem_mng_get_phys_mem:655] メジャー メモリ。マネージャーのメモリ割り当てに失敗しました [E, mem_mng_get_phys_mem:658] 必要なサイズ 0x000040000、アライメント 0x000000100 は、パーティション ID 7 の使用可能なメモリを超えています [E, init_bman_bp:399, DPDMUX] ID[6] - dpbp_allocate_buffers()、dpbpバッファの割り当てに失敗しました [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp : -12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure: -12 [E, mem_mng_get_phys_mem:655] メジャー メモリ。マネージャーのメモリ割り当てに失敗しました [E, mem_mng_get_phys_mem:658] 必要なサイズ 0x000040000、アライメント 0x000000100 は、パーティション ID 7 の使用可能なメモリを超えています [E, init_bman_bp:399, DPDMUX] ID[7] - dpbp_allocate_buffers()、dpbpバッファの割り当てに失敗しました [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp : -12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure: -12 [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@6 と dpmac@9 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。dpl プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@6 と dpni@15 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@6 と dpni@7 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@7 と dpmac@10 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。dpl プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@7 と dpni@16 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。dpl プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@7 と dpni@8 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。プロセッシングを続行します... [E, dpl_process:527] 「接続」の解析中にエラーが発生しました。DPL の残りのプロセッシングをスキップします。 [E、メイン:198] DPL プロセッシングに失敗しました。続行中... 動的な方法と同じレイアウトをサポートするために、静的 DPL には何か制限がありますか? QorIQ LS2デバイス Re: Failed to load static DPL with 8x DPDMUX こんにちは、イーピンワンさん 動的レイアウト作成で '--max-dmat-entries' を使用すると、 'restool dprc generate-dpl dprc.1' によって最終的な dts は変更されません。 SO、.dts に次の要素「mem-size」と「 max-dmat-entries」を追加して試してみます。手動で: dpdmux@0 { 互換性 = "fsl,dpdmux"; オプション = "DPDMUX_OPT_CLS_MASK_SUPPORT", "DPDMUX_OPT_AUTO_MAX_FRAME_LEN"; 方法 = "DPDMUX_METHOD_CUSTOM"; マニピュレータ = "DPDMUX_MANIP_NONE"; num_ifs = <0x2>; mem-size = <0x100>; // これは私が手動で追加したものです max-dmat-entries = <0x8>; // これは私が手動で追加したものです }; 残念ながら、これでは問題は解決せず、MC デバッグから同じエラー メッセージが表示されます。 同封の私のDPLもご確認ください。 Re: Failed to load static DPL with 8x DPDMUX 以下の方法が出来るかお試しください。 DPDMUX を作成するときは、リソース割り当てを減らすために「--max-dmat-entries=8」を指定してください。 --max-dmat-entries= DPDMUX アドレス テーブルの最大エントリ数。デフォルトは 64 です。 問題が解決しない場合は、コンソール ログ全体を共有して DPDMUX を作成し、DPL ファイルを生成します。 また、どのプロセッサを使用していますか? Re: Failed to load static DPL with 8x DPDMUX こんにちは、 DPL パラメータ名を修正することでこの問題を解決できました。

bl2でのseclogging こんにちは、 A-core (BSP43) に安全なログ記録を実装しようとしています。目標は、セキュア ブートの失敗、Wi-Fi/TLS の失敗など、セキュリティ関連の失敗を記録することです。 現在、BL2 ステージでのセキュア ブートの失敗を記録しようとしています。私の最初のアプローチは、これらのログを NOR フラッシュに直接書き込み、HSE を使用して暗号化することでした。ただし、S32G の BL2 レベルでは次の制限に遭遇しています。 BL2 には、NOR フラッシュの読み取りや書き込みに使用できる定義済み API はありません。 BL2 ステージでは永続的または追加形式のログ記録を実装することはできません。 これらの制約のため、このようなセキュア ブートの失敗ログを、後でLinuxからアクセスできるようにBL2のどこにどのように保存すればよいかはわかりません。 Wi-Fi および TLS 関連の障害については、Linux レベルで NetworkManager ベースのログを使用する予定です。 BL2 に起因するセキュア ブートの失敗をログに記録するための実行可能なアプローチについてアドバイスをいただけませんか。また、このシナリオで安全にログに記録するための推奨メカニズムを提案していただけますか。 Re: seclogging at bl2 こんにちは、 @Jayashree ご投稿ありがとうございます。 これはユーザー定義のソフトウェア実装であり、このようなトピックに関して当社側から正式な推奨がないことを残念に思います。 BL2 ステージに記録されたセキュア ブートの失敗に関しては、BL2 が BL3x バイナリの認証に失敗し、関連情報を記録したいということでしょうか? 私の経験からすると、上記のログはコンソールから見つけることができます。それらを QSPI に保存したい場合は、BL2 が QSPI からイメージをロードして DDR に格納し、QSPI にアクセスできるようになるため、関連するコード/API をチェックして、要件を満たすことができるかどうかを確認していただけますか? BR チェイン Re: seclogging at bl2 こんにちは、Chenyinさん ご提案に従って、BL2 の MMIO 読み取り/書き込み API を使用しようとしましたが、API 呼び出しの直後にブート プロセスが停止するようです。 FSPI 読み取り/書き込み API の使用も試みましたが、この場合、Yocto ビルド自体を完了できません。 セキュア ブートが有効な場合、BL2 からの読み取り/書き込みアクセスがサポートされているかどうかを確認してください。サポートされている場合、このCASEに推奨されるAPIを教えていただけますか?あるいは、BL2 からのログ記録やデータの永続化に関して実行可能なアプローチや推奨される代替方法についてご指導いただければ幸いです。 よろしくお願いします、 ジャヤシュリー  

LVGL基准测试性能优化   1 背景 2 开发设置 2.1 软件 2.2 硬件 3 性能优化 3.1 基准性能 3.2 优化 1：编译器优化 3.3 优化 2：外部同步动态随机存取存储器(SDRAM) 3.4 优化 3：VGLite 加速 3.5 优化比较 4 结论 5 参考 1. 背景 LVGL（轻量级通用图形库）是一个高性能、低资源的嵌入式图形库。由于其强大的开源生态系统和广泛的操作系统兼容性，它支持从低功耗的 ARM Cortex-M 微控制器（时钟速度低至 100 MHz）到运行 Linux 的高性能 MPU 的各种硬件平台，使其成为嵌入式开源解决方案的首选。许多芯片供应商现在提供对 LVGL 的“开箱即用”支持。 NXP 为其主流平台（包括 MCX、i.MX RT 和 LPC 系列）提供了现成的软硬件示例，并将 LVGL 示例集成到 MCUXpresso SDK。这些示例包含不同场景下的量化基准指标。然而，由于软硬件配置和规格存在差异，实际性能可能会显著不同，通常需要针对具体场景进行调优。 本文档基于 i.MX RT1170 平台的实际经验，旨在帮助 NXP 用户快速掌握并应用合适的优化策略，以提升 LVGL 应用性能。 @Smartling Language Service   4. 结论 本文档对 NXP 官方 LVGL 基准测试示例进行了逐步优化，并在 CPU 使用率、FPS、渲染时间和刷新时间方面进行了量化提升。以Widgets 演示为例： CPU使用率从96%→12%下降 FPS 从 2 提升至 59 这些优化技术（不仅限于 LVGL）广泛适用于 i.MX RT 平台上的系统级性能调优。

如何将 i.MX93 Cortex-M33 板和 SDK 导入 MCUXpresso IDE？ 📌 背景： 我想开始使用 MCUXpresso IDE 在 i.MX93 Cortex-M33 (MCIMX93-EVK) 板上进行开发。我已经从恩智浦网站下载了SDK ZIP，但我无法成功导入板或使用其示例。 🛠️ 我做了什么？ 从 mcuxpresso.nxp.com 下载 SDK ZIP： SDK_25_03_00_MCIMX93-EVK.zip 已打开MCUXpresso 集成开发环境（版本：请在此注明） 去了 已安装的 SDK> Import → 选择 ZIP 文件 SDK 出现在集成开发环境的已安装 SDK 下。 但是，当我进入 “导入SDK示例” 时，没有任何显示，或者我无法创建导入的项目的版本。 ❓ 我的问题： 将 i.MX93 Cortex-M33 板和 SDK 导入 MCUXpresso IDE 的正确和完整程序是什么，这样我就可以： 查看支持的板 访问演示/示例应用程序（如 hello_world） 无错误地版本和调试项目 🔍 其他说明： 我的目标是 i.MX93 的Cortex-M33 内核 我只想使用MCUXpresso 集成开发环境（而不是 IAR 或 VS Code）。 🧪 预期成果： 能够使用 MCUXpresso IDE 在 MCIMX93-EVK 板上导入和版本 cm33_core0 的 hello_world 或 led_blinky 等示例项目。 如果需要其他工具或配置，请告诉我。预先表示感谢！ i.MX93EVK#i.mx93 cortex-m33i.MX93#MCUXpressoIDE ##MCUXpressoSDK Re: How to Import i.MX93 Cortex-M33 Board and SDK into MCUXpresso IDE? 你好@Manjunathb 我目前也在使用i.MX93 Cortex-M33。我安装了 MCUXpresso 集成开发环境，但在将 SDK 压缩文件下放到已安装的 SDK 视图时遇到了错误（根据指南）。 了解到您也在研究相同的 M33 核心，您是否介意与我们分享任何信息以及您目前的进展情况？我还应该为 VS 代码使用 MCUXpresso 吗？ 如果您能分享一些关于如何开始 M33 开发的指南或程序，我将不胜感激。谢谢。 Re: How to Import i.MX93 Cortex-M33 Board and SDK into MCUXpresso IDE? 你好 Chavira， 我目前正在使用 i.MX93 Cortex-M33 内核，我知道这款设备不支持 MCUXpresso IDE，但推荐使用适用于 VS Code 的 MCUXpresso IDE。 我已经安装了：适用于 VS Code 扩展 的 mcuxPresso i.MX93 SDK 包 ARM GCC 工具链 而且我正在使用 J-Link 调试器。 请就以下几点为我提供指导： 如何将 i.MX93 Cortex-M33 SDK 正确导入 VS 代码？SDK 文件应放在哪里，扩展程序如何检测它们？ 如何创建或打开 Cortex-M33 演示或模板项目（如 hello_world 或 led_blinky）？ 如何配置版本设置（编译器、链接器路径等），以便使用 MCUXpresso VS Code 环境成功编译？ 使用 J-Link 探头或 remoteproc（如果使用 Linux）闪存和调试已编译应用程序的正确方法是什么？ 在使用 MCUXpresso for VS Code 时，是否有 i.MX93 特有的已知限制或额外步骤？ 如果能提供完整的分步说明或相关文档链接，我将不胜感激。预先感谢您的支持！ 最崇高的敬意， Manjunath Badiger Re: How to Import i.MX93 Cortex-M33 Board and SDK into MCUXpresso IDE? 好的 👍 感谢您的回复 Re: How to Import i.MX93 Cortex-M33 Board and SDK into MCUXpresso IDE? 嗨，@Manjunathb！ 感谢您联系恩智浦支持中心！ 遗憾的是，MCUXpresso IDE 与这种情况不兼容。不过，您也可以使用 MCUXpresso for VS Code，它支持并提供类似的功能。 致以最崇高的敬意， Chavira

YouTube 视频：“试用电压电平转换器评估板：NTS0304EUK-ARD”（日本博客）已发布 双向电压电平转换器评估板： 视频“如何使用NTS0304EUK-ARD ”现已在NXP YouTube频道上线↓↓   电压电平转换器：NTS0304E NTS0304E是一款 4 位双电压转换收发器，具有自动方向检测功能，可实现双向电压电平转换。 低压侧（A侧）可转换0.95V至3.6V之间的信号电压，高压侧（B侧）可转换1.65V至5.5V之间的信号电压。由于它可以自动控制双向信号，因此也可用于I²C等信号。 评估板：NTS0304EUK-ARD NTS0304EUK-ARD是这款芯片的评估板。它是一款 Arduino 扩展板，包含 NTS0304E 芯片、一个 I²C/SPI 目标设备和两个 LDO（低压差线性稳压器）。该评估板可用于在各种带有 Arduino 扩展板兼容接口的微控制器板上测试 NTS0304E 的电压转换性能。   视频：“如何操作 NTS0304EUK-ARD ” 本视频展示了使用开源示例代码在三种类型的微控制器上进行演示的操作。 首先， MCUXpresso IDE 和FRDM-MCXN236的组合 接下来，我们来看一个在i.MX RT1050上运行MicroPython的示例。 最后，采用Arduino UNO R3 的方法 你可以在这里看到。 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问，请参阅“ NXP技术问题-如何联系我们（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接询问负责人。） 双向电压电平转换器评估板：已发布题为“如何使用 NTS0304EUK-ARD ”的视频。 NTS0304E 是一款 4 位双电压转换 收发器 ，具有自动方向检测功能，可实现双向电压电平转换 。 i.MX RT 处理器 界面 介绍 MCUXpresso MCUXpresso IDE 日本博客

使用 J-Link 与 MIMXRT1170-EVKB 注意：有关类似的 EVK，请参阅： 使用 J-Link 与 MIMXRT1060-EVKB 或 MIMXRT1040-EVK 使用 J-Link 与 MIMXRT1060-EVK 或 MIMXRT1064-EVK 使用 J-Link 与 MIMXRT1160-EVK 或 MIMXRT1170-EVK 本文介绍了在该 EVK 上使用 J-Link 调试探针的详细方法。有两种方式：将板载 MCU-Link 调试探针更新为 Segger J-Link 固件，或将外部 J-Link 调试探针连接到 EVK。使用板载调试电路可免去对额外调试探针的需求。本文将详细介绍上述任一 J-Link 方式的使用步骤。 MIMXRT1170-EVKB jumper locationsMIMXRT1170-EVKB 跳线位置 使用外部 J-Link 调试探针 Segger 提供多种J-Link 探针选项。要使用这些探针配合这些 EVK，请按以下配置设置 EVK： 在JP5上安装一个跳线，以断开 SWD 信号与板载调试电路的连接。默认情况下，此跳线处于断开状态。 为EVK供电：默认选项是将电源连接到桶形插孔J43，并将电源开关SW5设置为开启位置 (3-6)。当EVK正常供电时，SW5旁边的绿色LED D16将会亮起。 将 J-Link 探头连接到 J1，20 针双排 0.1 英寸排针。 使用板载 MCU-Link 搭配 J-Link 固件 安装 MCU-Link 安装程序以获取驱动程序和固件更新工具 断开 EVK 上的所有 USB 连接线 为EVK供电：默认选项是将电源连接到桶形插孔J43，并将电源开关SW5设置为开启位置 (3-6)。当EVK正常供电时，SW5旁边的绿色LED D16将会亮起。 在 JP3 处安装跳线以强制 MCU-Link 进入 ISP 模式 将 USB 电缆连接到 J86，连接到 MCU-Link 调试器 转到 MCU-Link 软件包安装中的脚本目录，并双击运行 program_JLINK.cmd (Windows) 或 program_JLINK (Linux/MacOS) 脚本。按照屏幕上的说明操作。在 Windows 中，此脚本通常安装在 C:\nxp\MCU-LINK_installer_3.122\scripts\program_JLINK.cmd。 拔下 J86 处的 USB 线缆 移除 JP3 处的跳线 将 USB 线缆重新连接到 J86。现在，MCU-Link 调试器应以 J-Link 模式启动。 移除跳线 JP5，以连接来自 MCU-Link 调试器的 SWD 信号。默认情况下，此跳线处于断开状态。

PTN3460, PTN3460I FAQs Q1: Why DisplayPort to LVDS adapter? DPRX-LVDS is an (embedded) DisplayPort to LVDS bridge device that enables connectivity between an (embedded) DisplayPort (eDP) source and LVDS display panel. It processes the incoming DisplayPort (DP) stream, performs DP to LVDS protocol conversion and transmits processed stream in LVDS format. NXP offers two eDP-LVDS devices: 1. PTN3460 is commercial grade, 0 – 70 C. It is in 56-pin HVQFN package, 7 mm x 7 mm, 0.4 mm pitch. Supports pixel clock frequency from 25 MHz to 112 MHz. 2. PTN3460I is industrial grade, -40 – 85 C. It is in 56-pin HVQFN package, 7 mm x 7 mm, 0.4 mm pitch. Supports pixel clock frequency from 6 MHz to 112 MHz. Q2. How to configure eDP-LVDS device?   The eDP-LVDS has embedded microcontroller and on-chip Non-Volatile Memory (NVM) to allow for flexibility in firmware updates. Both PTN3460 and PTN3460I have a built in configuration table in internal 1K SRAM, which allows users to program seven EDID and 128 configuration registers through M/S I2C-bus. Please follow the programming guides below for these devices. 1. AN11128 – Programming Guide for PTN3460 2. AN11606 – Programming Guide for PTN3460I Q3. What is maximum resolution DP-LVDS can support? The available bandwidth over a 2-lane HBR DisplayPort v1.4 link limits pixel clock rate support to: 1. 1-lane DP with single LVDS bus supports 800x600 @ 60 Hz display, 40 MHz pixel clock. 2. 1-lane DP with dual LVDS bus supports 1366x768 @ 60 Hz display, 85.5 MHz pixel clock. 3. 2-lane DP with single LVDS bus operation up to 112 mega pixel per second – supports 1440x900 @ 60 Hz resolution display. 4. 2-lane DP with dual LVDS bus operation up to 224 mega pixel per second – supports 1920x1200 @ 60 Hz resolution display. Q4. How to update the FW? FW for eDP-LVDS devices can be updated by the following methods: 1. Flash over AUX (FoA) – This is an executable window utility that can only run under Windows OS. FW is updated through DP AUX channel. AN11133 – PTN3460 FoA utility user’s guide. 2. Flash over DOS (FoD) – This is an executable DOS utility that can run under DOS without OS. FW is updated through M/S I2C bus. 3. Flash over I2C – FW is updated through external I2C device that is plugged in a M/S I2C header. Q5. How to check the FW version? FW version can be read out with DPCD utility that runs under Windows OS. Please follow DPCD Tool User Manual V1.0. Q6. How many DP lanes supported in NXP DP to LVDS bridge device? NXP DP to LVDS bridge device supports 2 lanes HBR/RBR. Q7. What does HBR/RBR mean? HBR means “High Bit Rate”, it runs 2.7 Gbit/s. RBR means “Reduced Bit Rate”, it runs 1.62 Gbit/s. Q8. What is DP AUX channel? DP AUX channel is used for communication channel between DP source and DP sink device. Q9. What is DP source device? DP source device is DP signal transmitter. Q10. What is DP sink device? DP sink device is DP signal receiver.

Building AI/ML Devices at the Edge? Start with FRDM From smart sensing and anomaly detection to computer vision, voice recognition, and multimodal GenAI—AI/ML use cases are rapidly moving onto the device. But if you're an engineer getting started, the real questions usually are: What hardware products should I use? What NXP tools actually work for embedded AI applications? Do I need the cloud for anything? Let’s break it down ! Why Edge AI is important? Running AI models directly on-device enables: Real-time decisions (low latency) Better security Offline operation (no cloud dependency) Optimized power consumption That’s exactly where the FRDM development platform comes in Quick Positioning: From MCU to Edge AI Processor Category Boards AI Capability Level Typical Use Case MCU (Low Power Edge ML) FRDM-MCXA156 + ⭐ sensor AI, TinyML MCU + Neural Acceleration FRDM-MCXN947 ++ ⭐⭐ Edge AI with vision/audio, TinyML Application Processor (Entry Edge AI) FRDM-IMX93 +++ ⭐⭐⭐ HMI + AI inference High-Performance Edge AI FRDM-IMX8MPLUS ++++ ⭐⭐⭐⭐ Vision AI, Advanced HMI Next-Gen AI + Safety FRDM-IMX95 / PRO +++++ ⭐⭐⭐⭐⭐ Gen AI, Advanced Edge Computing AI/ML applications can run on general-purpose hardware, but leveraging dedicated hardware acceleration significantly improves performance, enables faster results, and reduces power consumption. Below is a reference list of FRDM development boards that support AI/ML applications, helping you choose the right platform based on your target use case   Board Positioning AI Acceleration Hardware Capabilities (AI-relevant) Best For FRDM-MCXA156 Entry-level MCU (TinyML)  No NPU (CPU-only) Sensors via Expansion headers (Arduino, MikroBUS, Pmod) Parallel display support Sensor ML Anomaly detection Basic TinyML FRDM-MCXN947 MCU with neural acceleration NPU Parallel camera interface (basic) Parallel display Audio (PDM/I2S) Voice AI  Low-res vision Object classification Anomaly Detection FRDM-IMX93 Entry Edge AI MPU NPU  MIPI CSI camera Display (MIPI DSI/LVDS) Audio + connectivity Smart HMI Light vision AI Edge gateways FRDM-IMX8MPLUS Advanced Multimedia + Edge AI platform NPU Multi-camera (MIPI CSI) High-res display (HDMI/DSI)  Audio DSP Connectivity (Wi-Fi, BLE, Ethernet) Some PCIe expansion Computer vision Object detection Industrial AI FRDM-IMX95 Next-gen AI + real-time MPU Next-gen NPU + heterogeneous compute Multi-camera pipelines Advanced HMI Industrial connectivity M.2 expansion(Up to 1 AI accelerators) Robotics Industrial AI Safety applications FRDM-IMX95-PRO Full-featured AI dev platform High-performance NPU + scalable AI (Ara240 Discrete NPU)  Multi-camera Advanced display M.2 expansion (Up to 2 AI accelerators) Advanced AI prototyping Gen AI Edge servers Edge computing  Software and tools for ML/AI applications   GoPoint GoPoint accelerates AI/ML evaluation on FRDM platforms powered by i.MX application processors by providing a ready-to-use, graphical environment with pre-integrated demos. Developers can quickly run applications such as image classification, object detection, and voice recognition directly on the hardware without complex setup. These demos are already optimized for available compute resources—including CPU, GPU, DSP, and NPU—allowing users to immediately visualize performance and understand how AI workloads map to the system. This makes GoPoint an ideal starting point for exploring edge AI capabilities and validating use cases before moving into full application development. Application Code Hub (ACH) Application Code Hub complements rapid evaluation tools by offering a centralized repository of reusable, production-oriented software examples for FRDM boards. It provides full application projects, source code, and documentation that developers can directly import into MCUXpresso IDE or VS Code. With filtering based on use case—such as vision AI, audio processing, or anomaly detection, ACH enables developers to quickly find and customize reference implementations. This helps bridge the gap between proof-of-concept and real product development, significantly reducing development time while enabling scalable AI/ML application design. Application Code Hub Guide eIQ Time Series Studio (TSS) eIQ Time Series Studio is purpose-built for developing AI models based on sensor and time-series data, making it highly relevant for FRDM-based edge intelligence applications. It provides a guided workflow for data collection, labeling, model training, and validation, all optimized for MCU-class devices. Developers can easily transform raw sensor data—such as vibration, motion, or environmental signals—into deployable machine learning models for use cases like predictive maintenance, anomaly detection, and condition monitoring. With built-in analytics and seamless deployment to FRDM boards, TSS simplifies the path from data to intelligent behavior on the edge. eIQ AI/ML Software Environment The eIQ software environment is the foundation that enables AI/ML development across the entire FRDM ecosystem, providing an end-to-end workflow from model creation to on-device inference. It supports importing and optimizing models from popular frameworks such as TensorFlow, PyTorch, and ONNX, and integrates tightly with MCUXpresso and Linux-based environments. eIQ includes tools for model optimization—such as quantization and pruning—as well as runtime engines designed for efficient execution on CPUs, DSPs, and NPUs. By combining these capabilities with hardware acceleration available on FRDM boards, eIQ allows developers to build, deploy, and run real-time AI applications directly on embedded devices with minimal reliance on cloud computing. eIQ Training Curriculum FQA What is an NPU ? A Neural Processing Unit (NPU) in the FRDM platform is a dedicated hardware accelerator integrated into certain microcontrollers (such as the MCX-N family) that is specifically designed to execute machine learning and neural network workloads efficiently. Unlike general-purpose CPUs, the NPU is optimized for the mathematical operations used in AI models, enabling significantly faster inference—up to tens of times higher throughput—while consuming less power. In FRDM boards, the NPU works alongside the CPU and DSP to offload complex AI computations, allowing real-time processing for applications such as image recognition, voice detection, and sensor-based anomaly detection directly on the device. Combined with NXP’s eIQ® software environment, the NPU becomes the core execution engine that transforms FRDM platforms into efficient, low-power edge AI systems capable of running intelligent applications without relying on the cloud What is a Discrete NPU? A Discrete Neural Processing Unit (DNPU) is a standalone AI accelerator designed specifically to execute machine learning and neural network workloads efficiently. Unlike integrated NPUs that are built into a processor, a DNPU exists as a separate chip or module that can be added to a system. It offloads compute-intensive AI operations, such as matrix multiplications and deep learning inference from the main CPU or GPU, delivering significantly higher performance and better energy efficiency. This makes DNPUs ideal for advanced edge AI applications like computer vision, generative AI, and real-time multimodal processing. How do I use Ara modules (DNPU) with FRDM boards? Ara modules, based on NXP’s DNPU technology, can be used with compatible FRDM boards to extend AI processing capabilities. On supported i.MX-based FRDM platforms such as FRDM-IMX95 or FRDM-IMX95-PRO—developers can connect Ara modules (e.g., Ara240) through the M.2 expansion interface. Once connected, the Ara module works alongside the main processor to offload complex AI workloads, enabling faster inference, lower latency, and improved power efficiency. Using the eIQ® AI software environment, developers can prototype and validate models on FRDM, then scale performance by enabling Ara acceleration, creating a seamless path from development to high-performance edge AI deployment. From TinyML to advanced edge AI and GenAI, discover how to build intelligent systems directly on-device with FRDM, no cloud dependency required. FRDM-IMX8 FRDM-IMX8MP FRDM-IMX9 FRDM-MCXN i.MX Application Processors MCU

FAQs - BMA7118/BMA7418 Battery Cell Controllers Introduction The BMA7118 and BMA7418 belong to NXP's latest family of 18-channel Li-ion battery cell controller ICs for advanced battery management systems. These devices are designed to provide accurate cell monitoring, low current consumption, integrated balancing, functional safety support, and scalable communication, making them suitable for demanding automotive and industrial battery applications. For customers interested in electrochemical impedance spectroscopy, the BMA7418 includes dedicated EIS support, while the BMA7118 provides a strong baseline solution with a convenient upgrade path within the same family. 1) What are BMA7118 and BMA7418? The BMA7118 and BMA7418 are NXP battery cell controller ICs designed for monitoring and balancing lithium-ion cells in battery management systems. They support 8 to 18 cells per device and are intended for applications such as EVs, HEVs, and industrial energy storage systems. 2) What is the main difference between BMA7118 and BMA7418? The main difference is EIS support. The BMA7418 includes integrated Discrete Fourier Transform functionality to support electrochemical impedance spectroscopy, while the BMA7118 targets high-accuracy battery monitoring without EIS. Both devices belong to the same product family and are positioned as pin- and software-compatible. 3) How many cells can one device monitor? One device can monitor from 8 up to 18 cells. This gives designers flexibility to optimize the battery architecture and reduce the number of monitoring ICs needed in larger battery packs. 4) What applications are these devices intended for? Typical target applications include automotive battery management systems for electric and hybrid vehicles, as well as industrial battery systems such as stationary energy storage and related electrification platforms. 5) What level of cell-voltage accuracy can I expect? The family is designed for very high measurement accuracy with ultra-low long-term drift. Typical accuracy for the family is ±0.8 mV, supporting precise battery monitoring and improved system performance. 6) Why is “dedicated ADC per voltage channel” important? Using a dedicated ADC for each voltage channel helps avoid the timing limitations of multiplexed measurement approaches. This supports highly synchronized cell measurements, which can improve SOC and SOH calculations and is especially important for EIS-capable systems. 7) What communication options are available? Depending on the variant, communication with the host MCU can be implemented through SPI or through an isolated daisy-chain transport protocol link (TPL). The daisy-chain approach supports scalable high-voltage battery systems with multiple monitoring nodes. 😎 How does the family support functional safety? The family is designed to support ASIL D-oriented battery management architectures. It includes redundant measurement paths, diagnostic functions, fault reporting, and safety-related monitoring features intended to support robust system-level functional safety designs. 9) Can the device measure temperatures and auxiliary signals? Yes. In addition to cell voltages, the devices support auxiliary analog inputs (AINx) that can be used for temperature sensing through external NTC networks and for other auxiliary measurements. These pins can also be configured as GPIOs. 10) What are the power-consumption advantages of this family? A key benefit is the integrated DC-DC converter, which helps reduce overall power consumption compared to solutions that rely on less efficient supply approaches. This can be beneficial for both active operation and low-power battery system scenarios. 11) What balancing capability is integrated? The family integrates passive balancing control with internal balancing FETs and supports balancing across up to 18 cells. It includes features such as timer-based balancing, voltage-based balancing, PWM-based balancing control, and protection-oriented timeout behavior. 12) Can balancing continue in low-power modes? Yes. Balancing support in low-power operating states is one of the useful capabilities of the family. This helps enable battery maintenance functions such as parked-vehicle balancing while still keeping power consumption low. 13) Does balancing influence measurement accuracy? Balancing can influence measured voltage values because current flow through external paths may create small voltage drops. To address this, the device supports balancing pause concepts so that measurements can be taken under more stable conditions when required. 14) Which operating modes are available? Multiple operation modes, including Deep Sleep, Sleep, Active, and Cyclic mode. These allow the system designer to balance measurement performance, wake-up behavior, and current consumption according to the use case. Deep Sleep is the lowest-current startup/storage state with almost no state retention. Sleep keeps key configuration and can allow balancing. Active enables full functionality. In Cyclic mode the device runs measurements in the configured intervals, and moves back to sleep or enters active mode afterward depending on the measurement results. 15) How are overvoltage and undervoltage conditions handled? The devices support configurable threshold checking for measured channels. When configured limits are exceeded, status information can be updated and event mechanisms can be used to notify the host controller or trigger an appropriate system response. 16) What development hardware and software are available? We offer evaluation boards for the BMA7x18 family (EVBMA7118DT, EVBMA7X18DT1), together with software tools (EvalGUI, BMS GEN2 SDK) and broader battery management ecosystem support. 17) Which orderable variants are available? The family includes SPI and TPL variants for both BMA7118 and BMA7418. This allows customers to choose the communication architecture that best matches their battery management system topology. 18) What is BMI7018, and how does it relate to BMA7118/BMA7418? The BMI7018 is an 18-channel Li-ion battery cell controller IC for industrial applications, especially energy storage systems (ESS) and uninterruptible power supplies (UPS). It is not the same product family as BMA7118/BMA7418, but it is highly relevant for customers looking for an NXP battery cell controller optimized for industrial use cases rather than automotive ASIL-D battery packs. It is s tailored to industrial mission profiles, and is characterized for industrial conditions rather than automotive AEC-Q100 Grade 1 positioning. 19) Does BMI7018 support EIS like BMA7418? No. BMI7018 is not positioned as an EIS-capable device. Customers specifically looking for electrochemical impedance spectroscopy support should use BMA7418 instead.

LLM Edge Studio LLM Edge Studio In this post, I want to share a quick walkthrough of LLM Edge Studio, an NXP launcher application designed to test supported Large Language Models running locally on i.MX platforms with Ara240 DNPU acceleration. LLM Edge Studio provides a simple GUI to select a model, load it, enter prompts, and interact with an LLM directly at the edge. It communicates with the Ara240 Runtime SDK through the eIQ AAF Connector, using a REST-based interface for prompt submission and streaming token responses.   Key Features Local LLM inference on supported i.MX platforms Ara240 DNPU acceleration GUI-based model selection and prompt input Streaming token output Integration with eIQ AAF Connector and Ara240 Runtime SDK Support for prebuilt Debian package installation or building from source   Supported Models Qwen2.5-coder-1.5B Qwen2.5-7B-Instruct These models are provided as Ara240-compatible model.dvm files and are intended for local execution on the target platform.   Basic Installation After making sure the Ara240 Runtime SDK is installed on the target board, copy the Debian package: scp llm-edge-studio.deb root@ : Install it with: dpkg -i llm-edge-studio.deb The installation may take a few minutes because the required models are downloaded during setup.   Running LLM Edge Studio Start the application with: run_llm_edge_studio Before launching, make sure the Ara240 runtime service is running: systemctl status rt-sdk-ara2.service --no-pager -l Once the GUI appears, click LOAD to load the selected model. After the model is ready, enter a prompt and submit it to start interacting with the LLM.   Walkthrough Video In the attached video, I show how to launch LLM Edge Studio, load a supported model, submit a prompt, and view the generated response running locally on the i.MX platform with Ara240 DNPU acceleration. (function() { var wrapper = document.getElementById('lia-vid-6396693184112w960h540r329'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos)   Summary LLM Edge Studio is a useful tool for quickly evaluating local LLM inference on NXP i.MX platforms using Ara240 DNPU acceleration. It provides a simple workflow for model loading, prompt testing, and observing token streaming directly at the edge. Link LLM Edge Studio repository: https://github.com/nxp-imx-support/llm-edge-studio ARA2-M2-16G-GT ARA240 Hands-On Training

PN7161 同时移除标签时的 NFC 发现阻塞问题 我正在使用 PN7161 芯片识别 NFC 卡。 当我同时标记 MIFARE Classic 卡和智能手机的 NFC 时，然后同时移除它们，函数NxpNci_WaitForDiscoveryNotification 就会被阻止。 打印 " WAITING FOR 设备 DISCOVERY " 后，程序无法继续打印 " test_1 "。 我使用的是 SW6705。 /////////////////////////////////////////////////////////////// /* 开始探索 */ 如果(::NxpNci_StartDiscovery(RW_DiscoveryTechnologies, sizeof(RW_DiscoveryTechnologies)) != NFC_SUCCESS) { LOG_ERR("无法开始发现"); 返回; } 虽然(_nfcRfMode == NFC_RF_MODE_RW) { LOG_INF( " 等待设备发现 "); /* 等待，直到发现对等设备 */ 而(::NxpNci_WaitForDiscoveryNotification(&RfInterface) != NFC_SUCCESS) { 日志文件("test_1"); 如果(_nfcRfMode != NFC_RF_MODE_RW) { ::NxpNci_StopDiscovery(); 日志文件("模式已更改，退出 RW 模式"); 返回; } } 如果((RfInterface.ModeTech & MODE_MASK) == MODE_POLL) { ////////////////////////////////////////////////////////////////////////////// 以下是出现问题时显示的 NCI 信息。之后，即使将卡靠近，也无法识别。只有在关闭电源并重新打开后，才能再次识别该卡。 [00:03:24.623,321] Iso14443_4Handler: === ISO14443-4 Scenario Complete === NCI>> 2f 11 00 NCI<< 4f 11 01 00 [00:03:25.265,533] NfcManager：CARD REMOVED NCI>> 21 06 01 00 NCI<< 6f 11 01 00 NCI<< 41 06 01 00 NCI>> 21 03 07 03 00 01 01 06 01 NCI<< 61 06 02 00 00 NCI>> 21 03 07 03 00 01 01 06 01 NCI<< 41 03 01 00 [00:03:25.288,543] nfcManager：等待设备发现 NCI < < 41 03 01 a0 NCI < < 60 07 01 a1 a1 NCI < > 21 06 01 03 NCI < < 41 06 01 00 NCI < < 61 06 02 03 00 NC I < < 61 03 0f 01 80 00 0a 04 00 04 aa 4e 46 0e 0e 01 08 00 02 NC I < < 61 03 0f 02 00 04 00 04 08 c0 b9 fa 01 20 00 02 02 02 02 04 00 04 04 08 c0 fa 01 20 00 01 //////////////////////////////////////////////////////////////////////////// 是否有人遇到过这个问题，或者是否有建议的方法来处理同时删除标签的问题，以避免在发现通知功能中阻塞？ Re: PN7161 NFC Discovery Blocking Issue with Simultaneous Tag Removal 你好@Jaden_jung 希望你一切顺利。 能否请您提供有关设置的更多详细信息？您使用的主机平台是什么？你使用的智能手机是iOS设备，还是安卓设备？ 我使用 SW6705 Rev 1.2（使用未修改的 LPC55S6x RW 演示）、OM27160、LPCXpresso55S69 并同时移除 Pixel 3 和 MIFARE Classic，都无法重现这种行为。您能否使用 PN7160 开发套件 (OM27160) 重现这种行为？ Eduardo。 Re: PN7161 NFC Discovery Blocking Issue with Simultaneous Tag Removal 照片显示了症状再现时的电流值。据怀疑，即使在取出卡之后，系统仍无法恢复到轮询状态。 Re: PN7161 NFC Discovery Blocking Issue with Simultaneous Tag Removal 主机是 nrf52840，手机是安卓手机。(Samsung Galaxy s25 和 flip) 同时访问两张 MIFARE 经典卡时没有问题。 将 OM27160 板与树莓派搭配使用（使用 linux_libnfc-nci）时没有问题。 定义 REMOVE_P2P_SUPPORT 可以解决问题。 出现问题时，它是否按照下面的流程工作？ 0. at 946line if (Answer[1] == 0x05) // true { pRfIntf->Interface = Answer[4]; // = 0x02 = INTF_ISODEP pRfIntf->Protocol = Answer[5]; // = 0x04 = PROT_ISODEP ...... NCI<< 61 05 19 01 02 04 01 ff 01 0c 0b 64 c6 b2 a3 00 00 00 80 81 71 01 00 00 02 01 00 1.在 WaitForDiscoveryNotification 处分支（第 962-963 行）： 在未定义 REMOVE_P2P_SUPPORT 时执行分支。 NCI>> 21 06 01 03 (NxpNci_HostTransceive) NCI<< 41 06 01 00 (NxpNci_WaitForReception) 2.从 do-while 循环退出： 收到以下通知后，循环终止（第 966 行）： NCI<< 61 06 02 03 00（成功退出循环） 3.多张卡片检测（找到 2 张卡片）： 该设备可识别野外两个目标： 目标 1：61 03 0f 01 80 00 0a 04 00 04 aa 4e 46 0e 0e 01 08 00 02 目标 2：61 03 0f 02 04 00 0a 04 00 04 04 08 c0 b9 fa 01 20 00 02 02 02 04 04 08 c0 b9 fa 01 20 00 01 4.处理条件分支：（第 986 行） 由于接收到的响应与条件不符（Answer[0] == 0x61&& Answer[1] == 0x05），逻辑会跳转到 if (AnswerSize != 0) 块。 5.第 989 行的潜在阻塞： 在第 989 行，条件 while(Answer != 0) 似乎总是为真，导致潜在的无限循环或阻塞状态。这似乎是启用 P2P 支持时系统挂起的根本原因。