IC COD Please help confirm the COD (wafer location) for  MC9S12XDP512MAG Re: IC COD Hello Weijun Ni Thanks for reaching out. Unfortunately, COD/COA information is not allowed to be shared in community. Please kindly submit a ticket https://support.nxp.com/s/?language=en_US , we will help there Thanks for understanding Becky

Scarthgap 和 Wrynose 的 I.MX8 NPU 性能差异 您好，NXP， 我已经对 NXP 提供的 `mobilenet_v1_1.0_224_quant.tflite` 进行了基准测试。使用 VX NPU 代理的模型。下面的结果是在 Scarthgap 6.6.23和 Wrynose 6.18.37 上重复基准测试运行的稳态“推理（平均）”计时结果。 Wrynose算法的平均推理时间比Scarthgap算法的结果高出约27%。 这种差异是预期之内的吗？我应该检查哪些 NPU、委托或基准测试设置？ 基准测试命令为： ```bash ./benchmark_model--graph=mobilenet_v1_1.0_224_quant.tflite --external_delegate_path=/usr/lib/libvx_delegate.so ``` 此致敬礼， 加布里埃尔·戈斯登 Re: I.MX8 NPU performance difference between Scarthgap and Wrynose 你好， 我在我们的 i.MX 8M Plus EVK 上也重现了类似的性能差异。使用相同的 MobileNet 模型和测试配置，我在 Scarthgap 上测得的时间为约 2.96 毫秒，而在 Wrynose 上测得的时间为 3.55 毫秒，推理时间大约增加了 20% 。 我的测试证实，两个版本中都成功委托了整个模型，并且相关的 NPU/ML 时钟频率配置为相同的速率。我还通过性能分析确认，性能差异仍然存在于 VX Delegate 执行路径中。 该现象可复现，现有结果表明，差异与软件执行堆栈有关，而非CPU回退或较低的NPU标称时钟频率。

HyperLynxを用いたLPPDR4シミュレーション用のタイミングモデル(.v)の要請。 こんにちは、 プロジェクトでMIMX8ML8CVNKZABを使っていて、HyperLynxを使ってLPDDR4インターフェースをシミュレートしようとしています。 Hyperlynxはメモリコントローラ用のタイミングモデルファイル(*.v)を要求します。MIMX8ML8CVNKZABのタイミングモデルを教えていただけますか? よろしくお願いいたします。 ブッディカ Re: Request for timing model (.v) for LPPDR4 simulation using HyperLynx. こんにちは、 私たちのチップには特別なVerilog Design Fileは提供していません。JEDEC仕様に従っています。Hyperlynxは多くの標準.vを提供しています異なるDDRタイプ用のファイル。デフォルトのタイミングを使用すれば十分です。例えば、次のようになります。 よろしくお願いいたします。

FS26 standby Hi，NXP专家，我遇到一个FS26相关的问题： 测试发现FS26无法进入standby模式，单步运行的时候可以运行下去，但是FS26无法进入standby。只要全速运行Sbc_fs26_SetOperatingMode()接口的时候会出现复位。硬件上的Wake信号已经去掉了，且reset引脚上没有接其他信号。 Small Engine Driver Re: FS26 standby Hi Chenxu 您是从哪个状态切换到standby状态？ 如何发的命令能给出吗？ Re: FS26 standby Hi，谢谢你的帮助，这个问题解决了。 测试发现当唤醒时间小于5ms的话，读M_WIO_FLG寄存器出现0，读不到唤醒源的情况。可以帮忙回答这个问题吗，谢谢 Re: FS26 standby HI CHENXU 新的topic请重新提交新的ticket吧！ https://support.nxp.com/s/?language=en_US

i.MX95: neutron_perf.sh で NPU 負荷が 100% と誤って表示される (perf_counters 行はバイト単位で読み取られます) こんにちは、 i.MX95では、neutron_perf.sh（eiq-examples-npu-utils、UG10166セクション8.4.5.1）が、実際の負荷が約60%であるにもかかわらず、NPU負荷が100%と表示されることがあります。 環境 - 基板: IMX95LPD5EVK-19 - BSP: LF_6.18.20_2.0.0 (neutron_perf.sh は lf-6.18.37_2.1.0 と同じです) - eIQ Neutron SDK 3.2.3 繁殖のステップ 1. MobileNetモデルを、neutron-compilerでimx95用に変換します(TensorFlow Liteの例フォルダ内のTensorFlow Liteフォルダ内のmobilenet_v1_1.0_224_quant.tflite)。 2. ボード上で、変換したモデルと背景にNeutron Delegateをbenchmark_modelして同時にneutron_perf.shを実行します。 3. 実際の負荷は約60%ですが、60秒間に100%と表示されたことが11回ありました。 原因 1.debugfsのperf_countersファイルはシーク可能ではないため、bashの「read」コマンドは1バイトずつ読み込みます。ドライバ関数perf_counters_read()はすべての読み取り呼び出しで回線を再構築するため、1行が異なるモーメントの値を混ぜ、一部の値は切れます。私たちのテストでは、「read」がついた300件中52件が破損し、「cat」で300件中0件が壊れました。 2. 32ビットカウンターが最大値に達すると、ドライバはそれを0にリセットします。スクリプトは負の差の絶対値を取り、これが100%となります。 提案された修正案（テスト済み：同じテストで100％成功しなかった） 1. 行全体を一度に読み込み（例えば cat の場合）、それを変数に分割します。 2. NACTの差が負の場合は、絶対値を取る代わりに32乗の2を加えます。 必要ならパッチを共有できます。 ドライバ側では、perf_countersにseq_fileを使うことで原因1(未確認)も防げる可能性が高いです。 注：修正後も、NACTが最大値に達するたびに（負荷が60%の場合、約7秒ごと）、NPU負荷は1インターバル低下します。これは、次の読み取りでリセットされるまでNACTがそこで停止するためです。 質問 1.これは既知の問題ですか? 2. 修正はFUTUREのBSPリリースに含まれることはCANか? よろしくお願いします。 Re: i.MX95: neutron_perf.sh shows false 100% NPU Load (perf_counters line is read byte by byte) こんにちは、 2週間返信がなかったので、念のためご連絡いたしました。 レポートの確認を容易にするため、提案された修正案をパッチファイル（neutron_perf_fix.patch.txt）として添付しました。neutron_perf.sh の 2 行だけを変更します。最初の投稿で説明したとおりです。 1. cat コマンドで perf_counters の行全体を一度に読み込み、それを変数に分割します。 2. NACTの差が負の値の場合は、絶対値を取る代わりに2の32乗を加えます。 このパッチは、GitHub の nxp-imx/eiq-example リポジトリ (ブランチ lf-6.18.20_2.0.0) にある npu_utils/neutron_perf.sh を対象としています。これはUG10166(i.MX Machine Learning ユーザー's Guide)第8.4.5.1節で説明されているスクリプトです。 https://www.nxp.com/docs/en/user-guide/UG10166.pdf NXPの誰かが、私の最初の投稿の2つの質問を確認してもらえますか? 1.これは既知の問題ですか? 2. この問題はFUTUREのBSPリリースでCAN修正でしょうか?添付のパッチはあくまで提案です。例えばドライバ側の別の修理も問題ありません。 よろしくお願いします。

FS26スタンバイ NXPのエキスパートの方、こんにちは。FS26に関連する問題が発生しました。 テストの結果、FS26がスタンバイモードに移行できないことが判明しました。シングルステップ実行は継続されますが、FS26はスタンバイモードに移行できません。Sbc_fs26_SetOperatingMode()インターフェースがフルスピードで実行されるたびにリセットが発生します。ハードウェアウェイク信号は削除されており、リセットピンには他の信号は接続されていません。 小型エンジンドライバー Re: FS26 standby こんにちは、チェンシュウ どの状態からスタンバイ状態に切り替えましたか？ 実行したコマンドを教えていただけますか？ Re: FS26 standby こんにちは、ご協力ありがとうございました。問題は解決しました。 テストの結果、ウェイクアップ時間が5ms未満の場合、M_WIO_FLGレジスタの読み取り値が0となり、ウェイクアップソースが読み取れないことが判明しました。この点についてご回答いただけますでしょうか？よろしくお願いいたします。 Re: FS26 standby こんにちは、チェンシュー 新しいトピックについては、新しいチケットを送信してください！ https://support.nxp.com/s/?language=en_US

i.MX95：neutron_perf.sh 显示错误的 100% NPU 负载（perf_counters 行是逐字节读取的） 你好， 在 i.MX95 上，neutron_perf.sh（eiq-examples-npu-utils，UG10166 第 8.4.5.1 节）有时会显示 100% NPU 负载，而实际负载约为 60%。 环境 - 板：IMX95LPD5EVK-19 - BSP：电路板支持包。LF_6.18.20_2.0.0（lf-6.18.37_2.1.0 中的 neutron_perf.sh 相同） - eIQ Neutron SDK 3.2.3 重现步骤 1. 使用 neutron-compiler 将电路板支持包。中的 MobileNet 模型（TensorFlow Lite 示例文件夹中的 mobilenet_v1_1.0_224_quant.tflite）转换为 imx95 格式。 2. 在板上，以转换后的模型和 Neutron 委托在后台运行 benchmark_model，同时运行 neutron_perf.sh。 3. 实际负载约为 60%，但在 60 秒内出现了 11 次 100% 的情况。 原因 1.debugfs 中的 perf_counters 文件不可查找，因此 bash“read”命令一次读取一个字节。驱动函数 perf_counters_read() 会在每次读取调用时重建行，因此一行会混合来自不同时刻的值，并且某些值会出错。在我们的测试中，300 个包含“read”的读取中有 52 个被破坏，而 300 个包含“cat”的读取中没有一个被破坏。 2. 当 32 位计数器达到其最大值时，驱动程序将其 RESET 到 0。脚本取负差值的绝对值，即 100%。 建议的修复方案（已测试：在同一测试中未达到 100% 的成功率） 1. 一次性读取整行（例如，使用 cat），然后将其拆分为变量。 2. 当 NACT 差值为负数时，将 32 的幂加 2，而不是取绝对值。 如有需要，我们可以分享补丁。 在驱动程序方面，使用 seq_file 作为 perf_counters 可能也能防止原因 1（未经验证）。 注意：即使进行了修复，每次 NACT 达到最大值时（大约每 7 秒达到 60% 的负载），NPU 负载也会下降一个时间间隔，因为 NACT 会在那里停止，直到下一次读取将其 RESET。 问题 1.这是已知问题吗？ 2. 该修复程序能否包含在未来的 电路板支持包。版本中？ 谢谢！ Re: i.MX95: neutron_perf.sh shows false 100% NPU Load (perf_counters line is read byte by byte) 你好， 这是善意的后续跟进，因为两周以来一直没有收到回复。 为了方便审阅报告，我已将建议的修复方案作为补丁文件（neutron_perf_fix.patch.txt）附上。它只修改了 neutron_perf.sh 文件中的两行代码。正如我在第一篇帖子中所述： 1. 使用 cat 命令一次性读取 perf_counters 行，然后将其拆分为变量。 2. 当 NACT 差值为负数时，将 32 的幂加 2，而不是取绝对值。 该补丁针对 GitHub 上的 nxp-imx/eiq-example 存储库（分支 lf-6.18.20_2.0.0）中的 npu_utils/neutron_perf.sh。这是 UG10166（i.MX 机器学习用户指南）第 8.4.5.1 节中描述的脚本： https://www.nxp.com/docs/en/user-guide/UG10166.pdf NXP 的工作人员能否帮忙查看一下我第一篇帖子中的两个问题？ 1.这是已知问题吗？ 2. 这个问题能否在未来的 电路板支持包。 版本中得到解决？附件中的补丁只是一个建议。采取其他解决方案，例如在驾驶员侧进行修复，也是可以的。 谢谢！

MIMXRT1176DVMAB 的最小系统设计指南 尊敬的恩智浦技术支持团队： 我正在根据以下内容设计定制PCB： MIMXRT1176DVMAB 一款基于 Quectel 的网络产品 RG255CGL00AB-4M2-SGASA_A 调制解调器。我们的第一个版本运行良好，现在我们正在使用 i.MX RT1176 开发下一个版本。 MCU 将位于 Mac 和 Quectel 调制解调器之间，提供面向 Mac 的 USB 网络接口并转发互联网流量。它还可以处理调制解调器的启动和恢复、设备识别、流量限制和使用情况统计、诊断、安全固件更新以及远程车队管理，而无需配套应用程序。 请问您能否提供或指引我联系以下机构： 简明扼要 最小系统硬件设计指南 涵盖该部件的电源、时钟、启动配置、复位、外部闪存和编程/调试接口。 这 原理图符号和PCB封装CAD文件，最好是KiCad兼容格式。 任何与在定制PCB上实现MCU相关的参考原理图或应用笔记。 EVKB 原理图包含许多我们最初设计中不需要的外围设备，因此，一份专注于基本电路的参考资料将特别有帮助。 感谢您抽出时间提供帮助。 Re: Minimum-System Design Guide for MIMXRT1176DVMAB 嗨@Onyeka ， 我建议先从MIMXRT1160/1170 处理器的硬件开发指南入手，因为它提供了有关板布局建议和设计清单的信息。此外，如果某些引脚将不使用，该指南还包含一个章节，其中提供了处理未使用引脚的建议。 关于 CAD 模型，您可以在i.MX RT1170产品页面的“购买/参数化”部分搜索特定零件编号来找到它们。 此致 巴勃罗

i.MX95: neutron_perf.sh shows false 100% NPU Load (perf_counters line is read byte by byte) Hello, On i.MX95, neutron_perf.sh (eiq-examples-npu-utils, UG10166 section 8.4.5.1) sometimes shows 100% NPU Load while the actual load is about 60%. Environment - Board: IMX95LPD5EVK-19 - BSP: LF_6.18.20_2.0.0 (neutron_perf.sh is the same in lf-6.18.37_2.1.0) - eIQ Neutron SDK 3.2.3 Steps to reproduce 1. Convert the MobileNet model in the BSP (mobilenet_v1_1.0_224_quant.tflite in the TensorFlow Lite examples folder) with neutron-compiler for imx95. 2. On the board, run benchmark_model with the converted model and the Neutron delegate in the background, and run neutron_perf.sh at the same time. 3. The actual load is about 60%, but 100% was shown 11 times in 60 seconds. Cause 1. The perf_counters file in debugfs is not seekable, so the bash "read" command reads it one byte at a time. The driver function perf_counters_read() rebuilds the line on every read call, so one line mixes values from different moments, and some values break. In our test, 52 of 300 reads with "read" were broken, and 0 of 300 with "cat". 2. When a 32-bit counter reaches its maximum value, the driver resets it to 0. The script takes the absolute value of the negative difference, which gives 100%. Proposed fix (tested: no 100% in the same test) 1. Read the whole line at once (for example with cat), and then split it into the variables. 2. When the NACT difference is negative, add 2 to the power of 32 instead of taking the absolute value. We can share the patch if needed. On the driver side, using seq_file for perf_counters would probably also prevent cause 1 (not verified). Note: even with the fix, the NPU Load drops for one interval each time NACT reaches its maximum value (about every 7 seconds at 60% load), because NACT stops there until the next read resets it. Questions 1. Is this a known issue? 2. Could the fix be included in a future BSP release? Thank you. Re: i.MX95: neutron_perf.sh shows false 100% NPU Load (perf_counters line is read byte by byte) Hello, This is a gentle follow-up, as there has been no reply for two weeks. To make the report easier to review, I have attached the proposed fix as a patch (neutron_perf_fix.patch.txt). It changes only two lines of neutron_perf.sh, as described in my first post: 1. Read the perf_counters line all at once with cat, and then split it into the variables. 2. When the NACT difference is negative, add 2 to the power of 32 instead of taking the absolute value. The patch is against npu_utils/neutron_perf.sh in the nxp-imx/eiq-example repository on GitHub (branch lf-6.18.20_2.0.0). This is the script described in UG10166 (i.MX Machine Learning User's Guide), section 8.4.5.1: https://www.nxp.com/docs/en/user-guide/UG10166.pdf Could someone from NXP check the two questions in my first post? 1. Is this a known issue? 2. Could this issue be fixed in a future BSP release? The attached patch is only a suggestion. A different fix, for example on the driver side, is also fine. Thank you.

Minimum-System Design Guide for MIMXRT1176DVMAB Dear NXP Support Team, I am designing a custom PCB based on the MIMXRT1176DVMAB for a networking product built around the Quectel RG255CGL00AB-4M2-SGASA_A modem. Our first version is working well, and we are now developing the next version with the i.MX RT1176. The MCU will sit between the Mac and the Quectel modem, providing the Mac-facing USB network interface and forwarding internet traffic. It will also handle modem startup and recovery, device identity, traffic throttling and usage accounting, diagnostics, secure firmware updates, and remote fleet management, without requiring a companion app. Could you please provide or direct me to: A concise minimum-system hardware design guide covering power supplies, clocks, boot configuration, reset, external flash, and programming/debug interfaces for this exact part. The schematic symbol and PCB footprint CAD files, preferably in KiCad-compatible format. Any relevant reference schematics or application notes for implementing the MCU on a custom PCB. The EVKB schematics include many peripherals that are unnecessary for our initial design, so a focused reference for the essential circuitry would be particularly helpful. Thank you for your time and assistance. Re: Minimum-System Design Guide for MIMXRT1176DVMAB Hi @Onyeka, I would recommend starting with the Hardware Development Guide for the MIMXRT1160/1170 Processor, as it provides information about board layout recommendations and design checklists. Additionally, if some pins will be unused, the guide includes a section with recommendations for handling unused pins. Regarding CAD models, you can find them on the i.MX RT1170 product page by searching for the specific part number in the Buy/Parametrics section. Best Regards Pablo

EasyEVSE EVerest MPU 构建 — SE05x 中间件版本说明 使用 i.MX93 服务处理板设置 NXP EasyEVSE 平台。 我正在按照 EasyEVSE EVerest MPU 的说明操作，并使用以下清单文件： 分支：版本/everest-mpu-2.0 清单文件：imx-6.12.20-2.0.0_everest.xml 目标图像：imx-image-everest meta-nxp-everest-mpu README 指定 EdgeLock SE05x Plug & Trust 中间件版本为 04.07.01 (se05x_mw_v04.07.01.zip)，但我目前只能在 NXP 下载网站上找到版本 04.08.01 (se05x_mw_v04.08.01.zip)。 版本/everest-mpu-2.0 是否支持中间件 04.08.01清单 和 imx-6.12.20-2.0.0_everest.xml？ 具体应该更新哪个配方或配置文件？需要做哪些更改？ 如果需要，中间件 04.07.01 是否仍然可以通过官方下载链接获取？ Re: EasyEVSE EVerest MPU build — SE05x middleware version clarification 嗨@ChargeMeMaybe README 文件仅将 04.07.01 列为先决条件；04.x 系列版本之间没有重大的架构变化。您需要修改 bb 文件以使用 04.08.01 版本。 此致， 志明

T1014- Error measuring IR length Hello experts of NXP: The link of original issue is : https://community.nxp.com/t5/T-Series/T1014-the-jtag-chain-does-not-contain-any-debuggable-cores/m-p/2424033#M5509 And I add an additional info is that when enabled the jtag Diagnostics, the log reported Error measuring IR length:  Please kindly help to find the root cause of the issue, thanks. Re: T1014- Error measuring IR length Support you in the  https://community.nxp.com/t5/T-Series/T1014-the-jtag-chain-does-not-contain-any-debuggable-cores/m-p/2424033#M5509

S32K312 FlexCAN – 启用 AEN 和总线关闭恢复时，使用 RTD 7.0.1 实现发送消息缓冲区中止 您好，NXP团队， 我正在使用NXP S32K312评估板和S32K3 RTD 7.0.1（AUTOSAR 4.9.0）。我正在使用RTD API FlexCAN_Ip_Send()和FlexCAN_Ip_AbortTransfer()测试FlexCAN发送消息缓冲区中止功能。 我的测试表明，中止功能没有按预期运行。我已附上项目文件、MEX 配置和测试代码供您参考。 我希望您能就以下三个问题提供指导。 1. 中止多个发送消息缓冲区 在我的第一次测试中，我使用多个消息缓冲区传输消息，然后对所有这些缓冲区发出中止请求。测试代码如下所示。 /* Transmit messages using MB0 to MB39. */ for (uint8_t lMb_u8 = 0U; lMb_u8 < 40U; lMb_u8++) { FlexCAN_Ip_Send( INST_FLEXCAN_0, lMb_u8, &tx_info, 0x123U, &dummyData[0] ); } /* Request abort for MB0 to MB39. */ for (uint8_t lMb_u8 = 0U; lMb_u8 < 40U; lMb_u8++) { FlexCAN_Ip_AbortTransfer( INST_FLEXCAN_0, lMb_u8 ); } 所有传输请求都使用相同的 CAN ID，即0x123 ，而消息缓冲区索引从 0 到 39 不等。 MCR [AEN]位设置为 1，启用了中止机制。但是，即使我发出中止消息缓冲区的请求，所有消息仍然可以在 PCAN-View 中看到。 我的预期是，仍在等待传输的消息应该被中止，而已经完成传输的消息则不能被中止。 请问您能否澄清以下问题？ 对于在多个消息缓冲区上进行传输，然后中止所有待处理的传输，是否有推荐的顺序？ 2. 使用单个消息缓冲区中止传输 为了找出问题所在，我创建了第二个测试，该测试仅使用消息缓冲区 8。 序列如下： 为 MB8调用FlexCAN_Ip_Send() 。 使用FlexCAN_Ip_GetTransferStatus()检查传输状态。 如果发送成功且传输状态为FLEXCAN_STATUS_BUSY ，则对 MB8调用FlexCAN_Ip_AbortTransfer() 。 再次读取传输状态并检查硬件寄存器。 发送 API 返回FLEXCAN_STATUS_SUCCESS ，中止前的状态检查报告FLEXCAN_STATUS_BUSY 。但是，中止 API 返回FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS ( 0x5 )。 在调试 RTD 实现时，我发现返回状态源自FlexCAN_AbortTxTransfer() 函数内部的以下条件： FlexcanMbConfig = *FlexcanMb; /* Check if the MBs have been safely inactivated */ if ((uint32)FLEXCAN_TX_INACTIVE == ((FlexcanMbConfig & FLEXCAN_IP_CS_CODE_MASK) >> FLEXCAN_IP_CS_CODE_SHIFT)) { /* Transmission has occurred */ Result = FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS; } 在我的当前配置中，消息缓冲区位于内存浏览器中的0x40304100地址。中止请求发出后， CODE字段显示为0x8 ，这对应于非活动/已发送状态，而不是预期的中止代码0x9 。 我还为FlexCAN_AbortTxTransfer()函数中的以下语句设置了一个断点： TimeStart = OsIf_GetCounter( FLEXCAN_IP_SERVICE_TIMEOUT_TYPE ); 此时， IFLAG1[8]已设置。 在当前的RTD实现中，中止序列会将FLEXCAN_TX_ABORT ( 0x9 )写入消息缓冲区的CODE字段，然后轮询相应的消息缓冲区中断标志。中止辅助函数返回后， FlexCAN_Ip_AbortTransfer()中的FlexCAN_ClearMsgBuffIntStatusFlag()函数会清除该标志。 我担心的是，在发出中止请求之前，中断标志可能已经因已完成的传输而被设置。如果真是这样，轮询循环就可以立即退出，而无需等待新的中止完成事件。但是，我尚未确认这是否是我的问题的原因。 3. 总线关闭恢复（自动恢复功能已禁用） 在另一项测试中，我禁用了自动总线关闭恢复功能，并尝试通过应用程序处理恢复。 当总线断开时，我目前的做法是先取消初始化 FlexCAN 驱动程序，然后再重新初始化。但是，在此之后，后续对FlexCAN_Ip_Send()的调用无法成功发送消息。 当自动总线断开恢复功能被禁用时，请问推荐的恢复步骤是什么？ 具体来说： 取消初始化和重新初始化是否足以使 FlexCAN 控制器从总线关闭状态恢复？ 在反初始化之前，是否应该中止或显式清除所有未处理的 TX 消息缓冲区？ 重新初始化后，消息缓冲区在传输前是否必须重新配置或初始化？ 在控制器能够再次发送数据之前，是否需要执行与ESR1状态、 MCR 、 CTRL1[BOFFREC] 、中断标志或 RTD 内部传输状态相关的任何步骤？ 从总线关闭状态恢复的推荐顺序是什么？同时要确保没有过期的 TX 传输或邮箱状态阻止后续传输。 我已附上测试项目、MEX 配置和相关源代码，以便审查配置和 API 使用情况。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 嗨@Yogs 我已将您提出的三个问题的答案总结如下： （内容较多，格式有点混乱。） Q1. 关于“Flexcan 中止”问题。 首先，您需要了解 FlexCAN 中止机制仅对仍处于挂起状态的 TX 消息缓冲区 (MB) 有效。 关于你的第一次测试： 首先激活MB0； FlexCAN 开始扫描并继续传输 MB0 的内容； 同时，CPU继续配置MB1、MB2、…、MB39； 当 CPU 最终到达第二个循环时，最初的一组 MB 可能已经传输完毕。 在总线负载低、成功接收到 ACK 以及经典 CAN 典型的 8 字节有效载荷等条件下， 40帧的传输可以很快完成。 同样的情况也适用于第二个测试，如果总线处于空闲状态，FlexCAN 很可能已经完成传输。 在 CPU 执行中止命令之前。 因此，你的两个测试都不能证明任何事情。 要正确验证中止操作，需要特意创建一个明确的“待处理”窗口，而不是依赖 CPU 的执行速度。 例如： 配置另一个 CAN 节点，使其使用更高优先级的 ID 持续占用总线，从而使目标消息缓冲区 (MB) 保持处于挂起状态，然后触发中止。 Q2：为什么单 MB 测试最初返回 BUSY，但在中止请求时返回 NO_TRANSFER_IN_PROGRESS？ 两者之间可能会出现短暂的状态不匹配： `FlexCAN_Ip_Send()` 将 RTD（运行时驱动程序）状态设置为 `BUSY`。 硬件开始传输。 帧传输完成；硬件将 MB（消息缓冲区）代码更新为 `0x8` 并设置 `IFLAG`。 如果 TX IRQ 处理程序尚未执行，或者在断点调试期间系统暂停，则 RTD 状态结构可能仍保持为“BUSY”。 此时会调用“中止”操作。 在内部，`Abort` 函数读取 MB CODE 并发现它已经是 `0x8`。 它返回 `FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS`。 因此：`GetTransferStatus() = BUSY` 且 `FlexCAN_Ip_AbortTransfer() = NO_TRANSFER_IN_PROGRESS` 并非一定相互矛盾。 前者可能反映软件记账，而后者则确认实际的硬件代码。 Q3. 总线停驶恢复 完全可以通过重新初始化 CAN 模块来从“总线关闭”状态恢复。 要手动执行“总线关闭”恢复，应用层必须首先停止数据传输，并取消或丢弃所有待处理的发送 (TX) 请求（中止）。 随后，控制器必须进行完全反初始化，然后再进行重新初始化。 随后，应重新配置应用层接收（RX）消息缓冲区（MB），并清除任何过时的消息缓冲区标志、错误标志和软件传输状态。 在恢复传输之前，应用层应验证控制器是否已退出“冻结”或“未就绪”状态，并确保发送消息缓冲区（TX MB）和“准备传输”（RTD）状态均未处于“忙碌”状态。 既然你提到你的测试失败了，那么你很可能忽略了上面提到的步骤。我在附件中没有找到任何关于总线断开恢复程序的信息；如果您对此仍有疑问，请随时与我分享您的测试项目，我可以查看并帮助您检查。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 关于问题1，我想澄清一下我的测试条件。 我使用的 CAN 波特率为 500 kbps ，一个具有 8 字节有效载荷的经典 CAN 帧 在总线上传输 大约需要 300 µs 。 在我的测试中，我首先通过相应的TX消息缓冲区提交消息，然后立即执行中止函数。中止函数会遍历相应的消息缓冲区，并对每个缓冲区调用FlexCAN_AbortTxTransfer()函数。 因此，中止请求是在传输请求发出后立即针对相应的消息缓冲区发出的，而不是故意延迟发出的。 我明白，在中止循环到达之前，前几条消息可能已经传输完毕。但是，考虑到大致的传输持续时间和提交的消息数量，我预计在发出中止请求时，一些较晚的消息缓冲区仍然会有待处理的传输。 您能否帮我了解一下，是否存在其他硬件条件或时序因素会导致这些待处理消息无法中止？ Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 嗨@Yogs 这是你的代码中“中止 MB”的默认序列； for(uint8_t lMb_u8 = 0; lMb_u8 < 40; lMb_u8++) { FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0,lMb_u8); } 我已将其修改为“40 - 1Mb_u8”。 for(uint8_t lMb_u8 = 0; lMb_u8 < 40; lMb_u8++) { FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0,40 - lMb_u8); } 以下是我的测试结果。 我只收到了两帧数据；其他所有 MB 的数据都已成功中止。 此次验证的结果足以证实我之前的假设：在你执行中止 MB 操作之前，当前的 MB 已经成功发送。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 您好， 谢谢你的解释。我理解了您的建议，并测试了反向中止序列。正如您所说，这种方法效果更好：我只在总线上收到两个帧，而其余消息都成功中止了。 但是，我对这种行为有一些疑问。 1. 为什么需要逆向堕胎？ 这两个循环本质上不都是在执行相同的操作吗，只是执行顺序不同？ 能否解释一下为什么从最高的邮箱索引开始中止操作会产生如此显著的影响？这是否与 FlexCAN 内部扫描或选择 TX 消息缓冲区的顺序有关？ 反向顺序中止是硬件要求，还是仅仅是一种提高中止待处理消息概率的推荐方法？ 2. 如果要中止单个消息缓冲区呢？ 我还测试了仅使用一个消息缓冲区时的中止功能： FlexCAN_Ip_Send( INST_FLEXCAN_0， 0U, &tx_info， 0x123U， &dummyData[0] ）； FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0, 0U); 我测试了执行 FlexCAN_Ip_Send() 和调用 FlexCAN_Ip_AbortTransfer() 之间的时间。大约需要 10.3 微秒。 然而，即使间隔时间很短，消息仍然会在 CAN 总线上传输。 我还使用 PCAN-View 中的高优先级消息保持了合理的总线负载，但单消息中止仍然不成功。 作为对比，当我使用多个消息缓冲区进行传输，然后按相反的顺序中止它们时，测得的序列持续时间约为 9.3 毫秒，总线上只接收到两个帧，其余消息都被中止。 这就引出了另一个问题：为什么即使在发送 API 返回后大约 10.3 µs 发出中止请求，单消息中止仍然会失败，而多邮箱反向顺序方法却能成功中止大多数消息？ 在发出中止请求之前，该单条消息是否可能已经传输到内部 TX 串行消息缓冲区 (TX SMB)？ 我希望您能解释一下硬件是如何处理这种情况的，以及如何可靠地测试单个消息缓冲区的中止机制。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 嗨@Yogs 为什么需要以相反的顺序中止操作？ 我并非暗示这是必要的。 通过这些对比测试结果，我解释道，中止操作可能会失败，因为您尝试中止的特定消息缓冲区 (MBn) 实际上已经成功传输。 当您按顺序填充消息缓冲区（从 MB0、MB1、…，直到 MB39）并从 MB0 开始执行中止操作时，目标 MB 可能已经成功发送。 考虑另一种方法：如果我们从 MB39 开始发起中止操作呢？这样可以确保优先处理索引较高的消息缓冲区以进行中止操作。

T1014 - JTAG 链不包含任何可调试内核 恩智浦的各位专家，您好： 我在自研的 T1014rdb 板上设置 Code Warrior TAP 时遇到了“jtag 链不包含任何可调试内核”和“JTAG 链配置失败”的问题。 通过分析，我们确认可以通过使用 ccs 命令测试访问 JTAG 链，但是无论是否重置电路板，都无法通过“get_children”命令获取调试核心： 我们发现的另一个现象是，在 ccs 中无法找到 t1014 芯片类型，只能找到 t10xx 系列，但可以找到 t1040 系列： 目前 RCW 加载方式是通过 SPI Flash，我们可以通过 MISO 获取 0xaa55aa55，并且 HRESET 已成功提升至 1.8V： 目前我们没有其他方法可以解决这个问题，仍然无法通过Code Warrior TAP调试T1014板。 请帮忙提供解决此问题的建议，问题是出在电路板启动还是IDE配置上？谢谢。 Re: T1014 - the jtag chain does not contain any debuggable cores 你好@BowenLi1991 ， 请您尝试一下 “ccs::config_chain t1040” 而不是 “ccs::config_chain t1014” 请在 CCS 中以硬编码模式尝试以下命令。 （bin）2% 全部删除 （bin）3% 配置 cc cwtap （bin）4% 显示 cc 0：CodeWarrior TAP (cwtap) CC 软件版本。{0.0} （二进制）5% ccs::config_chain t1040 (bin) 6 % 显示 ::ccs::get_config_chain 链条位置 0：T1040 (bin) 7% ccs::reset_to_debug 如果命令运行正常，请将 T1014 设置为闪存启动模式，然后再次运行该命令。 如果所有命令都能正常运行。 请按照 T1024RM 的图 4-1 检查 PORESET_B、HRESET_B、RESET_REQ_B 和 ASLEEP 的波形。上电复位序列 谢谢！ 六月

PCA9431HK datasheet and AN12639 access for NFC charging listener design The PCA9431 datasheet and AN12639 (referenced in the CRN120 datasheet) are not visible on the product page, even when logged in. Could you share them or tell us how to request access? Questions: 1. Is the PCA9431 output regulated to a fixed 5 V, and what output current is available at about 0.7 W? 2. Is there a reference schematic or eval kit for the CRN120 plus PCA9431 listener, and the matching CTN730 or CTN530 transmitter? 3. Recommended listener coil size and inductance for a coil of about 10 to 15 mm? Where can I d/l the **bleep** datasheet and docs? Re: PCA9431HK datasheet and AN12639 access for NFC charging listener design Hello, The datasheet and app notes required NDA. Please go to this web page: Secure Access Rights | NXP Semiconductors   Please follow the Step 2 for signing the NDA first. After you got the NDA number, follow the Step 3 to click the "submitting your request".   Then please request the highest access rights of the NFC Changing products.   Please type your project details and the NDA number in the "Reason" for requesting the access rights. 

主题：HyperLynx 和 IBIS 中的 i.MX 8M Plus 封装延迟 你好， 我正在使用 NXP i.MX 8M Plus (MIMX8ML8CVNKZAB) 和imx8mp_15x15_v2.ibs模型在 HyperLynx 2604 中进行信号完整性和建立/保持时间分析。 该设备的芯片到焊球延迟列于i.MX 8M Plus 硬件开发人员指南的表 23 中。我想知道这些延迟是否包含在 IBIS 模型中，以及 HyperLynx 在计算建立时间和保持时间时是否使用了这些延迟。 请问有人能确认一下，在使用 IBIS 模型时，这些封装延迟是否会自动包含在 HyperLynx 的建立/保持时间计算中吗？我的测量位置已设置 为 i.MX 8M Plus 的 芯片 。 谢谢！ 布迪卡 Re: Subject: i.MX 8M Plus Package Delay in HyperLynx and IBIS 您可以参考主题“已解决：iMX8MP IBIS 型号与 Hyperlynx 一起使用 - NXP 社区” ，如果仍然需要帮助，请随时与我们联系。

Subject: i.MX 8M Plus Package Delay in HyperLynx and IBIS Hello, I am using the NXP i.MX 8M Plus (MIMX8ML8CVNKZAB) and the imx8mp_15x15_v2.ibs model for signal integrity and setup/hold timing analysis in HyperLynx 2604. The die-to-ball delays for the device are listed in Table 23 of the i.MX 8M Plus Hardware Developer’s Guide. I wonder whether these delays are included in the IBIS model and used by HyperLynx when it calculates setup and hold times. Can anyone confirm whether these package delays are automatically included in HyperLynx setup/hold timing calculations when using the IBIS model? I have the measurement location set to Die for the i.MX 8M Plus. Thank you. Buddika Re: Subject: i.MX 8M Plus Package Delay in HyperLynx and IBIS You can refer to the thread Solved: iMX8MP IBIS model to be used with Hyperlynx - NXP Community, if still need help contact us freely.

件名:HyperLynxおよびIBISでの i.MX 8M以上のパッケージ遅延 こんにちは、 私はNXP i.MX 8M Plus(MIMX8ML8CVNKZAB)とimx8mp_15x15_v2.ibsモデルを使って、HyperLynx 2604で信号の整合性やセットアップ・ホールドタイミング解析を行っています。 デバイスのダイ・ツー・ボール遅延時間は、 i.MX 8M Plusハードウェア開発者ガイドの表23に記載されています。これらの遅延はIBISモデルに含まれていて、HyperLynxがセットアップやホールド時間を計算する際に使っているのかもしれません。 IBISモデルを使う場合、これらのパッケージ遅延がHyperLynxのセットアップ/ホールドタイミング計算に自動的に含まれるかどうか、誰か確認できますか?i.MX 8M Plusの 測定位置は Die に設定しています。 よろしくお願いします。 ブッディカ Re: Subject: i.MX 8M Plus Package Delay in HyperLynx and IBIS Hyperlynx - NXPコミュニティで使用する場合は「解決済み:iMX8MP IBISモデル」Threadを参照してください。まだ助けが必要な場合は自由にお問い合わせください。

T1014 - 赤外線長さ測定の誤差 NXPの専門家の皆様、こんにちは。 元の記事へのリンクはこちらです： https://community.nxp.com/t5/T-Series/T1014-the-jtag-chain-does-not-contain-any-debuggable-cores/mp/2424033#M5509 さらに、jtag Diagnostics を有効にすると、ログに「IR の長さの測定エラー」と表示されるという情報も追加しておきます。 問題の根本原因の特定にご協力いただければ幸いです。よろしくお願いいたします。 Re: T1014- Error measuring IR length あなたをサポート  https://community.nxp.com/t5/T-Series/T1014-the-jtag-chain-does-not-contain-any-debuggable-cores/m-p/2424033#M5509

T1014 - the jtag chain does not contain any debuggable cores Hello experts of NXP: I suffered a problem "the jtag chain does not contain any debuggable cores" and "Failed to correctly configure the JTAG chain" when setting the Code Warrior TAP on a self developping T1014rdb board. Through the analysis, we confirmed that the JTAG chain is accessible by testing using ccs cmd, but can't get the debug core by the cmd "get_children" no matter reset the board or not: And another phenomenon we found is that we can't get the t1014 chip type in ccs, we can only get the t10xx, but we can get t1040: Currently the RCW loading method is by SPI Flash, we can get 0xaa55aa55 through MISO and the HRESET has successfully raised to 1.8V: Currently we don't have any further method to solve the issue and we still can't debug the T1014 board through Code Warrior TAP.  Please help to give suggestion to solve this issue, is the issue due to board bring up or IDE configuration, thanks. Re: T1014 - the jtag chain does not contain any debuggable cores  Hi @BowenLi1991 , Please kindly try the "ccs::config_chain t1040" instead of "ccs::config_chain t1014" Please try the commands below in the CCS with hard coded mode. (bin) 2 % delete all (bin) 3 % config cc cwtap (bin) 4 % show cc 0: CodeWarrior TAP (cwtap) CC software ver. {0.0} (bin) 5 % ccs::config_chain t1040 (bin) 6 % display ::ccs::get_config_chain Chain Position 0: T1040 (bin) 7 % ccs::reset_to_debug If the commands work well, please set the T1014 to your flash boot mode and run the command again. If all the commands work well. Please check the waveform of the PORESET_B, HRESET_B, RESET_REQ_B and ASLEEP follow the T1024RM, Figure 4-1. Power-on reset sequence Thanks June