[SPSDK][i.MX95] nxpele 读取公共熔丝失败 您好， 我正在研究如何在 IMX95 19x19 EVK 板上启用安全启动。我已经使用 SPSDK 成功对我的镜像进行了签名。现在，在写入熔丝之前，我想使用 `nxpele` 读取它们，但我遇到了以下错误。 ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-熔丝 --index 136 SPSDK解析错误：SPSDK：响应中的消息大小无效：0x4 请查看调试日志文件：/home/user/.local/state/spsdk/3.11.0/log/debug.log 获取更多信息 ``` 日志中显示以下内容： ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"响应中的消息 SIZE 无效：{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 调试：spsdk：***************************************************（自启动以来已耗时 206 毫秒，spsdk_logger.py:212） DEBUG:spsdk:* SPSDK 调试日志记录已启动 2026-09-03 15:58:44 * (自启动以来耗时 207 毫秒，spsdk_logger.py:213) 调试信息：spsdk：* SPSDK 版本：3.11.0* (自启动以来耗时 207 毫秒，spsdk_logger.py:215) 调试信息：spsdk：* Python 版本：3.14.4* (自启动以来耗时 207 毫秒，spsdk_logger.py:216) 调试：spsdk：* 操作系统版本：Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * （自启动以来耗时 208 毫秒，spsdk_logger.py:217） DEBUG:spsdk:* 最后一条命令：['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-熔丝', '--index', '136'] * (自启动以来已过去 208 毫秒，spsdk_logger.py:218) 调试：spsdk：***************************************************（自启动以来已运行 208 毫秒，spsdk_logger.py:219） 跟踪：spsdk.uboot.uboot：Uboot写入 -> 无效（自开始以来已耗时 210 毫秒， __init__ .py:50） 调试：spsdk.uboot.uboot：Uboot读取直到 <- => (自启动以来已过去 210 毫秒，uboot.py:271) 调试：spsdk.uboot.uboot：正在检查如果串口控制台因发送无效命令而打开：“无效\r\n未知命令‘无效’ - 请尝试‘帮助’\r\nu-boot=>”（自启动以来 224 毫秒，uboot.py:209） 调试：spsdk.utils.database：当前数据库指纹哈希值：f0f0598d4e6ae6c755d693693f232e30537cfb3b（自启动以来耗时 226 毫秒，database.py:1967） 调试信息：spsdk.utils.database：已加载从缓存读取数据库：/tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache（自启动以来耗时 226 毫秒，database.py:1976） 调试：spsdk.utils.misc：正在加载从 /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml 读取文本文件（自启动以来耗时 226 毫秒，misc.py:312） 信息：spsdk.ele.ele_comm：ELE通信器在 mimx9596 中使用 92800000 地址处的 196608 B 大小的缓冲区，版本：最新目标。 调试：spsdk.ele.ele_comm：ELE消息 0x92800000 0x30000 0602971788000000 (自启动以来已过去 245 毫秒，ele_comm.py:502) 跟踪：spsdk.uboot.uboot：Uboot写入 -> ele_message 0x92800000 0x30000 0602971788000000 (自开始以来耗时 246 毫秒， __init__ .py:50) 调试：spsdk.uboot.uboot：Uboot读取直到 <- => (自启动以来 246 毫秒，uboot.py:271) 调试：spsdk.ele.ele_comm：原始ELE消息输出： ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (自启动以来 256 毫秒，ele_comm.py:422) 调试：spsdk.ele.ele_comm：已剥离输出：060497e1d600000000000000（自启动以来耗时 256 毫秒，ele_comm.py:460） 调试：spsdk.apps.utils.utils：SPSDK：响应中的消息大小无效：0x4（自启动以来耗时 257 毫秒，utils.py:182） 回溯（最近一次调用）： 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py”，第 172 行，包装纸 retval = function(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，在 safe_main 函数的第 2189 行 sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1631 行，在__call__ 返回 self.main(*args,**kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1552 行，主线 rv = self.invoke(ctx) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 2032 行，在 invoke 中 返回 _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1415 行，在 invoke 中 返回 ctx.invoke(self.callback,**ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 910 行，在 invoke 中 返回回调函数(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py”，第 46 行，在 new_func 中 返回 f(get_current_context().obj, *args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，第 575 行，在 cmd_read_common_fuse 中 ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，第 588 行，在 ele_read_common_fuse 中 ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py”，第 519 行，在 send_message 函数中 msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”，第 1235 行，在 decode_response 中 super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”，第 346 行，在 decode_response 中 raise SPSDKParsingError(f"响应中的消息 SIZE 无效：{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 ``` 注：我使用的是 `SPSDK 3.11.0` 我已在 SPSDK 的 GitHub 页面上创建了一个 issue： https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614 非常感谢您的帮助。 谢谢！ BR， Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 嗨joanxie 我使用的是 Linux 电路板支持包 版本 LF6.18.20_2.0.0 (yocto wrynose) 以下是 nxpele get-info 的输出结果 $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 请问您执行此命令时使用的是哪个 EL 固件版本？让我再确认一下。

i.MX RT1176 – FlexIO2パラレル受信：達成可能な最大シフトクロックは？わずか約48 MSPSしか到達しなかった iMXR1176 SDK 25.09.00 Manifest 3.15.0 ゴール i.MX RT1176に搭載されているLTC2164 16ビットADCからデータを取得しています。データパスは次のとおりです。 LTC2164（フルレートCMOS出力）→FlexIO2（パラレルRX）→eDMA→外部SDRAM ハードウェアのセットアップ LTC2164フルレートCMOS出力モードで構成され、外部100MHz発振器(100MSPS、16ビット並列)でクロックされます。 ADCデータ出力D0–D15はGPIO_AD_00...GPIO_AD_15。 ADC CLKOUT+はGPIO_AD_30に接続され、FlexIOタイマークロック(外部ピンクロックソース)として使用されました。 ソフトウェアのセットアップ FlexIO2は並列レシーバとして構成され、データはシフター7にラッチされます。シフター7から>0は、DMA要求が主張される前に32バイトバッファリングされるようにチェーンされています。 kDmaRequestMuxFlexIO2Request0Request1によってトリガーされたeDMAは、ピンポン（スキャッター/ギャザー）モードで2つのTCDを使用します。各メジャーループ完了時、つまり16384サンプルごとに割り込みが発生します。 FlexIO2の機能クロック：120MHz。 バスクロック（eDMA/SEMC側）：240MHz。 問題 100 MSPS の場合、16384 サンプルの処理には163.84 µsかかるはずです。連続する 2 つの DMA 割り込み間の時間を測定 (GPIO トグル + オシロスコープ) すると、常に338 µsという結果が得られ、これは約 2.06 倍です。 これは約48 MSPSの実効持続レートに相当し、ボトルネックはADCやSDRAMではなくFlexIO側にあることを示唆している。 質問 RT1176の並列受信モードにおけるFlexIOの最大シフトクロック周波数に関する公式な文書はありますか？RMやデータシートにはそのような数値は見つかりませんでした。 タイマークロックのソースが外部ピンの場合、FlexIOの機能クロックと外部シフトクロックの比率はどのようになりますか？私のFlexIOクロック（120MHz）は、入力される100MHzクロックのわずか1.2倍ですが、それで十分でしょうか？それとも、入力同期ロジックには2倍または4倍が必要ですか？ ほぼ正確な×2の比率を考えると、これはFlexIOタイマーがクロックの両端で減少している(TIMMPの慣例)によるもので、タイマー比較値が実質的にスループットを半分に減らしているのではないでしょうか? この部分でのFlexIO + eDMAの最大現実的な持続スループットについてのガイダンスがあれば、非常に助かります。なぜなら、別のペリフェラルに移行するか外部FIFOに切り替えるかを判断するからです。 よろしくお願いいたします。 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached こんにちは、ご返信ありがとうございます。確かに望ましい性能は達成できましたが、Flexioペリフェラルの推奨クロック周波数を最大を超えたことでしかできませんでした。具体的には、120MHzでクロックを設定するのではなく、100MSpsの取得には200MHz以上のクロック速度が必要ですが、120MHz構成ではクロックエッジがミスされます。問題は、200 MHzで動作しているにもかかわらず(リファレンスマニュアルには最大120 MHzと記載されていますが)、温度条件や生産バッチごとに安定して動作する保証がないことです。 Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached こんにちは、@azed38 さん。 外部ピンをクロックソースとして使用した場合、わずかな同期レイテンシが発生することに注意してください。RMのセクション67.3.3.2によると、このレイテンシは0.5から1.5 FlexIOクロックサイクルの範囲です。 Habib_MS_1-1788818202534.pngHabib_MS_1-1788818202534.png FlexIOとDMAで達成可能な最大スループットに関しては、FlexIOとDMAの性能テストは存在しません。しかし AN12686 、FlexIOとDMAを用いた並列通信実装を示しているため、あなたのユースケースに関連する指針となるかもしれません。 BR ハビブ

MCXW727CMFTBT — 出厂空白设备上的 SWD 连接失败（2 台设备，故障相同） 我们无法与任何MCXW727CMFTBT 样品（2 个单元，定制板）建立 SWD 调试连接，而完全相同的探针/电缆/设置却能立即连接到其他方面完全相同的板（相同的原理图，相同的物料清单，只有 MCU 不同）上的 MCXW716C。 元件： MCXW727CMFTBT，HVQFN-48封装，日期代码9D2604，批号PF2R73.00；板：定制PCB（10引脚Cortex调试SWD，无ISP按钮），出厂空白/从未编程； SDK： MCUXpresso SDK 26.06.00 — 应用程序构建/链接正常，故障仅在调试连接阶段出现。 症状 使用 NXP LinkServer 25.12.83 和正版 SEGGER J-Link Plus 均出现完全相同的故障：   LinkServer: Error: Wire Ack Fault - target connected? Ed:02: Failed on connect: Ee(42). No connection to chip's debug port J-Link: device MCXW727C_M33_0 / connect (VTref correctly read at 3.025V) ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF LinkServer 自身的 MCXW7XX 预连接脚本 (LS_preconnect_MCXW7XX.scp) 会自动发出调试会话请求 — 但仍然失败。nxpdebugmbox (SPSDK) 手动启动调试会话也失败，出现相同的 WIRE ACK FAULT 错误。 已经排除 探头/电缆/适配器：已确认工作正常（同样的配置连接到MCXW716C也没问题） MCU 端的 VDD_IO / P3V3：~3.3V，正确 SWDIO/SWDCLK 连续性：良好 VDD_CORE（内部 低压差线性稳压器(LDO)）：1.065V，在范围内 RESET_b 处于静止状态，电缆拔出：读取0V而不是预期的内部上拉 ~3.3V（参考）。手册第22.3.1节）— 两个单元 连接尝试期间，强制外部将 RESET_b 设置为 3.3V（VTref 读取正确为 3.025V）：无变化，仍然失败，并出现相同的错误：DM-AP IDCODE 错误 0xFFFFFFFF 在两台独立的物理设备/两块独立的电路板上均可复现。 相关帖子 这里报告了完全相同的错误（DM-AP IDCODE 0xFFFFFFFF），设备名称相同，但情况不同（板卡工作正常，但在擦除/重新编程周期后损坏）： FRDM-MCXW72 不再连接。我们的设备从未进行过任何刷机，因此如果像该帖子所暗示的那样与 NBU/核心状态有关联，那么它显然也会影响客户从未触碰过的设备。 问题 对于早期生产的 MCXW727CMFTBT（批号 PF2R73.00），是否存在任何已知的勘误/启动配置要求/默认生命周期状态，导致在标准调试邮箱程序之外的空白设备上阻止 SWD 操作？ 两个单元的 RESET_b 在静止状态下读数均为 0V（与文档中记录的内部上拉电阻相反）——是该批次产品的制造问题，还是上电时会有其他因素驱动该引脚？ 针对这种情况，有没有不需要基于UART的ISP（我们的板子没有板载USB-UART桥接器）的推荐恢复方法？ 乐意根据要求提供完整日志、示波器捕获或其他任何有用的信息。 协议：BLE -> 连接性 协议：Thread Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 感谢您的快速跟进！ 为了澄清，我们使用两种探针分别进行了测试，每种探针都使用各自合适的工具——没有将 LinkServer 与 J-Link 探针混用： NXP MCU-Link Pro ，通过LinkServer 25.12.83访问，通过 MCUXpresso for VS Code 调试/闪存集成（它会在底层启动 LinkServer 的 gdbserver/flash-programmer）。这是我们日常的正常工作安排。 结果：线路确认故障 - 目标已连接？/ Ed:02: 连接失败: Ee(42)。无法连接到芯片的调试端口，即使 LinkServer 自动运行其 MCXW7XX 特定的预连接脚本（LS_preconnect_MCXW7XX.scp，该脚本会发出调试会话请求）时也是如此。 一个独立的、正品的SEGGER J-Link Plus （固件 V11.00）+ J-Link Adapter CortexM（20 针 → 10 针 0.05 英寸），通过J-Link Commander V9.74直接访问（而不是通过 LinkServer）。 结果：错误：检测到错误的 DM-AP IDCODE：连接时为 0xFFFFFFFF，VTref 已正确读取为 3.025 V。 我们专门进行了第二次测试，以排除任何 LinkServer/MCU-Link 特有的问题。使用完全相同的 J-Link Plus + 适配器 + 电缆 + 实验室电源设置，仅将目标板更换为我们的 MCXW716C 型号（PCB 相同，只有 MCU 不同）， J-Link Commander 连接成功并识别出 Cortex-M33 内核——因此确认探针、电缆、适配器和工具工作正常；故障似乎是 MCXW727C 部件/板特有的。 我们还没有专门尝试过 J-Flash 或 LinkFlash，只尝试过 J-Link Commander（连接）和 LinkServer 的内置“调试”和“恢复”闪存编程器模式——如果这有助于进一步缩小问题范围，我们很乐意尝试其中任何一个。 与我们联系，如果需要提供任何其他信息或日志。 顺祝商祺！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ，希望你一切都好。 为了更好地了解您观察到的现象，请您确认一下，在每种情况下，您是否都使用了外部 J-Link 调试器？或者您是否也尝试过使用 MCU-Link Pro？ 此外，请提供您用于通过 SWD 访问的工具（LinkFlash、J-Flash、J-Link Commander），因为 Linkserver 是用于启动和管理 NXP 调试探针的 GDB 服务器的实用程序（例如，因此，MCU-Link Pro），预计 Linkserver 不会检测到 J-Link 探针。J-Link Plus 探针只能与 J-Link Commander/J-Flash 工具一起被检测到和使用。

EB tresos 用の MCP サーバー 私はelectrobitが提供するMCPサーバー、またはEB Tresos用に開発されたAPIを探しています。

NXP S32M276CHABMKHSR VPRE output voltage range Hello,  I have a question about the VPRE output voltage range of NXP S32M276XX IC. I used external P-MOSFET voltage-regulator for VPRE in my design as below shows. Ted_Qiao_0-1788752795769.pngTed_Qiao_0-1788752795769.pngTed_Qiao_0-1788752795769.png When external P-MOSFET regulator is activated(set CONFIG-VPREEXT = 1), the output voltage of VPRE pin is around 7.0V; When external P-MOSFET regulator is not activated(set CONFIG-VPREEXT = 0, then internal regulator to be used), the output voltage of VPRE pin is around 6.3V. The status that I described is normal or not? What exactly output range is the VPRE in both status? By the way, In the datasheet, the typical output voltage of VPRE is 6.4V. Ted_Qiao_1-1788753322135.pngTed_Qiao_1-1788753322135.pngTed_Qiao_1-1788753322135.png Re: NXP S32M276CHABMKHSR VPRE output voltage range Hello @Ted_Qiao, The two regulators, one using the external ballast PMOS and the other using the internal ballast PMOS, are enabled by default. The external regulator has a slightly higher regulation point, so it is the only one active under normal conditions. The internal regulator becomes active only when the external regulator is disabled. The exact regulation points are not specified in the datasheet. Only a typical value of 6.4 V is provided for both the internal and external regulators. The actual regulation point depends on production variations and operating conditions. For example, on my EVB I measured approximately 6.2 V with the internal ballast PMOS and approximately 6.8 V with the external ballast PMOS. The absolute maximum rating for VPRE is 7.5 V, so the voltage you measured is well below this limit. BR, Daniel

HSE installation issues Help! I have written a routine for HSE firmware installation by referring to the official demo project. However, no data is present at the HSE installation address 0x007E0000 after I perform two resets. Does this mean the HSE installation has failed? 1131_0-1788746050565.png1131_0-1788746050565.png This is the ld file 1131_1-1788746137817.png1131_1-1788746137817.png This is the rewritten IVT vector 1131_2-1788746175542.png1131_2-1788746175542.png 1131_3-1788746225953.png1131_3-1788746225953.png 1131_4-1788746253844.png1131_4-1788746253844.png Finally, I attach my HSE installation demo project. Re: HSE installation issues The S32 version is 3.6.8, the chip is S32K314, and the RTD version is 7.0.1 Re: HSE installation issues At first you should see HSE_CONFIG_GPR3 register (0x4039C028) to find out whether your HSE FW is installed or not. 

HSE安装问题 帮助！我参考官方演示项目编写了一个 HSE 固件安装程序。但是，在执行两次 RESET 后，HSE 安装地址 0x007E0000 处没有任何数据。这是否意味着 HSE 安装失败了？ 1131_0-1788746050565.png1131_0-1788746050565.png 这是 ld 文件 1131_1-1788746137817.png1131_1-1788746137817.png 这是重写的 IVT 向量 1131_2-1788746175542.png1131_2-1788746175542.png 1131_3-1788746225953.png1131_3-1788746225953.png 1131_4-1788746253844.png1131_4-1788746253844.png 最后，我附上我的 HSE 安装演示项目。 Re: HSE installation issues S32 版本为 3.6.8，芯片型号为S32K314，RTD版本为7.0.1。 Re: HSE installation issues 首先，您应该查看 HSE_CONFIG_GPR3 寄存器 (0x4039C028)，以确定您的 HSE 固件是否已安装。

i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached iMXR1176 SDK 25.09.00 Manifest 3.15.0 Goal I am acquiring data from an LTC2164 16-bit ADC on an i.MX RT1176. The data path is: LTC2164 (full-rate CMOS output) → FlexIO2 (parallel RX) → eDMA → external SDRAM Hardware setup LTC2164 configured in full-rate CMOS output mode, clocked by an external 100 MHz oscillator (so 100 MSPS, 16-bit parallel). ADC data outputs D0–D15 connected to GPIO_AD_00 … GPIO_AD_15. ADC CLKOUT+ connected to GPIO_AD_30, used as the FlexIO timer clock (external pin clock source). Software setup FlexIO2 configured as a parallel receiver, data latched into shifter 7; shifters 7->0 are chained so that 32 bytes are buffered before the DMA request is asserted. eDMA triggered by kDmaRequestMuxFlexIO2Request0Request1, using two TCDs in ping-pong (scatter/gather) mode. An interrupt is raised on each major loop completion, i.e. every 16384 samples. FlexIO2 functional clock: 120 MHz. Bus clock (eDMA / SEMC side): 240 MHz. Problem At 100 MSPS, 16384 samples should take 163.84 µs. Measuring the time between two consecutive DMA interrupts (GPIO toggle + scope), I consistently get 338 µs, i.e. a factor of ~2.06. This corresponds to an effective sustained rate of about 48 MSPS, which suggests the bottleneck is on the FlexIO side rather than the ADC or the SDRAM. Questions Is there a documented maximum shift clock frequency for FlexIO in parallel receive mode on the RT1176? I could not find any such figure in the RM or the datasheet. When the timer clock source is an external pin, what is the required ratio between the FlexIO functional clock and the external shift clock? My FlexIO clock (120 MHz) is only 1.2× the incoming 100 MHz clock — is that sufficient, or does the input synchronization logic require 2× or 4×? Given the almost exact ×2 ratio I observe, could this come from the FlexIO timer decrementing on both edges of the clock (TIMCMP convention), meaning my timer compare value effectively halves the throughput? Any guidance on the maximum realistic sustained throughput of FlexIO + eDMA on this part would be very helpful, since this determines whether I need to move to a different peripheral or an external FIFO. Thanks in advance. Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached Hello, thank you for your reply. I was indeed able to achieve the desired performance, but only by exceeding the maximum recommended clock frequency for the Flexio peripheral; specifically, instead of configuring the clock at 120 MHz, a clock speed greater than 200 MHz is required to achieve 100 MSps acquisition, whereas a 120 MHz configuration results in missed clock edges. The problem is that, even though it works at 200 MHz (despite the Reference Manual specifying a 120 MHz maximum), I have no guarantee of reliable operation under varying temperature conditions or across different production batches. Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached Hello @azed38,   Please keep in mind that when an external pin is used as the clock source, a small synchronization latency is introduced. According to Section 67.3.3.2 of the RM, this latency can range from 0.5 to 1.5 FlexIO clock cycles: Habib_MS_1-1788818202534.pngHabib_MS_1-1788818202534.png Regarding the maximum throughput achievable with FlexIO and DMA, there is not a performance test for the FlexIO  and DMA. However, you may find the AN12686 useful, as it demonstrates a parallel communication implementation using FlexIO and DMA, this may provide guidance relevant to your use case. BR Habib

i.MX RT1176 – FlexIO2 并行接收：可实现的最大时钟移位是多少？仅达到约 48 MSPS iMXR1176 SDK 25.09.00 清单 3.15.0 目标 我正在从 i.MX RT1176 上的 LTC2164 16 位 ADC 获取数据。数据路径为： LTC2164（全速率CMOS输出）→ FlexIO2（并行接收）→ eDMA → 外部同步动态随机存取存储器(SDRAM) 硬件设置 LTC2164 配置为全速率 CMOS 输出模式，由外部 100 MHz 振荡器提供时钟信号（即 100 MSPS，16 位并行）。 ADC 数据输出 D0–D15 连接到 GPIO_AD_00 … GPIO_AD_15。 ADC CLKOUT+ 连接到 GPIO_AD_30，用作 FlexIO 定时器时钟（外部引脚时钟源）。 软件设置 FlexIO2 配置为并行接收器，数据锁存到移位器 7；移位器 7->0 串联起来，以便在 DMA 请求钳位之前缓冲 32 字节。 eDMA 由 kDmaRequestMuxFlexIO2Request0Request1 触发，使用两个 TCD 以乒乓（分散/聚集）模式运行。每次主循环完成时都会引发中断，即每 16384 个样本一次。 FlexIO2 功能时钟：120 MHz。 总线时钟（eDMA / SEMC 侧）：240 MHz。 问题 在 100 MSPS 下，采集 16384 个样本需要163.84 µs 。通过测量两个连续 DMA 中断之间的时间（GPIO 切换 + 示波器），我始终得到338 µs ，即 ~2.06 倍。 这相当于大约48 MSPS的有效持续速率，这表明瓶颈在于 FlexIO 端，而不是 ADC 或 SDRAM。 问题 RT1176 上 FlexIO 在并行接收模式下是否有记录在案的最大移位时钟频率？我在参考手册或数据表中都找不到这样的数据。 当定时器时钟源为外部引脚时，FlexIO 功能时钟与外部移位时钟之间所需的比率是多少？我的 FlexIO 时钟 (120 MHz) 只是输入 100 MHz 时钟的 1.2 倍——这足够吗？还是输入同步逻辑需要 2 倍或 4 倍？ 鉴于我观察到的几乎精确的 ×2 比率，这是否可能是由于 FlexIO 定时器在时钟的两个边沿递减（TIMCMP 约定）造成的，这意味着我的定时器比较值实际上将吞吐量减半？ 任何关于 FlexIO + eDMA 在此部分上的最大实际持续吞吐量的指导都将非常有帮助，因为这决定了我是否需要迁移到不同的外设或外部 FIFO。 先行致谢。 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached 您好，谢谢您的回复。我确实达到了预期的性能，但这仅仅是通过超过 Flexio 外设的最大推荐时钟频率来实现的；具体来说，要达到 100 MSps 的采集速率，需要将时钟频率配置为 200 MHz 以上，而不是 120 MHz，而 120 MHz 的配置会导致时钟边沿丢失。问题是，即使它在 200 MHz 下工作（尽管参考手册规定最大频率为 120 MHz），我也无法保证在不同的温度条件下或不同生产批次之间可靠运行。 Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached 你好@azed38 ， 请注意，当使用外部引脚作为时钟源时，会引入较小的同步延迟。根据 RM 第 67.3.3.2 节，此延迟范围为 0.5 至 1.5 个 FlexIO 时钟周期： Habib_MS_1-1788818202534.pngHabib_MS_1-1788818202534.png 关于 FlexIO 和 DMA 可达到的最大吞吐量，目前还没有针对 FlexIO 和 DMA 的性能测试。不过，您可能会发现AN12686很有用，因为它演示了使用 FlexIO 和 DMA 的并行通信实现，这可能会为您的用例提供相关指导。 BR 哈比卜

NXP S32M276CHABMKHSR VPRE 出力電圧範囲 こんにちは、 NXP S32M276XX ICのVPRE出力電圧範囲について質問があります。 私はVPRE用に外部のP-MOSFET電圧レギュレータを使用しました。以下に示す通りです。 Ted_Qiao_0-1788752795769.pngTed_Qiao_0-1788752795769.pngTed_Qiao_0-1788752795769.png 外部P-MOSFETレギュレータがアクティブ化されている場合（CONFIG-VPREEXT = 1に設定）、VPREピンの出力電圧は約7.0Vになります。 外部P-MOSFETレギュレータがアクティブでない場合（CONFIG-VPREEXT = 0に設定し、内部レギュレータを使用する場合）、VPREピンの出力電圧は約6.3Vです。 私が説明した状態は正常でしょうか、それとも異常でしょうか？VPREの出力範囲は、両方の状態において具体的にどのくらいですか？ ちなみに、データシートによると、VPREの標準出力電圧は6.4Vです。 Ted_Qiao_1-1788753322135.pngTed_Qiao_1-1788753322135.pngTed_Qiao_1-1788753322135.png Re: NXP S32M276CHABMKHSR VPRE output voltage range こんにちは、 @Ted_Qiao さん。 外部バラストPMOSを使用するレギュレータと内部バラストPMOSを使用するレギュレータの2つは、デフォルトで有効になっています。 外部レギュレーターはやや高いレギュレーターポイントを持っているため、通常条件下では唯一作動します。内部レギュレータは、外部レギュレータが無効になっている場合にのみ有効になります。 具体的な調整ポイントはデータシートに記載されていません。内部レギュレータと外部レギュレータの両方において、標準値として6.4Vのみが供給されます。 実際の調整点は、生産量の変動や操業条件によって異なります。 例えば、私のEVBでは、内蔵バラストPMOSを使用した場合、約6.2V、外部バラストPMOSを使用した場合、約6.8Vの電圧を測定しました。 VPREの絶対最大定格は7.5Vなので、あなたが測定した電圧はこの限界を大きく下回っています。 BR、ダニエル

S32K31XEVB-Q100 (S32K311)“锁定设备”/首次调试时提示调试身份验证 ID 代码 我刚收到一块新的S32K31XEVB-Q100板，并第一次将 Segger J-Link 连接到它上面（通过外部 10 针 SWD 接头，而不是板载调试器）。这是一个全新的开发板——目前我只尝试过一个默认的RTD生成的项目（Mcal.h）。包括，库存为空 main() 循环），与 HSE 或网络安全无关。 连接后，SEGGER J-Flash 和 S32 Design Studio 都显示设备已锁定，并弹出“ID 代码”身份验证提示：   - Unknown SDA AP Id detected: 0x00000000 - Connect failed. Trying connect under reset... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - Unlocking device if necessary... - Locked device detected. Proceeding with the unlock procedure... J-Flash 然后询问：“请输入身份验证所需的 ID 代码”（32 个十六进制数字或 16 个 ASCII 字符）。我从未在这个芯片上设置过密码。 设置：MCU 在 J-Flash 中正确显示为 NXP S32K311 / Cortex-M7，SWD @ 4000 kHz，J-Flash V9.74，J-Link V9.74/V9.26。作为对比，我的 S32K144 EVB 与同一个 J-Link 配合使用一切正常——那里从未出现过这样的提示，据我了解，这是因为 S32K1 和 S32K3 使用了非常不同的安全模型。 J-Flash 然后询问：“请输入身份验证所需的 ID 代码”（32 个十六进制数字或 16 个 ASCII 字符）。我从未在这个芯片上设置过密码。 设置：MCU 在 J-Flash 中正确显示为 NXP S32K311 / Cortex-M7，SWD @ 4000 kHz，J-Flash V9.74，J-Link V9.74/V9.26。作为对比，我的 S32K144 EVB 与同一个 J-Link 配合使用一切正常——那里从未出现过这样的提示，据我了解，这是因为 S32K1 和 S32K3 使用了非常不同的安全模型。 我找到了之前关于 S32K311 出现相同症状的帖子，其中 NXP 支持解释说 K3 没有批量擦除不安全路径（与 K1 不同），并指出 HSE_B 固件参考手册（通过安全文件）用于恢复。 向社区/恩智浦提出的问题： 有没有其他人见过全新到货的 S32K31XEVB-Q100 已经像这样被锁定调试状态的情况？这是某些批次产品中已知的工厂测试瑕疵吗？ 评估板（而非量产芯片）是否有已记录的默认/恢复密码？ 请问如何申请获取 HSE_B 固件参考手册？ 此致 任何支持都将不胜感激：

S32K31XEVB-Q100 (S32K311) "Locked device" / Debug Authentication ID Code prompt on first debug I just received a new S32K31XEVB-Q100 board and connected a Segger J-Link to it for the very first time (via the external 10-pin SWD header, not the onboard debugger). This is a completely fresh board — the only thing I tried so far is a default RTD-generated project (Mcal.h include, stock empty main() loop), nothing related to HSE or security. On connecting, both SEGGER J-Flash and S32 Design Studio report the device as locked and pop up an "ID Code" authentication prompt:   - Unknown SDA AP Id detected: 0x00000000 - Connect failed. Trying connect under reset... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - Unlocking device if necessary... - Locked device detected. Proceeding with the unlock procedure... J-Flash then asks: "Please input the ID Code required for the authentication" (32 hex digits or 16 ASCII chars). I've never set a password on this chip. Setup: MCU shows correctly as NXP S32K311 / Cortex-M7 in J-Flash, SWD @ 4000 kHz, J-Flash V9.74, J-Link V9.74/V9.26. For comparison, my S32K144 EVB works fine with the same J-Link — no such prompt ever appears there, which I understand is because S32K1 and S32K3 use very different security models. J-Flash then asks: "Please input the ID Code required for the authentication" (32 hex digits or 16 ASCII chars). I've never set a password on this chip. Setup: MCU shows correctly as NXP S32K311 / Cortex-M7 in J-Flash, SWD @ 4000 kHz, J-Flash V9.74, J-Link V9.74/V9.26. For comparison, my S32K144 EVB works fine with the same J-Link — no such prompt ever appears there, which I understand is because S32K1 and S32K3 use very different security models. I found earlier thread with the same symptom on an S32K311, where NXP support explained there's no mass-erase-unsecure path for K3 (unlike K1) and pointed to the HSE_B Firmware Reference Manual (via Secure Files) for recovery. Questions for the community / NXP: Has anyone else seen a brand-new S32K31XEVB-Q100 arrive already debug-locked like this? Is this a known factory-test artifact on some batches? Is there a documented default/recovery password for evaluation boards specifically, as opposed to production silicon? Any pointers on requesting the HSE_B Firmware Reference Manual? Regards Any support will be appreciated:

[SPSDK][i.MX95] nxpele read-common-fuse fails Hi, I'm working on enabling secure boot on an IMX95 19x19 EVK board. I've successfully signed my images using the SPSDK. Now, before writing the fuses, i wanted to read them using `nxpele` but i'm getting the error below. ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-fuse --index 136 SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 See debug log file: /home/user/.local/state/spsdk/3.11.0/log/debug.log for more info ``` and in the logs it says the following: ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"Message SIZE in response is invalid: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 DEBUG:spsdk:*************************************************** (206ms since start, spsdk_logger.py:212) DEBUG:spsdk:* SPSDK DEBUG LOGGING STARTED 2026-09-03 15:58:44 * (207ms since start, spsdk_logger.py:213) DEBUG:spsdk:* SPSDK version: 3.11.0 * (207ms since start, spsdk_logger.py:215) DEBUG:spsdk:* Python version: 3.14.4 * (207ms since start, spsdk_logger.py:216) DEBUG:spsdk:* OS version: Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * (208ms since start, spsdk_logger.py:217) DEBUG:spsdk:* Last command: ['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-fuse', '--index', '136'] * (208ms since start, spsdk_logger.py:218) DEBUG:spsdk:*************************************************** (208ms since start, spsdk_logger.py:219) TRACE:spsdk.uboot.uboot:Uboot WRITE -> invalid (210ms since start, __init__.py:50) DEBUG:spsdk.uboot.uboot:Uboot READ UNTIL <- => (210ms since start, uboot.py:271) DEBUG:spsdk.uboot.uboot:Checking if the serial console is open by sending invalid command: "invalid\r\nUnknown command 'invalid' - try 'help'\r\nu-boot=> " (224ms since start, uboot.py:209) DEBUG:spsdk.utils.database:Current database finger print hash: f0f0598d4e6ae6c755d693693f232e30537cfb3b (226ms since start, database.py:1967) DEBUG:spsdk.utils.database:Loaded database from cache: /tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache (226ms since start, database.py:1976) DEBUG:spsdk.utils.misc:Loading text file from /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml (226ms since start, misc.py:312) INFO:spsdk.ele.ele_comm:ELE communicator is using 196608 B size buffer at 92800000 address in mimx9596, Revision: latest target. DEBUG:spsdk.ele.ele_comm:ELE msg 0x92800000 0x30000 0602971788000000 (245ms since start, ele_comm.py:502) TRACE:spsdk.uboot.uboot:Uboot WRITE -> ele_message 0x92800000 0x30000 0602971788000000 (246ms since start, __init__.py:50) DEBUG:spsdk.uboot.uboot:Uboot READ UNTIL <- => (246ms since start, uboot.py:271) DEBUG:spsdk.ele.ele_comm:Raw ELE message output: ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (256ms since start, ele_comm.py:422) DEBUG:spsdk.ele.ele_comm:Stripped output: 060497e1d600000000000000 (256ms since start, ele_comm.py:460) DEBUG:spsdk.apps.utils.utils:SPSDK: Message SIZE in response is invalid: 0x4 (257ms since start, utils.py:182) Traceback (most recent call last): File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py", line 172, in wrapper retval = function(*args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 2189, in safe_main sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1631, in __call__ return self.main(*args, **kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1552, in main rv = self.invoke(ctx) File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 2032, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1415, in invoke return ctx.invoke(self.callback, **ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 910, in invoke return callback(*args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py", line 46, in new_func return f(get_current_context().obj, *args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 575, in cmd_read_common_fuse ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 588, in ele_read_common_fuse ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py", line 519, in send_message msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py", line 1235, in decode_response super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py", line 346, in decode_response raise SPSDKParsingError(f"Message SIZE in response is invalid: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 ``` Note: i'm using `SPSDK 3.11.0` I've created an issue also on SPSDK's github page https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614  Any help is very much appreciated.  Thank you, BR, Re: [SPSDK][i.MX95] nxpele read-common-fuse fails Hi joanxie I'm using linux BSP version LF6.18.20_2.0.0 (yocto wrynose) And here is the output of nxpele get-info $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails could you tell me what ele fw version do you use for this command? let me double check it

NXP-PORT GMBHによるIMX94キットのポーティング こんにちは、 NXP-PORT GMBHのPROFINETスタックをIMX94キットに移植する予定です。 資料を探してみましたが、ほとんどがRT1180に関するものでした。 LinuxやM7、M33コアへの移植に関するドキュメントを教えてください。 ありがとう ビジャイ・ラナ ACLデジタル Re: NXP-PORT GMBH Porting on IMX94 Kit 以下のリンクをご参照ください。 https://www.nxp.com/design/design-center/software/development-software/software-for-industrial-networking/profinet-industrial-ethernet-protocol-software:PROFINET-INDUSTRIAL-COMMUNICATIONS-SOFTWARE?_gl=1*rqpmy3*_ga*MTk0NjI5NzAyNi4xNzg4NzQ0MDgx*_ga_WM5LE0KMSH*czE3ODg3NTg2ODkkbzIkZzEkdDE3ODg3NjM1MTYkajYwJGwwJGg5ODc1Nzg5NA .. Linuxルートでは、まずPROFINETFORLINUXFS、UM12408、UM12463、RN00389/RN00434、そしてPROFINETスタックライブラリパッケージから始めましょう。Linuxのファクトシートだけが、Linux用のPROFINETエンドポイントを明確に言及している唯一の情報源であり、その配信モデルはサポートNXPデバイス向けの事前コンパイル済みユーザー空間オブジェクトライブラリとプラットフォーム固有のドライバーソースとして説明されています。 i.MX94 上のM7/M33ルートについては、i.MX94 RM と PROFINET/GOAL/ICC ドキュメントを併用しますが、 AN13933 は参照パターンとしてのみ扱います。i.MX94はCortex-M7コア2基とCortex-M33コア2基を持ち、PROFINETを含む産業用イーサネットプロトコル向けに設計されていますが、Cortex-Mポーティングに関する詳細なアプリノートは、FreeRTOSとlwIPを使った8M Mini Cortex-M4 i.MX 専用です。

S32K31XEVB-Q100(S32K311)「ロックされたデバイス」/デバッグ認証IDコードプロンプトが最初のデバッグで表示されます 新しい S32K31XEVB-Q100 ボードを受け取り、初めてSegger J-Linkを接続しました(オンボードデバッガではなく、外部10ピンSWDヘッダー経由で)。これは完全に新しいボードで、今のところ試したのはデフォルトのRTD生成プロジェクト(Mcal.h)だけです含まれているのは、空のメインループで、HSEやセキュリティには関係ないということです。 接続すると、SEGGER J-FlashとS32 Design Studioの両方がデバイスをロックしたと報告し、「ID Code」認証プロンプトが表示されます。   - Unknown SDA AP Id detected: 0x00000000 - Connect failed. Trying connect under reset... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - Unlocking device if necessary... - Locked device detected. Proceeding with the unlock procedure... J-Flashは次に「認証に必要なIDコードを入力してください」(32桁の十六進数または16文字のASCII文字)を尋ねます。私はこのチップにパスワードを設定したことは一度もありません。 セットアップ:MCUはJ-Flash、SWD @ 4000 kHz、J-Flash V9.74、J-Link V9.74/V9.26でNXP S32K311 / Cortex-M7として正しく表示されます。比較のために、私のS32K144 EVBは同じJ-Linkで問題なく動作します。S32K1とS32K3はセキュリティモデルが大きく異なるため、そのようなプロンプトは一度も表示されません。 J-Flashは次に「認証に必要なIDコードを入力してください」(32桁の十六進数または16文字のASCII文字)を尋ねます。私はこのチップにパスワードを設定したことは一度もありません。 セットアップ:MCUはJ-Flash、SWD @ 4000 kHz、J-Flash V9.74、J-Link V9.74/V9.26でNXP S32K311 / Cortex-M7として正しく表示されます。比較のために、私のS32K144 EVBは同じJ-Linkで問題なく動作します。S32K1とS32K3はセキュリティモデルが大きく異なるため、そのようなプロンプトは一度も表示されません。 以前のスレッドで同じS32K311症状があり、NXPのサポートがK3には大量消去・アンセキュアパスはないと説明し(K1とは異なり)、回復のためにHSE_Bファームウェア**リファレンス・マニュアル**(Secure Files経由)を指し示していました。 コミュニティ/NXPへの質問： 新品のS32K31XEVB-Q100が、このようにデバッグロックされた状態で届いたのを見た人は他にいますか？これは一部の製造ロットで発生する、工場検査時の既知の不具合でしょうか？ 評価ボード専用のデフォルトやリカバリーパスワードは文書化されていますか?生産用シリコンとは違います。 HSE_Bファームウェアリファレンスマニュアルをリクエストする際のアドバイスはありますか? よろしくお願いします。 どんなサポートでも感謝します:

MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) We cannot establish an SWD debug connection to any of our MCXW727CMFTBT samples (2 units, custom board), while the exact same probe/cable/setup connects immediately to an MCXW716C on an otherwise identical board (same schematic, same BOM, only the MCU differs). Part: MCXW727CMFTBT, HVQFN-48, date code 9D2604, lot PF2R73.00 Boards: custom PCB (10-pin Cortex Debug SWD, no ISP button), factory-blank/never-programmed SDK: MCUXpresso SDK 26.06.00 — application builds/links fine, failure is purely at debug-connect stage Symptom Fails identically with both NXP LinkServer 25.12.83 and a genuine SEGGER J-Link Plus:   LinkServer: Error: Wire Ack Fault - target connected? Ed:02: Failed on connect: Ee(42). No connection to chip's debug port J-Link: device MCXW727C_M33_0 / connect (VTref correctly read at 3.025V) ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF LinkServer's own MCXW7XX pre-connect script (LS_preconnect_MCXW7XX.scp) does issue a Debug Session Request automatically — still fails. nxpdebugmbox (SPSDK) manual Start Debug Session also fails with the same WIRE ACK FAULT. Already ruled out Probe/cable/adapter: confirmed working (same setup connects fine to MCXW716C) VDD_IO / P3V3 at the MCU: ~3.3V, correct SWDIO/SWDCLK continuity: good VDD_CORE (internal LDO): 1.065V, in range RESET_b at rest, cable unplugged: reads 0V instead of expected internal-pull-up ~3.3V (Ref. Manual §22.3.1) — on both units RESET_b forced externally to 3.3V during connect attempt (with VTref correctly read at 3.025V): no change, still fails with the same Wrong DM-AP IDCODE 0xFFFFFFFF Reproducible on 2 separate physical units / 2 separate boards Related thread Same exact error (Wrong DM-AP IDCODE 0xFFFFFFFF) reported here on the same device name, though in a different scenario (board worked, then broke after an erase/reprogram cycle): FRDM-MCXW72 no longer connects. Our units have never been flashed at all, so if there's a link to NBU/core state as that thread suggests, it apparently can also affect units that were never touched by the customer. Questions Any known erratum / boot-config requirement / default life-cycle state for early-production MCXW727CMFTBT (lot PF2R73.00) that would block SWD on a blank device beyond the standard Debug Mailbox procedure? RESET_b reading 0V at rest (contrary to documented internal pull-up) on both units — fabrication issue with this lot, or something else expected to drive this pin at POR? Recommended recovery procedure for this exact case that doesn't require UART-based ISP (our board has no on-board USB-UART bridge)? Happy to provide full logs, oscilloscope captures, or anything else useful on request. Protocol: BLE -> connectivity Protocol: Thread Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Thank you for the quick follow-up! To clarify, we tested with both probes, each with its own appropriate tool — not mixing LinkServer with the J-Link probe: NXP MCU-Link Pro, accessed through LinkServer 25.12.83, via the MCUXpresso for VS Code debug/flash integration (which launches LinkServer's gdbserver/flash-programmer under the hood). This is our normal day-to-day setup. Result: Wire Ack Fault - target connected? / Ed:02: Failed on connect: Ee(42). No connection to chip's debug port, including when LinkServer automatically runs its MCXW7XX-specific pre-connect script (LS_preconnect_MCXW7XX.scp, which issues a Debug Session Request). A separate, genuine SEGGER J-Link Plus (firmware V11.00) + J-Link Adapter CortexM (20-pin → 10-pin 0.05"), accessed through J-Link Commander V9.74 directly (not through LinkServer). Result: ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF on connect, with VTref correctly read at 3.025 V. We ran this second test specifically to rule out any LinkServer/MCU-Link-specific issue. Using this exact same J-Link Plus + adapter + cable + lab power supply setup, swapping only the target board for our MCXW716C variant (identical PCB, only the MCU differs), J-Link Commander connects successfully and identifies the Cortex-M33 core — so the probe, cable, adapter, and tool are confirmed working correctly; the failure appears specific to the MCXW727C part/board. We have not yet tried J-Flash or LinkFlash specifically, only J-Link Commander (connect) and LinkServer's built-in "debug" and "resurrect" flash-programmer modes — happy to try either of those if it would help narrow this down further. Let us know if there's any additional information or logs that would be useful. Best regards! Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, hope you are doing well. In order to better understand the behavior you are observing, would you please confirm if for each case you are using an external J-Link debugger? Or have you tried also with an MCU-Link Pro? Additionally, please provide which tool (LinkFlash, J-Flash, J-Link Commander) you are using to access through SWD, as Linkserver is a utility for launching and managing GDB servers for NXP debug probes (e.g. MCU-Link Pro), therefore it is expected that a J-Link probe will not be detected by Linkserver. While the J-Link Plus probe will only be detected and usable along J-Link Commander/J-Flash tools.

S32K312: SWT0機能リセットエスカレーション、破壊リセットステータス、およびSRAM保持 NXPチームの皆様、こんにちは。 私はS32K312 Cortex-M7を使い、S32 Design StudioとAUTOSAR RTD 7.0.1 / AUTOSAR 4.9を使って作業しています。 現在、MC_RGMのリセット動作、特にSWT0機能リセット、機能リセットエスカレーション、破壊的リセット、SRAM保持、SBAF/リカバリ動作、およびPower IPリセットAPIのテストを行っています。 1. SWT0機能リセットエスカレーション 私はSWT0タイムアウトを使用して機能リセットを生成しています。 私のMC_RGMの設定は以下のとおりです。 MC_RGM_FRET_FRET((uint32)15U) MC_RGM_DRET_DRET((uint32)0U) 機能リセットカウンタが増加していることを確認しました。 SWT0機能リセット#1 -> FREC = 1 SWT0機能リセット#2 -> FREC = 2 ... SWT0機能リセット#14 -> FREC = 14 次のSWT0リセット後、FRECはクリア/リセットされますが、期待される動作は確認できませんでした。 DES[MC_RGM_FRE] = 1 私の質問は以下のとおりです。 SWT0_RSTは、S32K312のMC_RGM機能リセットエスカレーションカウンタ（FREC）に参加しますか？ FRECがFRET=15に達したとき、MC_RGM_FREを生成し、DES[MC_RGM_FRE]を設定すべきでしょうか？ エスカレーション直後、FES、DES、FREC、FRET、Power_Ip_GetResetReason() には具体的にどのような値が期待できるでしょうか？ SWT0がFRETエスカレーションに参加するために、追加の設定は必要ですか？ SBAFやリカバリーハンドリングはFRETのエスカレーションに支障をきたすことはありますか? SWT0/FRETの上昇に関連する既知の不具合やS32K312の挙動はありますか？ アプリケーションを継続的に実行すると、15回目の機能リセット後にアプリケーションやデバッガが停止し、期待される破壊的なリセットを観察できません。これがリセットシーケンス、SBAFリカバリ、またはデバッガに関連しているかどうかを知りたいです。 2.すべてのSWT0機能リセットを破壊的なものにしたい テスト目的で、以下のことも達成したいと考えています。 SWT0タイムアウト ↓ 機能リセット ↓ 即時破壊リセット 15回も機能リセットを待つ代わりに。 以下の設定で実現できますか: FRET = 1U; 具体的には： FRET = 1 の場合、最初の適格な SWT0 機能リセットが破壊的なリセットにエスカレートしますか？ MC_RGMの追加設定は必要ですか？ SWT0は、このエスカレーションの対象となる情報源として確実に認められるのでしょうか？ SBAFや回復行動はこれに影響を与えるのでしょうか? これはRTD 7.0.1の設定で直接サポートされていますか？ 3. SRAMデータは、機能リセットのたびに消去されます。 私の理解では、S32K3xxリファレンスマニュアルでは、SRAMやシステムメモリは機能リセット後も保持されるべきです。 SRAMテスト変数を作成しました。 #define SRAM_TEST_ADDR ((volatile uint32_t *)0x204007d4U) そして、それを使って機能リセット後のデータ保持状況を確認する。 しかし、機能リセット後にSRAMデータが消去/ゼロに書き換えられていることを確認しました。 私の質問は以下のとおりです。 機能リセットの際にハードウェアがSRAMを保持し、その後ソフトウェアによって上書きされるのでしょうか? S32K312において、機能リセット後も内容が確実に保持されるSRAM領域はどれですか？ 関数リセットを通じてその内容を保持するために、SRAMに変数を配置する推奨される方法は何ですか? 専用の.noinitファイルを使うべきでしょうか？または、保持されたSRAMセクション？ データ保持に必要なMC_RGM/SRAMの特定の構成はありますか？ 機能リセット間でアプリケーションデータを保持するための推奨されるRTD 7.0.1の方法は何ですか? 4. 直接ソフトウェア破壊的リセット また、Power IPを使って直接的なソフトウェア破壊リセットもテストしています: Power_Ip_Init(&Power_Ip_HwIPsConfigPB); gVar= Power_Ip_GetResetReason(); for (count = 0; count < 10125000; count++); Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB); 現在のMC_RGM構成には以下が含まれます。 static const Power_Ip_MC_RGM_ConfigType Power_Ip_MC_RGM_ConfigPB = ヤージュ (MCU_DEST_RESET) ... MC_RGM_FRET_FRET((uint32)15U) MC_RGM_DRET_DRET((uint32)0U) }; 破壊的なリセットが発生するが、デバッガーは通信を繰り返し失い、再確立する。 次のようなメッセージを見かけます。 情報: DAP IDCODE = 0x6BA02477 情報：DAPの電源投入に成功しました。DP CTRL/STAT = 0xF0000000 複数回繰り返され、続いて次のもの： 割り込みコマンドを受信しました。執行を停止します。 理解したいのは以下の点です。 破壊的なリセット中に、DAPの再接続が繰り返し発生することは想定されていますか？ 破壊リセットシーケンス中にCortex-M7に具体的に何が起こるのでしょうか? 破壊的なリセット後、CPUはいつ再び使用可能になりますか？ 単一のソフトウェア破壊リセットをデバッグする推奨される方法は何ですか? 5. Power_Ip_PerformReset() 前のブレークポイント挙動 直前にブレークポイントを確実に到達することはできません: Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB); APIの前に遅延を設定し、デバッガがアクセスを得るのに十分な時間があると期待していました。 場合によっては、ターゲットを手動で一時停止してから実行を再開した後に初めてブレークポイントに到達することがあります。 理解したいのは以下の点です。 リセットAPIの前に遅延があるのに、なぜデバッガはブレークポイントを見逃すのでしょうか? これは、ターゲットが繰り返しリセットされ、デバッガーがDAP経由で再接続されることに関係していますか？ 破壊的なリセットの直前や直後にCPUをキャッチする推奨される方法はありますか? RTDのDISABLE_DEBUGGER_TRAPオプションはこの動作に関係していますか？ 6. Power IPの初期化とPower_Ip_SetMode() 私のRTDは以下を提供します： void Power_Ip_Init( const Power_Ip_HwIPsConfigType *HwIPsConfigPtr); void Power_Ip_SetMode(const Power_Ip_ModeConfigType *ModeConfigPtr); void Power_Ip_PerformReset( const Power_Ip_HwIPsConfigType *HwIPsConfigPtr ); Power_Ip_ResetType Power_Ip_GetResetReason(void); Power_Ip_RawResetType Power_Ip_GetResetRawValue(void); 現在使用しているもの： Power_Ip_Init(&Power_Ip_HwIPsConfigPB); そして： gVar = Power_Ip_GetResetReason(); 私のモード設定はPOWER_IP_RUN_MODEです。 以下の点についてご説明をお願いします。 Power IPリセットAPIを使用する前に、Power_Ip_Init(&Power_Ip_HwIPsConfigPB)は正しい初期化方法でしょうか？ ソフトウェアの機能的/破壊的リセットテストにはPower_Ip_SetMode()が必要ですか? 選択したモードがPOWER_IP_RUN_MODEなら、このリセットテストでPower_Ip_SetMode()を省略してもいいですか? RTD 7.0.1を使って、ソフトウェアの機能リセットとソフトウェア破壊リセットの設定をどうすればよいですか? 環境 MCU:S32K312 コア:Cortex-M7 S32DS:S32 Design Studio AUTOSAR:4.9 RTD: 7.0.1 リセット元: SWT0 フレット: 15 DRET: 0 試験用の申請書を全部ご用意できます、Power_Ip_PBcfg.c。リンカー構成、MC_RGMレジスタキャプチャ、および必要に応じてデバッガーログ。 よろしくお願いします。 Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、 @Sharif417 さん。 1. SWT0機能リセットエスカレーション SWT0_RSTdoes S32K312 FRECに参加し、FRECが15に達するとDES[MC_RGM_FRE]が設定されます。Power_Ip_GetResetReason()を呼び出して「MCU_MC_RGM_FRE_RESET」を返すことで読み取れるはずです。 降格されていない機能リセット源(MCRGM.を通じて)はFERD は FREC のインクリメンションの対象となります。 Power_Ip_Init()はMC_RGMをクリアするので覚えておいてください。DES(値を保存した後)なので、電源モジュールを初期化する前にレジスタ値を取得するか、リセット理由を読み込むようにしてください。 回復モードは、閾値が>8の場合、回復モードがデフォルトで「8」に設定されているため、これに影響を与える可能性があります。sBAFはFRETではなくDRETにも干渉することがあります .「0」の場合、0xFに変わるのがわかります:   Julin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.png アプリケーションを継続的に実行すると、15回目の機能リセット後にアプリケーションやデバッガが停止し、期待される破壊的なリセットを観察できません。これがリセットシーケンス、SBAF復旧、またはデバッガに関連しているのか知りたいです。 デバッガを接続したままにしようとする代わりに、15回目の機能リセット後に接続を試みるか、UARTなどでリセット理由を印刷してみることはできますか? 2. すべてのSWT0機能リセットを破壊的なものにしたい はい、FRET=1であれば、すべての機能リセットで破壊リセットを発行するのに十分です。 追加のMC_RGMは不要です。 sBAF/リカバリーモードはこれに影響を与えないはずです。 はい、POWER モジュール -> 「モジュール設定」 -> 「McuResetConfig」 -> 「機能リセットエスカレーション閾値」で直接設定できます 3. SRAMデータは、機能リセットのたびに消去されます。 その通りです。SRAMは機能リセット後も保持されます。 S32K3は、派生モデルによって、スタンバイRAMとして16KB、32KB、または最大64KBを提供する場合があります。 スタンバイRAMを通じて変数を配置・使用する方法の例をいくつか見つけることができます: [RTD600 MCAL & IP]S32K3 低消費パワーマネージメントANおよびデモ S32K3の低消費電力管理ANとデモ 例：S32K312スタンバイモード、スタンバイRAMおよびPAD（DS3.5 RTD300を維持） スタンバイRAMがクリア/書き換えられる理由は、デフォルトのstartup_cm7.sによるものです。S32DSによって提供される機能は、リセット理由（POR、破壊的、機能的）に関係なく、SRAM全体を初期化します。機能リセットが発生した際に、割り当てられたスタンバイRAMをSRAMの初期化がスキップするように修正する必要があります。以下のコミュニティ投稿を参照してください: S32K311 スタンバイ RAM 保持。 4. 直接ソフトウェア破壊的リセット はい、MCUが機能的/破壊的リセットを発行されると、デバッグサブシステムとクロックはすべて再初期化されるため、デバッガは再びDAPアクセスを再交渉しなければなりません。 破壊的なリセットを行うと、一部のモジュールを除いて、チップの大部分がリセットされます。機能リセットを行うと、すべての通信ペリフェラルやコアがリセットされます。通信プロトコルの健全性は保証されておらず、リセット後に再初期化されることが前提とされています。 接続を維持しようとする代わりに、デバッガの「ターゲットにアタッチ」オプションを使うことができます: Julin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.png 5. Power_Ip_PerformReset() 前のブレークポイントの動作 おそらく再接続のウィンドウを見落としているだけです。for()ループを使う代わりに、フラグはデバッガで再接続した後に手動で変更する変数であるwhile(flag)を使い、「Expressions」タブから使うことができます。 6. Power IPの初期化とPower_Ip_SetMode() はい、Power APIを使用する前にPower_Ip_Init()を呼び出す必要があります。 そうすることをお勧めします。リセットはPower_Ip_PerformReset()を通じて行うことができますが、破壊的リセットか機能リセットのどちらかをMcuResetConfigコンテナ内で設定できます。代わりに、機能リセット用と破壊リセット用2つのパワーモードを宣言できます。次に、Power_Ip_SetMode(Functional_Reset) または Power_Ip_SetMode(Destructive_Reset) を呼び出します。 省略しても構いませんが、すべてのモジュールが正しくゲート化・設定されているか確認するためにPower_Ip_SetMode(RUN_MODE)を呼び出すと良いでしょう。もしプロジェクトに不要であれば省略しても構いません。 A6.2を参照してください。 簡単なテストを作成し、FRET=1を設定し、Power_Ip_SetMode( ) APIを通じて機能リセットを行うと報告FRE_RESET確認できました: Julin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.png よろしくお願いします、 ジュリアン Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、ジュリアンさん。 ご説明いただきありがとうございます。 S32K312で再度テストを行ったので、2つの点について明確にしておきたいと思います。完全なプロジェクトフォルダを添付しておきますので、設定を確認して動作を再現できます。 1. SWT0機能リセットエスカレーション 設定しました： FRET = 15U;DRET = 0U; そして、 125ミリ秒のタイムアウトを設定したSWT0を使用して、機能リセットを生成します。 機能リセットのたびに FREC が増加しているのが観察できます: SWT0 reset #1 -> FREC = 1 SWT0 reset #2 -> FREC = 2 ... SWT0 reset #14 -> FREC = 14 しかし、次のSWT0機能リセットが発生し、 FRET = 15の閾値に達したときに、期待される破壊的リセット状態を観察することができません。 DES[MC_RGM_FRE] = 1 また、15回目の機能リセット後もMCUは動作を続け、予想される破壊的なリセット動作は見られません。私のSRAMテストパーティションに保存されているSRAMデータも、そのままの状態を保っています。 以下の方法でリカバリ動作を無効にしました。 IP_DCM_GPR->DCMRWP1 |= (3 << 22); 添付のプロジェクトを確認して、もう少し詳しく教えていただけますか: 15回目のSWT0機能リセット後、 DES[MC_RGM_FRE] = 1が観測されないのはなぜですか？ FRECがFRET = 15に達した後、MCUは確実に破壊的なリセットに入るべきでしょうか?破壊的なリセットが発生した場合、なぜテストパーティションにSRAMの内容が保持されるのでしょうか？ 他にMC_RGM/SBAFの設定で見落としているものはありますか？ 2. 機能リセットおよび破壊リセット後のSRAM保持 専用のSRAMパーティション／セクションを作成し、その領域にテストデータを保存しました。 SWT0機能リセットを繰り返してもSRAMの値が保持されることを確認しました。これは想定どおりです。 しかし、FRETエスカレーションによって破壊的なリセットが発生すると予想される15回目の機能リセット後でも、SRAMの値は依然として残っています。 また、直接的なソフトウェア破壊リセットも試しましたが、リセット後もSRAM値は保持されていました。 したがって、私の見解は以下のとおりです。 SWT0 functional reset ↓ SRAM value retained 15th functional reset / expected FRET escalation ↓ SRAM value still retained Direct software destructive reset ↓ SRAM value also retained このSRAMの挙動がS32K312上で予想されるものなのか、また私のSRAMテスト領域が破壊的なリセットを経ても保持されるメモリ領域にある可能性があるのか、教えていただけますか? リンカー構成、RTD構成、MC_RGM構成、SWT0構成、テストアプリケーションを含む S32K312プロジェクトフォルダ全体を添付していますので、実際のメモリ配置とリセット設定を確認できます。 再開まで今しばらくお待ちください。 Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、 @Sharif417 さん。 1. SWT0機能リセットエスカレーション 1. 15回目のSWT0機能リセット後、DES[MC_RGM_FRE] = 1が観測されないのはなぜですか？ 前述したように、Power_Ip_Init() APIはDESレジスタをクリアするため、リセット理由はPower_Ip_GetResetReason()を使用して読み取る必要があります。 2. FRECがFRET = 15に達した後、MCUは確実に破壊リセットに入るべきか?破壊的なリセットが発生した場合、なぜテストパーティションにSRAMの内容が保持されるのでしょうか？ はい。FRECがFRTで設定された閾値に達している限り、MCUは破壊的なリセットを発行すべきです。破壊的なリセットが行われていないか、変数の位置が間違っているかのどちらかです。 3. 他にMC_RGM/SBAFの設定で不足しているものはありますか？ いいえ。機能リセットエスカレーションの場合、FRETを設定するだけで十分です。 2. 機能リセットおよび破壊リセット後のSRAM保持 1. このSRAMの挙動がS32K312上で予想されるものか、またSRAMテスト領域が破壊的なリセットを経ても保持されるメモリ領域にある可能性があるのか、明確にしていただけますか? しかし、そうあるべきではありません。破壊的なリセットイベントの後、すべてのSRAMコンテンツは失われます。 直接的なソフトウェア破壊リセットをどのようにテストしているのか教えてもらえますか? プロジェクトで Power_Ip_PerformReset() API を使用している場合、それは破壊的ではなく機能的なリセットとして構成されています。 Julin_AragnM_0-1788891886849.pngJulin_AragnM_0-1788891886849.png 実は、値を保存してUARTで共有してテストしました。FRDM-A-S32K312はSW2で機能リセットを発行し、FRETは15に設定され、15回のSW機能リセット後にMCU_MC_RGM_FRE_RESETが生成されるのが見えます。これはRTD 6.0.0で発生しています。以下のログをご覧ください。 [RESET] Reason : MCU_F_EXR_RESET (RGM_FES F_FR0) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 1 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 2 [RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 1 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 2 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 3 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 4 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 5 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 6 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 7 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 8 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 9 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 10 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 11 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 12 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 13 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 14 [RESET] Reason : MCU_MC_RGM_FRE_RESET (RGM_DES F_DR6) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 1 RTD 7.0.1では、あなたが言及したのと同じ挙動が見えます(FREが破壊リセットを主張しなかったり、デバッグャが切断されたりするなど): [RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 1 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 2 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 3 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 4 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 5 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 6 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 7 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 8 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 9 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 10 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 11 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 12 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 13 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 14 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 0 これにより、RTD 6.0.0とRTD 7.0.1の間にPower ドライバにいくつかの違いがあり、それがこれらの症状の原因になっているのではないかと考えています。これが設定の問題なのかバグなのか特定できていません。分析の時間をいただき、必要なら社内チームに連絡してください。 よろしくお願いします、 ジュリアン

HSE設置に関する問題 ヘルプ！公式デモプロジェクトを参考に、HSEファームウェアのインストールルーチンを作成しました。しかし、2回のリセットを実行した後でも、HSEのインストールアドレス0x007E0000にはデータが存在しません。これは、HSE（健康・安全・環境）設備の設置が失敗したということでしょうか？ 1131_0-1788746050565.png1131_0-1788746050565.png これはldファイルです 1131_1-1788746137817.png1131_1-1788746137817.png これは書き換えられたIVTベクトルです 1131_2-1788746175542.png1131_2-1788746175542.png 1131_3-1788746225953.png1131_3-1788746225953.png 1131_4-1788746253844.png1131_4-1788746253844.png 最後に、HSE（環境・安全・衛生）導入デモプロジェクトを添付します。 Re: HSE installation issues S32版は3.6.8です。チップはS32K314で、RTDのバージョンは7.0.1です。 Re: HSE installation issues まず、HSE_CONFIG_GPR3レジスタ（0x4039C028）を確認して、HSEファームウェアがインストールされているかどうかを調べてください。

射频发生器 你好。我计划使用 NXP MRF101AN LDMOS 晶体管制作一个实验室用 13.56 MHz 射频发生器，并希望复现 NXP MRF101AN-13MHZ 参考电路。 在购买两台 MRF101AN 设备之前，我需要 MRF101AN-13MHZ 参考设计的完整文档，特别是原理图、包含制造商零件编号的物料清单、PCB/Gerber 或制造文件、元件布局图、空芯电感器详细信息、PCB 规格、铝底板/散热器图以及偏置/调谐说明。 请问您能否提供这些文件，或者指引我联系恩智浦半导体（NXP）相应的射频应用/支持工程师？ 我身在印度，打算通过印度的授权代理商采购元器件。 Re: RF Generator 你好， 请访问https://www.nxp.com/products/radio-frequency-rf/legacy-rf/legacy-rf-power/mrf101an-reference-circuits:MRF101AN-REFCirc 向下滚动到“设计文件”，您将找到 MRF101AN 13.56 MHz 参考电路设计文件。 请注意，NXP 提供的此设计文档包中不包含原理图。由于大多数射频设计对电路板布局都很敏感，因此这是我们的常规做法。因此，布局视图加上物料清单比单纯的原理图能提供更具可重复性的结果。如果需要，您可以自己使用布局图和物料清单绘制原理图。 希望这能帮到你！

RF Generator Hello. I am planning a laboratory 13.56 MHz RF generator using the NXP MRF101AN LDMOS transistor and would like to reproduce the NXP MRF101AN-13MHZ reference circuit. Before purchasing two MRF101AN devices, I need the complete documentation for the MRF101AN-13MHZ reference design, particularly the schematic, BOM with manufacturer part numbers, PCB/Gerber or fabrication files, component-placement drawing, air-core inductor details, PCB specification, aluminium baseplate/heatsink drawing, and bias/tuning instructions. Could you please provide these files or direct me to the appropriate NXP RF applications/support engineer? I am located in India and intend to source the components through authorized distributors in India. Re: RF Generator Hello, Please go to https://www.nxp.com/products/radio-frequency-rf/legacy-rf/legacy-rf-power/mrf101an-reference-circuits:MRF101AN-REFCirc Scroll down to Design files and you will find the MRF101AN 13.56 MHz Reference Circuit Design File. Please note that NXP documentation pack for this design does not include a schematic. It is our general practice since most RF designs are sensitive to board layout. Thus, the layout view plus BOM provides more reproducible results than a pure schematic. If you need, you can draw the schematic by yourself using layout and BOM. Hope this helps!