NXP UM11442、3.1.5.15項コピーなし、動作しません 皆さん、こんにちは。 UM11442 黙示録24章 段落 3.1.5.15 ゼロコピー 例 evkmimxrt1170_wifi_cli_cm7 コンパイル中でないこと、推奨されたプリプロセッサマクロフラグを使った場合、最初のエラー: < 未定義>> そこで次の定義を追加しました #define NETIF_RX_BUFFERS 8 でも今は <<エラー: 未定義型「struct nxp_wifi_device」の無効な使用>>  実際、使用された構造は例では定義されていません 例ではゼロコピー機能が不完全なので、UM11442の説明は適用されませんか? ゼロコピーをどうやってテストできますか? ありがとうございます。よろしくお願いいたします。 ピエロ Re: NXP UM11442, paragraph 3.1.5.15 Zero Copy, NOT working 現時点ではMIMXRT1170-EVKしか持っていません, SDK 26.06はインストールされていますが、EVKの例は以下の通りです。 「EVKmimxrt1170_wifi_cli_cm7」は「EVKBmimxrt1170_wifi_cli_cm7」とは異なります。 ドキュメントUM11442にはdoc UM11441への言及があり、doc UM11441 表1 5ページ 組み合わせ i.MX RT1170 EVK AW611 u-blox ジョディ W5 支持されていると宣言されます つまり、「evkmimxrt1170_wifi_cli_cm7」は実際にはWi-Fi Zero-Copyでは動作しないということですか? Re: NXP UM11442, paragraph 3.1.5.15 Zero Copy, NOT working こんにちは、 RT1170-EVKとRT1170-EVKBのどちらをお使いですか？ SDK 26.06でこれをテストし、ガイドで紹介されているマクロを使ってevkbmimxrt1170_wifi_cli_cm7例を使ってアプリケーションをうまく構築できました。 どのSDKバージョンを使っていますか? よろしくお願いいたします。 ダニエル。 Re: NXP UM11442, paragraph 3.1.5.15 Zero Copy, NOT working こんにちは、 正しい。EVKB SDKでテストしました。 RT1170-EVK用のSDK 26.06をどこで見つけたのか、またはどのようにインポートしたのか教えていただけますか? RT1170-EVKのリリースを調べましたが、SDKバージョン2.16.0しか見つかりませんでした。 よろしくお願いいたします。 ダニエル。

NXP UM11442，第 3.1.5.15 段零拷贝功能失效 大家好， UM11442 修订版24 第3.1.5.15 段 零拷贝 例子 evkmimxrt1170_wifi_cli_cm7 编译失败，使用建议的预处理器宏标志，第一个错误： << wifi_netif.c 中未定义 NETIF_RX_BUFFERS>> 所以我添加了下一个定义 #define NETIF_RX_BUFFERS 8 但我现在有 错误：无效地使用了未定义的类型“struct nxp_wifi_device ” 实际上，示例中并未定义所使用的结构。 示例中的零拷贝功能不完整，因此 UM11442 中的描述不适用？ 如何测试零拷贝？ 谢谢，并致以最诚挚的问候。 皮耶罗 Re: NXP UM11442, paragraph 3.1.5.15 Zero Copy, NOT working 目前我们只有MIMXRT1170-EVK ， SDK 26.06 已安装，但 EVK 示例 “ evk mimxrt1170_wifi_cli_cm7”与“ evkb mimxrt1170_wifi_cli_cm7”不同。 文档 UM11442 中引用了文档 UM11441，文档 UM11441 表 1 第 5 页中也提到了组合 i.MX RT1170 EVK AW611 u-blox JODY W5 声明支持 所以你的意思是“ evk mimxrt1170_wifi_cli_cm7”实际上无法与Wi-Fi零拷贝配合使用吗？ Re: NXP UM11442, paragraph 3.1.5.15 Zero Copy, NOT working 您好， 您使用的是RT1170-EVK还是RT1170-EVKB？ 我在 SDK 26.06 上进行了测试，并使用 evkbmimxrt1170_wifi_cli_cm7 示例，按照指南中提到的宏成功构建了应用程序。 你使用的是哪个SDK版本？ 问候， 丹尼尔。 Re: NXP UM11442, paragraph 3.1.5.15 Zero Copy, NOT working 您好， 正确的。我使用 EVKB SDK 进行了测试。 请问您是从哪里找到 RT1170-EVK 的 SDK 26.06 的，或者您是如何导入的？ 我查看了 RT1170-EVK 版本，只找到了 SDK 版本 2.16.0。 问候， 丹尼尔。

IW416の長期安定した運用設計について NXPチームの皆様、こんにちは。 当社では、NXP IW416チップセットを搭載したu-blox MAYA-W1モジュールを使用しています。 環境 ハードウェア ホストプラットフォーム:Rock3A Wi-Fiモジュール:u-blox M2-MAYA-W1(NXP IW416ベース) u-bloxが提供する評価用ハードウェア SDIOホストインターフェース ソフトウェア Linuxカーネル:6.6.23 NetworkManager: 1.30.6 wpa_supplicant: 2.10 iw: 5.9 Wi-Fiドライバー/ファームウェア ドライバー:MM6X16542.p8-(FP92) ファームウェア: 16.92.21.p155.1 Wi-Fi設定 cntry_txpwr=1 cfg80211_wext=0xf cal_data_cfg=なし drv_dbg=0xFFFFFFFF edmac オフ その他の設定はすべてデフォルトです ホスト・インターフェース： SDIO（Wi-Fi専用、Bluetoothは使用しません。） テスト条件 このデバイスは非常に弱い信号条件下でAPに接続された状態で連続的に動作します。 RSSIは通常次のようになります。 -80 dBm～-85 dBm アクセスポイントが通信範囲の限界付近に位置しているため、接続が不安定で、再接続やスキャン動作が断続的に発生することが予想されます。 問題の説明 約10日間連続稼働すると、Wi-Fiインターフェース(mlan uap wfd)が消えます。 故障発生時： FW_IN_BAND_RESETがトリガーされます ファームウェアのリロード開始 ファームウェアのダウンロードが失敗します mlan0および関連するインターフェースは消失します ログには、次のようなエラーが含まれています。 FW_IN_BAND_RESET ... wlan_dnld_fw 失敗 ret=0xffffffff インバンドリセットシーケンスを実行しても、問題は自動的に回復しません。 質問 これはIW416ファームウェア16.92.21.p155.1の既知の問題ですか？ RSSIが弱い状態（-80～-85 dBm） スキャン/再接続アクティビティの繰り返し 長時間運転 FW_IN_BAND_RESET wlan_dnld_fw 失敗 ret=0xffffffff システム設計の観点から、IW416を組み込み、長期的な安定した運用を必要とする製品に対して、NXPからの推奨される復旧戦略は何でしょうか? システム設計者は、現場運用中に時折ファームウェア復旧イベントが発生すると想定し、それに応じてより高レベルの復旧メカニズムを実装すべきでしょうか?（PDn後またはRESET後のファームウェアのリロードなど） 添付： dmesgログ FW_IN_BAND_RESET 周辺の障害ログ 追加情報 mlan0の消失は、熱の問題やWi-Fiモジュールへの電力供給不足が原因であることを理解しています。 これらの可能性を排除するため、試験中に以下の対策が講じられた。 基板は外部ファンを使用して積極的に冷却された。 基板の温度は約30℃に維持された。 最大出力60Wの専用USB Type-C電源が使用されました。 試験中、電力供給の不安定性を示す兆候は一切見られなかった。 したがって、熱や電力に関する問題が今回の故障の主な原因である可能性は低いと考えられる。 よろしくお願いいたします。 Re: Regarding the design for long-term stable operation of the IW416 こんにちは、 @developer123 最新リリースで試すのを手伝ってもらえますか: SD-WLAN-UART-BT-IW416-LNX_6_18_20-IMX8-16.92.21.p160-16.92.21.p160-MM6X16543.p18-GPL 最新のタグを選択してください：lf-6.18.20_2.0.0 FWを取得するには： GitHub - nxp-imx/imx-firmware · GitHub ドライバーを獲得するには: GitHub - nxp-imx/mwifiex: WiFi拡張機能 · GitHub よろしくお願いいたします。 Christine。 Re: Regarding the design for long-term stable operation of the IW416 こんにちは、 @developer123 詳細なフォローアップと設計哲学の質問を明確に述べてくださりありがとうございます。これは確かに生産システムにとって重要な考慮事項です。 ご質問に直接お答えします。 はい、NXPが長期的な現場運用に推奨する設計哲学は、システム設計の一部としてホスト側の復旧メカニズムを実装することです。 また、IW416はリリースノートに記載されているように 、致命的なエラーに対する自動フォールカバリをサポートしています 。 Wi-Fiファームウェアの自動復旧理論をより深く理解するために、以下を参照することをお勧めします。 Wi-Fiファームウェアの自動復旧 報告された問題に戻りますが、最新のドライバ+FWの組み合わせで試してみてください。もしまだ再現できる場合は、dmesgログ、FWダンプ、ドライバーダンプを含む完全なログの提供に協力してください。 完全なログを取得するには、以下を実行してください。 1. load driver with drvdbg=0xa0037 issue happened logs will automatically save in this directory printed like below: ======================================== [ 4221.173141] Create directory /data/dump_4220 error, try create dir in /var [ 4221.173147] Wakeup device... [ 4221.173231] Create directory /var/dump_4220 successfully [ 4221.173232] Directory name is /var/dump_4220 [ 4221.173233] === START DRIVER INFO DUMP=== [ 4221.173289] DRV dump data in /var/dump_4220/file_drv_info [ 4221.173306] Wakeup device... [ 4221.173889] SDIO Func0 (0x0-0x9): 43 03 06 00 07 00 00 02 03 00 [ 4221.175173] SDIO Func1 (0x4-0xb): 00 00 00 00 ff ff ff ff [ 4221.175879] SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00 [ 4221.176284] SDIO Func1 (0xc0-0xca): dc fe 96 00 31 11 00 37 37 02 20 [ 4221.177301] | [ 4221.275861] SDIO Func1 (0xc0-0xca): dc fe a1 00 3b 00 00 37 37 02 20 [ 4221.276501] Drv info total bytes = 263150 (0x403ee) [ 4221.276503] === DRIVER INFO DUMP END===Wakeup device... [ 4221.276555] ==== DEBUG MODE OUTPUT START: 4220.878602 === ==================================================== If the dump is not auto-generated at "/var" or "/data" it can be collected manually using below "cat /proc/mwlan/adapter0/fw_dump > file_fw_dump" command. 2. If you check it doesn't print the directory in dmesg logs, 3.please get it in below way: - echo debug_dump > /proc/mwlan/adapter0/config - Wait for some time (1 or 2 min) - cat /proc/mwlan/adapter0/fw_dump > file_fw_dump drv_dump: cat /proc/mwlan/adapter0/drv_dump > file_drv_dump よろしくお願いいたします。 Christine。 Re: Regarding the design for long-term stable operation of the IW416 おすすめしていただきありがとうございます。 最新のドライバとファームウェアのリリースを評価します。 しかし、我々の主な疑問は、この特定の問題が新しいファームウェアバージョンで修正されたかどうかではありません。 実際の製品開発では、ソフトウェアのバージョンは製品リリース前のどこかで凍結されなければなりません。新しいファームウェアリリースが既知の問題を解決することはありますが、製品ライフサイクル全体を通じてすべてのファームウェアアップデートを継続的に追跡・展開することは一般的に現実的ではありません。 また、ファームウェアは時間とともに継続的に改良されており、新しいリリースで特定の問題が解決されることもありますが、将来的に追加の例外的な問題が発見される可能性もあります。 長期的に信頼性の高い現場運用を必要とする製品において、時折のファームウェア復旧イベントを通常のシステム設計の前提として考慮すべきでしょうか? 私たちはNXPのデザイン哲学を理解しようとしています。 よろしくお願いいたします。

S32K146 SRAM ECC 在 SRAM 读取时自动纠错？ 我使用的是S32K146。冷启动时，我将 32 位值 0 写入所有 SRAM（以初始化相关的伴随式位）。 我一直认为，如果我读取一个 SRAM 位置，而 ECC 检测到单个比特损坏，那么 ECC 系统会将更正后的值返回给 MCU，并通过写回 SRAM 位置来更正该 SRAM 位置。另一位同事则认为情况并非如此，他表示：“更正后的值会传递给 MCU，但翻转后的位会保留在 SRAM 中，直到被重新写入。” 谁的说法正确？如果是对方，那么我应该从哪里获取更正后的值，然后将其写回SRAM？这是否需要使用ERM单比特错误中断？我可以看到 EARn 寄存器指示了错误的 SRAM 地址，但没有看到 EDRn (?) 寄存器具有正确的值。 总之，我只需要知道如果检测到单比特错误，如何纠正 SRAM 位置。我希望它能通过读取位置信息自动完成。如果真是这样，我就可以有效地忽略单比特纠错，就好像它们从未存在过一样，只出于好奇才使用中断来统计纠错的总数。这也意味着我可以执行“分片读取 SRAM 中的所有数据”作为 CBIT 活动的一部分，从而在发生第二次损坏并可能导致双位不可恢复错误之前，自动快速修复任何单比特错误。 我注意到 S32K1xx 参考手册第 32 节“PRAMC”提到了自动校正 SRAM，但 S32K146 上没有 PRAMC。我注意到第 35.1.3.1 节还提到单比特 ECC 错误会自动纠正，但这指的是 NVM，而不是 SRAM。我在 S32K14x 的参考手册中没有找到任何明确的说明，即读取 SRAM 位置时如果出现单比特错误，将把更正后的值返回给 MCU，并将更正后的值写回 SRAM 位置。是否有这样的参考手册章节？ 我注意到 AN12522 rev 0 第 2.3 节提到了检测和反应时间。我拍摄这张照片是为了指示发生的单比特故障（闪电箭头），但该故障要过一段时间才能被检测到（故障检测时间，在第一次读取该位置时），然后才能被纠正（故障反应时间）。目前还不清楚该反应（校正）是否对 MCU “无形地”发生，即自动修复 SRAM 位置（写入）并将修复后的值返回给 MCU（通过数据总线）。 谢谢！ 达伦 Re: S32K146 SRAM ECC auto-correcting on SRAM read? 根据 AN12522 的说法，根据您希望系统达到的功能安全级别，处理 SRAM ECC 有 3 种模式。您想要哪个功能安全级别？ Re: S32K146 SRAM ECC auto-correcting on SRAM read? 好的，谢谢你的解释。此问题可以关闭。 这是我的第一款带 ECC 的芯片，令我惊讶的是，参考手册并没有明确指出 ECC“校正”实际上是将（已校正的）有效读取值返回给 MCU，而不是修复 SRAM 本身内部的底层位翻转。恩智浦或许可以考虑将此视为一项更新请求？ 这一定是我对“纠正”这个词的理解有误。很多 ECC 设备似乎都采取了一种常见的做法，即“纠正报告”，而不是“解决问题”。我现在意识到其他一些设备具有“自动修复 ECC”（通常称为 TCM ECC）。

按下开/关按钮后，IMX 8MQ Linux 显示器无法远程控制 Tuna38_0-1787099918843.pngTuna38_0-1787099918843.pngTuna38_0-1787099918843.png 我使用了套件中的HDMI接口。我可以按下那个按钮，但是显示屏无法关闭。 Re: IMX 8MQ Linux display not remoting when pressed the on/off button 你好@Tuna38 希望你一切都好。 在EVK板上可以复现吗？ 请分享BSP版本的具体步骤和细节。 顺祝商祺！ 萨拉斯。 Re: IMX 8MQ Linux display not remoting when pressed the on/off button 我使用的是最新版本的Linux嵌入式系统。这些图片显示的是按下开/关按钮时的日志。但是按下按钮后，显示屏并没有关闭。

使用OTFAD时，J-Flash和MCUXpress IDE有什么区别？ 应用OTFAD时，J-Flash和MCUXpress IDE有什么区别？ 我目前正在使用 RT1010 EVK 测试 OTFAD 配置。 我使用 MCUXpress SPT 程序配置了 OTFAD 并下载了固件。 我将配置的 EVK 的启动模式设置为 FlexSPI 启动模式。 我还有一个关于后续JTAG访问的问题。 虽然我没有配置任何 JTAG 安全设置，但 J-Flash 程序可以连接到目标设备，但我之后无法读取或重写闪存。 但是，如果我在 MCUXpress IDE 中构建原始项目，并使用类似“调试与下载？”的功能下载它，我可以下载一个未配置 OTFAD 的版本。 我想知道这两个程序有什么区别。 为什么无法在 J-Flash 中访问？ 但为什么在集成开发环境（IDE）中可以做到呢？ i.MXRT 安全 Re: What are the differences between J-Flash and MCUXpress IDE when using OTFAD? 尊敬的@TnseoRnr ， 1. 为什么在 J-Flash 中无法访问 Flash？ J-Flash 依靠其自身的 Flash 算法和 J-Link 配置。对于 i.MX RT 设备上的外部 Flash，编程工具通常需要先将 Flash 驱动程序算法加载到片上 RAM 中并执行它。这段驻留在 RAM 中的代码负责 FlexSPI 初始化、擦除操作和编程。 如果当前 J-Flash 项目使用的 SEGGER Flash Loader、JLinkScript、FlexSPI LUT 或 FCB 配置与 SPT 配置后的设备状态不匹配，则可能会遇到调试器可以连接到内核，但无法可靠地读取、擦除或编程外部 Flash 的情况。 2. 为什么仍然可以从 MCUXpresso IDE 访问 Flash？ MCUXpresso IDE 的下载和调试流程通常不仅仅是简单的基于 JTAG 的外部 Flash 写入。相反，它会执行完整的目标初始化和 RAM 驻留 Flash 驱动程序过程： 将 Flash 驱动程序下载到 i.MX RT 设备的内部 RAM 中。→ 初始化 FlexSPI 接口。→ 将应用程序映像分段缓冲，并调用 Flash 擦除/编程 API。 同样，LinkServer 也使用 .cfx 文件。闪存驱动程序通过RESET→运行闪存驱动程序→程序序列执行下载。 因此，即使 J-Flash 项目没有针对当前的 OTFAD 或 FlexSPI 状态正确配置，MCUXpresso IDE 也可能能够重新初始化 Flash 并成功执行擦除/编程操作。 顺祝商祺！ 雪莉

iMX8qm 启动核心 A72_0 大家好，NXP论坛， 在 iMX8qm 上，我们能否从 A72 核心启动？SCUFW 是否支持这样做？ 谢谢！ Re: iMX8qm Boot Core A72_0 请先使用现有的 flash_ca72 目标；不要替换 u-boot-atf.bin 文件。使用 u-boot-atf-a72.bin除非您有意使用驾驶舱/多 AP 图像流。 证据表明存在这种区别： flash_ca72 被描述为与普通 A-core 启动目标相同的基本启动映像，但加载到 A72 而不是 A53。 u-boot-atf.bin 是 ATF 和 U-Boot 的组合镜像：bl31.bin加上 u-boot.bin/ u-boot-hash.bin。 u-boot-atf-a72.bin出现在 flash_cockpit 目标中，其中镜像包含两个 AP 有效载荷：一个用于 A53，另一个用于 A72：-ap u-boot-atf.bin a53 0x80000000 ... -ap u-boot-atf-a72.bin a72 0xC0000000 ... 。 因此，重要的选择器不仅是文件名；它还是目标中的 imx-mkimage -ap ... a72 ... 参数。对于单个 A72 启动映像，使用 u-boot-atf.bin 的 flash_ca72 与文档中所述的意图一致：即使文件名没有后缀 -a72，有效载荷也会通过目标规则加载到 A72。 推荐路径： 使用现有目标构建标准的仅限 A72 的镜像： 制作 SOC=iMX8QM flash_ca72 在 Linux 端使用 CA72 设备树/配置。NXP 文档指出，i.MX8QM MEK CA72 DTB 仅支持两个 Cortex-A72 内核，并且需要使用 flash_ca72 构建的特殊启动映像。 预留 u-boot-atf-a72.bin对于显式打包第二个 A72 AP 映像的流程（例如 flash_cockpit），除非您的 电路板支持包的 soc.mak评论或发行说明另有说法。 启动时验证镜像是否实际进入 A72 路径：检查 make V=1 SOC=iMX8QM flash_ca72 命令发出的 imx-mkimage 命令，或检查 iMX8QM/soc.mak 文件。并确认 AP 线路使用 a72。 要点：将当前 flash_ca72 引用视为对 u-boot-atf.bin 的引用这是有意为之；u-boot-atf-a72.bin 是用于驾驶舱/多分区风格镜像中单独使用的 A72 有效载荷，而不是 flash_ca72 的自动替代品。 Re: iMX8qm Boot Core A72_0 我们想澄清/确认一个小问题：`flash_ca72` 目标目前引用了 `u-boot-atf.bin`，同时，在相同的配置中，还有一个单独的 `u-boot-atf-a72.bin` 可用。 我们该如何进行？ Re: iMX8qm Boot Core A72_0 是的——在 i.MX8QM 上，应用程序处理器启动映像可以面向 Cortex-A72 而不是 Cortex-A53，SCFW 允许这种流程。NXP 的 imx-mkimage 有一个 flash_ca72 目标，被描述为普通 A53 启动映像的 A72 变体，旨在尽早启动 A72 以优化启动时间。 重要的区别在于： First code after RESET: 不是 A72。设备启动流程仍然从 ROM/SCU/SCFW 开始。 AP 端引导加载程序/操作系统启动：是的，这可以在 A72 上完成。SCFW 初始化 DDR，加载 Cortex-A 映像，然后启动内核并设置其起始地址。 配置机制：启动容器可以为 a72 指定一个 AP 镜像，例如示例显示 imx-mkimage 中的 -ap ... a72 ...。 所以答案是： SCFW 确实允许从 A72 启动 AP 软件路径，但 A72 不是 RESET/ROM 启动主控；它是由 SCFW 根据启动容器配置启动的。

LX2160A - 同步以太网 (SyncE) RCLK 您好， 我使用的是LX2160A板。 据我了解，SerDes 模块可以使用同步以太网 (SyncE) 并从输入的 SerDes 信号中恢复时钟。然后，该时钟可作为 RCLK0/1 提供，相关的 SerDes 可通过寄存器 RECOV_CLK_SEL_RCLK0/1 选择。 那么，恢复后的时钟信号能否用于驱动 SerDes 模块，无论是用于恢复该信号的那个模块还是其他模块？ 能否作为PLLS/PLLF的参考时钟？ 先行致谢。 Re: LX2160A - Synchronous Ethernet (SyncE) RCLK 你好， 不，RCLK0/1 不能直接反馈到 LX2160A SerDes 作为 PLLS/PLLF 的参考时钟。RCLK0 和 RCLK1 是 LX2160A 上的仅输出引脚。预期的 SyncE 架构要求先将 RCLK0/1 通过外部抖动清除器 PLL 进行路由，然后再将清除后的时钟作为 SerDes 参考时钟（SD1_PLLS_REF_CLK_P/N 等）反馈回去。 此致

Secure アクセス Filesを使わないセキュアブート実装 S32kのボードでセキュアアクセスファイルなしでセキュアブートを実行する方法はありますか?もしそうなら、それはどのように実現されるのでしょうか? Re: Secure Boot Implementation without Secure Access Files ハイ CASE00999901に対して私が返信した内容を直接ここに貼り付けさせてください。 もしかしたら、あなたの質問を正しく理解できていなかったかもしれません。もし私の理解が間違っていたら、訂正してください。 Secure Access Rightsについて誤解があるようですね。 セキュアアクセス権を取得すると、セキュアブート関連の資料だけでなく、また、Secure Resourcesへのアクセスも与えられます。詳細については、 Secure Access Rights FAQ を読むことをお勧めします。 あなたの説明からすると、すでに セキュアアクセス権を取得しているようですね。その場合、 S32K3 のドキュメントサイトで 「Secure 」をクリックし、キーワードを入力して関連情報を検索できます。例えば、ブートを入力する場合： セキュアアクセス権を持っていなければ、HSE-BファームウェアリファレンスマニュアルV2.7 [RM758227]RM00286ダウンロードすらできません。S32K3のセキュアブートは、HSE(ハードウェアセキュリティエンジン)に基づくブート整合性/認証機構を使用しています。この文書がなければ、HSE（健康・安全・環境）について理解を深めるのは非常に困難でしょう。   セキュアブートに関しては、こちらのディスカッションもご参照ください： https://community.nxp.com/t5/S32K/S32K3/td-p/1735306 高度なセキュアブートモードの使用を推奨します。このモードはチェックすべきリージョンが増えるため、ブートローダーとアプリケーションの両方をカバーするように設定できます。 基本的なセキュアブートモードでは、1つのリージョンしかチェックできません。   よろしくお願いいたします ロビン Re: Secure Boot Implementation without Secure Access Files こんにちは、 私は安全なアクセス権を持っていません。これらのセキュアアクセスファイルはHSE/セキュアブートに関するドキュメントだけでなく、もっと多くの内容をカバーしていると理解しています。 以下にアクセスするには安全なアクセス権が必要だと理解しています: The HSE-B Firmware リファレンス・マニュアル セキュアブートアプリケーションノート(AN744511)とそのデモプロジェクト。 HSEファームウェアパッケージ自体 また、HSE標準のFW図書館は安全なアクセス権なしでアクセスできることも知っています。 セキュアアクセス権にアクセスできなくても、ボード上でセキュアブートを実行することは可能でしょうか? Re: Secure Boot Implementation without Secure Access Files Q: セキュアアクセス権にアクセスできなくても、ボード上でセキュアブートを実行することは可能ですか? A：このチップには、デフォルトではHSEファームウェアはインストールされていません。S32K3にHSEファームウェアをダウンロード・インストールできない場合、Secure Bootは確実に動作しません。 以前、セキュアアクセス権限を申請されたようですね。安全なアクセス権限を確実に取得できるよう、引き続き私の同僚と連絡を取り合ってください。

Skywell BE11主机砖模式 你好， 我是来自匈牙利的阿提拉·波通迪。 我想请您帮忙将主机恢复到原始状态。 我在德国买了一辆二手车，但我写给 Skywell 经销商的信件一直没有收到任何回复。 车辆识别码 (VIN) 为：LMELBL1P4NRC03065 Skywell BE11 NXP i.MX8QXP 处理器。 遗憾的是，这两个国家的代理商和制造商都没有回答这些问题，所以我才来向您求助。 我想通过终端删除一些 APK 文件，但这些文件导致系统崩溃，并要求通过终端输入密码。 谢谢 阿提拉 Re: Skywell BE11 Head unit Brick mode 你好， 我会非常谨慎地处理这件事，尤其是考虑到主机本身就不稳定。在基于 i.MX8QXP 的系统中，从终端删除系统 APK 或更改文件很容易导致 Android 无法启动。如果没有确切的 Skywell 固件/版本和正确的恢复程序，我不建议猜测终端密码或删除更多软件包。

モータ制御評価キット こんにちは、NXPは初めて利用します。 MCSPTR2AK396開発キット用のカスタムモータ制御Cコードを開発・書くことはできますか? はいの場合、このキットに付属するソフトウェアツールチェーンの一覧を教えていただけますか？ よろしくお願い申し上げます。 Re: Motor control evaluation kit こんにちは、 はい、できます。 MCSPTR2AK396キットはS32K396上でのモーター制御アプリケーション開発に特化しており、NXPはAUTOSAR以外のアプリケーション向けにANSI Cソースコードとしてリファレンスソフトウェアを提供しているため、制御アルゴリズムの一部をカスタムCコードで開発・置き換えするのに適しています。 典型的なソフトウェアツールチェーン: S32 Design Studio(S32DS) – IDE、コンパイラ、デバッガ RTD(リアルタイム・ドライバ) – S32K3ペリフェラルドライバ S32設定ツール(S32CT) – ピン/クロック/ペリフェラル設定 AMMCLib – モータ制御アルゴリズムライブラリ FreeMASTER – ランタイム監視とデバッグ MCAT – 運動パラメータの識別と調整 よろしくお願いいたします。 ピーター

RIOP RT1189 – GitHubソースからのビルドおよびフラッシュワークフロー こんにちは、 現在はNXP RIOP評価ボードと連携しており、Getting Startedガイドを無事に完了し、事前プログラムされたFreeMASTERデモもテストしました。 次のステップは、デモをソースコードから再構築し、ボードに書き込んで、ビルドと書き込みのパイプライン全体が正しく動作することを確認することです。 以下のドキュメントと情報源を確認しました: はじめ:GS-REMOTE-IOプラットフォーム RIOPユーザーガイド:UG10224 GitHubリポジトリ: nxp-appcodehub/rd-riop-demo GitHubリポジトリには2つのプロジェクトが含まれています。 riop_M33LEADER_DEMO riop_M7FOLLOWER_DEMO 必要なSDKおよびツールのバージョン、MIMXRT1189 SDK 25.09.00を含むことを規定しています。 私にとってまだ完全には理解できていないのは、これら2つのプロジェクトから、基板に搭載されているものと同じ起動可能なファームウェア構成にどうやって到達するかということです。 質問: M33およびM7プロジェクトを構築する際の推奨される方法は？MCUXpressoで両方のプロジェクトを個別にインポートしてビルドすればよいのでしょうか、それともビルド順序や依存関係が必要なのでしょうか？VS Code拡張機能も使えますか? 生成されたM33およびM7の画像は、どのようにRIOPにプログラムされるのですか？Secure Provisioning Toolは、アプリケーション全体を作成・フラッシュするための意図された方法なのでしょうか? 2つのイメージがどのように結合されるか（正しいメモリレイアウトとフラッシュアドレスを含む）を示す、既存のセキュアプロビジョニングツールの構成例またはサンプルはありますか？ RIOPデモの画像認証はどのように扱われていますか?工場出荷時の設定でセキュアブート／署名検証は有効になっていますか？また、デモ版を自作してフラッシュする際に、キーのプロビジョニングは必要ですか？ rd-riop-demoを上書きする前に、現在ボードにプログラムされているrd-riop-demoのバージョンを特定する方法はありますか？ 例コードから見ると、RT1189 Boot ROMがM33アプリケーションを起動し、M33がMCMGRを使って0x303C0000でM7を起動するようです。これは工場出荷時イメージの完全なブートフローですか、それともGitHubリポジトリに含まれていない追加のブートステージがありますか？ 必要ならボードを元のすぐに使える状態に戻せるよう、元の工場出荷イメージはどこかに入手できますか? コマンドライン／ヘッドレスビルドのワークフローも利用可能ですか？長期的には、ビルドを再現可能にし、CI（継続的インテグレーション）に適したものにしたいと考えています。 Getting Startedガイドはすぐに使えるのデモをよく説明しており、GitHubリポジトリにもソースがありますが、今のところ両者のつながりが分かりません。 GitHubソース → M33/M7をビルド → ブート可能なイメージを作成 → フラッシュ → 同じデモを実行 UG10224か他の文書の該当箇所を見落としたのかもしれません。 ご回答をお待ちしています。 Re: RIOP RT1189 – build and flash workflow from GitHub sources こんにちは、シェリーさん。 詳細なご回答をありがとうございました！ よろしくお願いいたします。 Marco Re: RIOP RT1189 – build and flash workflow from GitHub sources @Embernard様、 ご質問への回答は以下のとおりです。 1.RIOPデモはMCUXpresso IDEとVS Code + MCUXpresso for VS Codeの両方をサポートしています。VS Codeのご利用をお勧めします。riop_M7FOLLOWER_DEMOとriop_M33LEADER_DEMOプロジェクトをインポートした後、まずM7フォロワープロジェクトをビルドし、次にM33リーダープロジェクトをビルドすることをお勧めします。これは、M33プロジェクトがriop_M7FOLLOWER_DEMO.axf.oを参照しているためです。M7プロジェクトによってマルチコアスレーブイメージとして生成されたファイル。 2. Secure Provisioning Tool (SPT) を使用してフラッシュメモリに書き込む必要があるのは、riop_M33LEADER_DEMO.axf ファイルのみです。UG10224のセクション4.1.5を参照してください。「デモアプリケーションの実行中」。最新版のSPT v26.06をダウンロードして使用することをお勧めします。一部の設定設定はユーザーガイドに示されているものとは若干異なることに注意してください。 ShellyZhang_0-1787196235459.pngShellyZhang_0-1787196235459.pngShellyZhang_0-1787196235459.pngShellyZhang_0-1787196235459.png 3. 独自のRIOP SPTワークスペースを作成するには、UG10224を参照してください。SPT側では、主な役割はブート可能なRT1189アプリケーションイメージを生成し、デバイスにプログラムすることです。 4. 開発中は、機能検証のために署名なし/オープン構成を使用することを推奨し、eFuseやキーのプログラミングは推奨しません。 プログラミングヒューズは不可逆的な操作であり、シャドウレジスタなど適切な検証後の本番セキュリティプロセスの一部としてのみ実施されるべきです。セキュアブート、イメージ署名、暗号化を有効にするかどうかは、最終的には本番環境のセキュリティ要件とSPT設定によって決定されるべきです。 5. 現在のファームウェアがFreeMASTER変数、UART出力、またはバージョン文字列を通じてバージョン情報を公開しない場合、ボード上で現在実行されているrd-riop-demoのバージョンを確実に判別することはできません。フラッシュメモリの内容を上書きする前にバックアップを取るか、カスタムファームウェアにバージョン情報を追加することをお勧めします。 6.現在のプロジェクトで実装されている起動モデルは、RT1189がまずCM33(M33リーダー)を起動し、その後M33がマルチコア/MCMGRフレームワークを通じてM7フォロワーを起動するというものです。追加の起動段階は不要です。 7. 復元が必要な場合、最も信頼できる方法は、既存のフラッシュイメージを読み返して保存し、再プログラムすることです。バックアップが利用できない場合は、rd-riop-demoを再構築して再プログラムするしか選択肢はありません。これにより、システムは機能的に同等の状態に復元されます。 8. コマンドラインワークフローがサポートされています。SPTは内部的にOpenSSLやSPSDKなどのコマンドラインツールを呼び出し、鍵の生成やイメージのビルド/書き込みを行います。詳細については、以下のドキュメントをご参照ください。 セキュアプロビジョニングツール - コマンドライン操作 2つの画像がどのように関連付けられているかについては、主要な流れは以下のとおりです。 1.デモは、リンクされた2つのマルチコアプロジェクトとして構成されています。 RIOPデモリポジトリには、2つのプロジェクトディレクトリが含まれています。 riop_M33LEADER_DEMO/ riop_M7FOLLOWER_DEMO/ 。 MCUXpressoのマルチコアプロジェクトモデルでは、プライマリ/リーダープロジェクトがセカンダリー/フォロワープロジェクトにリンクします。プライマリプロジェクトが構築されると、まずセカンダリプロジェクトが構築され、セカンダリ出力イメージがプライマリイメージに組み込まれる／埋め込まれる。 2. M33プロジェクトはマルチコアマスターとして構成され、M7プロジェクトはスレーブとして構成されます。 riop_M33LEADER_DEMO/.cproject では、プロジェクトは __MULTICORE_MASTER と __MULTICORE_MASTER_SLAVE_M7SLAVE を定義しています。そのマルチコアマスター構成は以下を指し示しています。 ${workspace_loc:/riop_M7FOLLOWER_DEMO/Debug/riop_M7FOLLOWER_DEMO.axf.o} 。 これは、まず riop_M7FOLLOWER_DEMO.axf が .axf.o に処理され、そのオブジェクトが「スレーブオブジェクト」として M33 リーダーイメージにリンクされることを意味します。 M7プロジェクトは、CM7 ITCM/DTCMメモリ領域を使用して、M7SLAVE / __MULTICORE_M7SLAVEとして構成されます。 3.実際のマージは主にリンク/ビルド後の段階で行われます。 MCUXpressoのマルチコアフローは、セカンダリコアイメージを処理し、セカンダリコアセクションをシフトしてから、それらを完全なマルチコアイメージにリンクします。 したがって、最終的なriop_M33LEADER_DEMO.axfは、M33リーダーELFにM7フォロワーの画像データ/セクションが埋め込まれたものであり、2つの独立したAXFファイルを単純にバイナリで連結したものではありません。 4.実行時に、M33はM7を開始します。 riop_M33LEADER.c 内M7ブートアドレスは次のように定義されます。 CORE1_BOOT_ADDRESS = 0x303C0000、CORE1_KICKOFF_ADDRESS = 0x0。 SystemInitHook() では、Prepare_CM7(CORE1_KICKOFF_ADDRESS) が呼び出され、その後 main() で MCMGR_StartCore(kMCMGR_Core1, CORE1_BOOT_ADDRESS, ...) が呼び出されてセカンダリ コアが起動します。 したがって、M7イメージはM33リーダーAXFに埋め込まれていますが、M7の実行は実行時にM33によって明示的に起動されます。 5. 起動可能なイメージは依然としてSPTプロセッシングが必要です RT1180については、ドキュメントによるとデバイスはCM33からのみ起動できると記載されています。Secure Provisioning Toolは、生アプリケーションイメージからブートヘッダー付きのブート可能なイメージを生成するために使用されます。MCUXpressoの出力タイプには.axfが含まれます。 通常の流れは次の通りです: riop_M7FOLLOWER_DEMO.axf→riop_M7FOLLOWER_DEMO.axf.oに処理されます→ riop_M33LEADER_DEMO.axf にリンクされます → SPT は M33 リーダー AXF を使用してブート可能なフラッシュ イメージを生成します。 よろしくお願いいたします。 シェリー Re: RIOP RT1189 – build and flash workflow from GitHub sources こんにちは、シェリーさん。 続報です。 RIOPリポジトリにはriop_M7FOLLOWER_DEMO/scripts/image_hash_tool.pyが含まれていませんが、元のプロジェクトでは条件付きでこのファイルが呼び出されています。RIOPマルチコアデモにおいて、ヘルパー関数が欠落しているのは意図的なものですか？もしそうなら、VS CodeのプロジェクトコンバーターはWindows上で元の「スキップ・if uncessent」の動作を保持し、失敗するcmd.exeコマンドを生成せずに済むのでしょうか?意図的でない場合、意図された image_hash_tool.py はどこで提供され、SPT で M33 画像をプロセッシングする前に必須ですか? よろしくお願いいたします。 Marco Re: RIOP RT1189 – build and flash workflow from GitHub sources @Embernard様、 image_hash_tool.py スクリプトは以下の場所にあります。 riop_M33LEADER_DEMO\scripts\ これは、ビルド後の段階でファームウェアELFイメージのハッシュ値を計算し、生成されたハッシュ値をELFファイル内の予約済みセクション/オフセットに書き戻すために使用されます。これにより、起動コードやセキュリティ機構が実行時にファームウェアイメージの整合性を検証できます。 この設計ではM7コアが主要なブートコアではないため、M7イメージではこの後処理ステップは一般的に不要です。image_hash_tool.py が見つからないことに関連する警告が表示された場合は、それらは無視して、ビルドプロセスを続行してください。 よろしくお願いいたします。 シェリー

i.MX6Q HAB開発用の旧バージョンのコード署名ツール（CST）の提供依頼 NXP技術サポートチームへ、 現在、i.MX6Q SabreSDプラットフォームをベースにしたHigh Assurance Boot(HAB)セキュアブートソリューションを開発しており、公式のNXP BSPリリースL3.14.52_1.1.0を使用していますGAは当社の製品に対して完全に検証されています。 最新のCST v3.1.0公式ポータルからダウンロードしたものは、このレガシーBSPバージョンと完全に互換性がなく、i.MX6QのHABv4プロトコルに一致する有効な署名データを生成できません。これにより、その後のセキュアブート検証作業が妨げられます。 私はすでにNXPのコード署名ツールに関するソフトウェアライセンス契約を読み、受け入れており、このツールはNXP i.MX シリーズチップの社内製品開発にのみ使用されることを確認しています。 CST v2.3.2(HABv4用)のダウンロードリンクを教えていただけますか?このバージョンは、私たちが使用しているi.MX6Q BSPに対して公式に推奨されているマッチングツールです。 プロジェクトやチップの部品番号について追加情報が必要な場合は、どうぞお気軽にご連絡ください。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 リクエフイ i.MX6Quad

KW47：WDOG待機/停止モードと電源モード（スリープ/ディープスリープ）の関係 こんにちは、 KW47リファレンスマニュアルを読んでいるのですが、WDOGの低消費電力モードとシステムの電源モードの関係について混乱しています。 WDOGの章では、制御およびステータスレジスタには次のビットが含まれています。 - 待って： 「チップが待機モードのときにWDOGが動作できるようにします。」 - 停止： 「チップが停止モードのときにWDOGが動作できるようにします。」 WDOGの章には、次のようにも記載されています。 - 選択したWDOGクロックソースは、停止モードでもアクティブな状態を維持する必要があります。 デバッグモードおよび停止モードでは、バスクロック以外のクロックソースを使用する必要があります。 一方、「電源モード」の章では、以下のことが説明されています。 スリープモード: - CPUの実行が停止しました - コアクロックゲートオフ システムクロックとバスクロックは引き続き動作する可能性があります。 ディープスリープモード： - コアクロックゲートオフ - システムクロックゲートがオフになっています バスの時計が閉まっている これらの記述に基づくと、以下のように解釈するのが妥当と思われる。 - 待機モード ≈ スリープモード - 停止モード ≈ ディープスリープモード しかし、リファレンス・マニュアルにはこのマッピングを裏付ける明確な記述は見つかっていません。 私の質問は以下のとおりです。 1. WDOG待機モードはKW47のパワーモードスリープモードに対応しますか? 2. WDOG停止モードはKW47のパワーモードのディープスリープモードに対応しますか? 3. それとも、待機/停止はWDOG特有のCPU状態で、SoCの電源モードとは異なるのでしょうか? 4. この関係を明示的に説明したリファレンス・マニュアルのセクションやアプリケーションノートはありますか? ご協力ありがとうございます。

电机控制评估套件 您好，我是NXP的新员工。 我能否为MCSPTR2AK396开发套件开发并编写基于C语言的自定义电机控制代码？ 如果可以，能否列出该工具包中包含的SW工具链？ 谢谢 Re: Motor control evaluation kit 你好， 是的，可以。 MCSPTR2AK396 套件专为 S32K396 上的电机控制应用开发而设计，NXP 提供参考软件作为 ANSI C 源代码，适用于非 AUTOSAR 应用，使其适合开发和用您自己的自定义 C 代码替换部分控制算法。 典型的软件工具链： S32 设计工作室 (S32DS) – 集成开发环境 (IDE)、编译器、调试器 RTD（实时驱动程序）– S32K3 外围设备驱动程序 S32 配置工具 (S32CT) – 引脚/时钟/外设配置 AMMCLib – 电机控制算法库 FreeMASTER – 运行时监控和调试 MCAT – 运动参数识别与调优 顺祝商祺！ Peter

LX2160AのJTAG(CCS)接続が失敗する LX2160Aに対し、DDR toolの使用を考えていますが、Connectができません。 原因はCCSより、JTAGの接続が確認できないことだと思います。 IDcodeの確認結果を添付します。 KAZU_ISHI_0-1786615924736.pngKAZU_ISHI_0-1786615924736.pngKAZU_ISHI_0-1786615924736.pngKAZU_ISHI_0-1786615924736.pngKAZU_ISHI_0-1786615924736.pngKAZU_ISHI_0-1786615924736.pngKAZU_ISHI_0-1786615924736.png 少し前に接続を試した際はJTAGからの接続が確認できましたが、ファイルが破損してしまったことと、細かくリビジョンを管理しておらず復元できておりません。 check for Updateより、インターネットからダウンロードを実施するとファイルが破損するケースが存在することを把握しておらず、現在ソフトウェアの状態を一致させることができないでいます。 一度接続できたため、ソフトウェアの問題かと思いますが、解決方法をご存じでしたらご教授願います。 以上よろしくお願いいたします。 Re: LX2160AのJTAG(CCS)接続が失敗する まずCW_ARMv8_v2020.06_b200629GA_Win_Offline.exeをインストールし、その後CodeWarrior IDEを開き、Help->Install New Software->Add->Archiveからサービスパックcom.freescale.armv8.11.5.12.GA.Win.updatesite.221209.zipをインストールしてください。 問題が解決しない場合は、エラー画面のスクリーンショットをご提供ください。 Re: LX2160AのJTAG(CCS)接続が失敗する 最新版のCodeWarrior for ARMv8 11.5.12がインストールされているかどうか確認してください。 CodeWarrior IDEを開き、QorIQ LSシリーズ(ARM V8 ISA)のHelp->About CodeWarrior Development Studioのバージョンを確認してください。 既にこのバージョンのCodeWarriorをインストールしている場合は、CodeWarrior TAPからUSBケーブルを抜き、再度差し込んでください。 Re: LX2160AのJTAG(CCS)接続が失敗する ご返信ありがとうございます。 現在使用しているCodeWarriorのバージョン情報は以下の通りです。 CodeWarrior Development Studio for QorIQ LS series - ARM V8 ISA Version: 11.5.0 Build Id: 200629GA ご連絡いただいた最新バージョンと比較すると、私の環境は古いバージョンのようです。 ちなみに、「Install New Software」→「Add」→「Archive」から 「com.freescale.armv8.11.5.12.GA.Win.updatesite.221209.zip」を選択した場合、どの項目をインストールすればよいでしょうか。 「Select All」を選択すると、エラーが発生し、インストールが成功しません。 Re: LX2160AのJTAG(CCS)接続が失敗する ご返信ありがとうございます。 「CodeWarrior for ARMv8 v11.5.0 b200629 Windows Offline Installer」からインストールを実行しました。 その後、CodeWarrior IDEで、Help → Install New Software → Add → Archive から com.freescale.armv8.11.5.12.GA.Win.updatesite.221209.zip を指定して更新を試みましたが、インストール中にエラーが発生します。 エラーメッセージは以下の通りです KAZU_ISHI_0-1786959225115.pngKAZU_ISHI_0-1786959225115.pngKAZU_ISHI_0-1786959225115.pngKAZU_ISHI_0-1786959225115.png An error occurred while installing the items session context was:(profile=epp.package.cpp, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=[R]com.freescale.core.debugger.fsl_gdb 13.0.0.202003111126 --> [R]com.freescale.core.debugger.fsl_gdb 14.0.0.202204131357, action=com.freescale.updater.customactions.actions.FreescaleProcessCheck). NLS missing message: param_not_set in: com.freescale.updater.customactions.Messages 対処方法についてご教示いただけますでしょうか？ 以上よろしくお願いいたします。 Re: LX2160AのJTAG(CCS)接続が失敗する 以下のリンクからインストールファイルをダウンロードし、CodeWarrior for ARMv8 11.5.12を再インストールしてください。 https://support.nxp.com/s/case/500Te00000eeSJXIA2/community-lx2160a%E3%81%AEjtagccs%E6%8E%A5%E7%B6%9A%E3%81%8C%E5%A4%B1%E6%95%97%E3%81%99%E3%82%8B?language=en_US Re: LX2160AのJTAG(CCS)接続が失敗する Windows 10にCodeWarrior for ARMv8をインストールしようとしていますか？ まず、CodeWarriorのインストールファイルをすべて削除してください。 私のtarボールからCW_ARMv8_v2020.06_b200629GA_Win_Offline.exeをインストールしてください。 その後、 新しいワークスペースでCodeWarrior IDEを開き、Help->Install New Software->Add->Archiveからサービスパックcom.freescale.armv8.11.5.12.GA.Win.updatesite.221209.zipをインストールします。

请求提供 i.MX6Q HAB 开发用旧版代码签名工具 (CST) 尊敬的恩智浦技术支持团队： 我目前正在基于 i.MX6Q SabreSD 平台开发高度保证启动 (HAB) 安全启动解决方案，使用的是 NXP 官方 BSP (电路板支持包) 版本 L3.14.52_1.1.0。GA 已针对我们的产品进行了全面验证。 最新版 CST v3.1.0从官方门户网站下载的版本与此旧版 电路板支持包。 不完全兼容，无法生成与 i.MX6Q 的 HABv4 协议匹配的有效签名数据。这会阻碍我们后续的安全启动验证工作。 我已经阅读并接受了 NXP 代码签名工具的软件许可协议，并且我确认该工具将仅用于我们 NXP i.MX 系列芯片的内部产品开发。 请问能否提供CST v2.3.2 （适用于 HABv4）的下载链接？这是我们使用的 i.MX6Q 电路板支持包。的官方推荐匹配工具。 如果您需要有关我们项目或芯片零件编号的任何其他信息，请随时与我联系。 感谢您的支持。 顺祝商祺！ 立学会 i.MX6 四核

Selection of FS2613 chip The FS2613 series chips are quite powerful, and the values and timings of each power rail are editable. However, we don't have much time for software development and prefer not to implement OTP ourselves. Are there any models that are factory-configured to be compatible with the S32K358? For example, like the one shown in the image below? Rio_Lee_0-1786090969347.pngRio_Lee_0-1786090969347.pngRio_Lee_0-1786090969347.png Re: 关于FS2613芯片的选型 See attachment Re: 关于FS2613芯片的选型 Okay, for the MFS2633AMDB2AD model, what are the output voltages of each of the following channels after power-on by default? Where do VCORE, LDO1, LDO2, VREF, VBST, TRK1, and TRK2 originate? Re: 关于FS2613芯片的选型 MFS2633AMDB2AD Search | NXP Semiconductors You can choose this one! Re: 关于FS2613芯片的选型 The MFS2633AMDB2AD is discontinued. With the same specifications, I should replace it with the MFS2633HMDB2AD, right? Re: 关于FS2613芯片的选型 Yes! Re: 关于FS2613芯片的选型 Please submit a new ticket for new questions. Thank you! Re: 关于FS2613芯片的选型 How are PIN.17 FCCU1 and PIN.18 FCCU2 used on this chip? What truth table do the input values of these two pins form, triggering different protection mechanisms of the chip? Re: 关于FS2613芯片的选型 Is the factory default configuration, based on the S32K358 adapter, that LDO1, LDO2, TRK1, and TRK2 are all 3.3V models? Re: 关于FS2613芯片的选型 guoweisun_0-1787644183604.pngguoweisun_0-1787644183604.png There are two adapters for K35X that are not what you need: LDO1, LDO2, TRK1, and TRK2 are all 3.3V. For new questions, you can submit a new ticket; it's best to use a company email address.

LS1046ARDB Mbed Serial Driver Install Windows 11 2026 Hello, I'm trying to establish serial communication with the LS1046ARDB per the "LS1046A Reference Design Board Getting Started Guide" Section 10 "Booting LS1046ARDB".  The link in the guide for the Mbed Windows Serial Port Driver redirects to a github page with different repos.  https://developer.mbed.org/handbook/Windows serial-configuration I can't seem to find "mbedWinSerial_16466.exe" in the repos linked from the getting started guide. I'm using Windows 11. I've also tried updating the CMSIS-DAP FW and connecting to the serial console with Storage Services turned off, but still can't detect the Mbed serial com port. Any help is appreciated! Re: LS1046ARDB Mbed Serial Driver Install Windows 11 2026 Hello,  Windows is not recognizing the serial port automatically. It recognizes the board as Mass Storage in the device manager, and an MBED drive appears in the file explorer, but no mbed serial port is recognized in the device manager. Re: LS1046ARDB Mbed Serial Driver Install Windows 11 2026 Hello, The Mbed Windows Serial Port Driver has been superseded by DAPLink. The key guidance from daplink.io is: "If your computer is running Windows 10, Mac OSX or Linux and using DAPLink firmware version 0240 or later, then drivers are not needed." Since the customer is on Windows 11, no serial port driver installation is required at all — Windows should recognize the serial COM port automatically once the board is connected via USB.   Regards

S32G2によるマルチコアアプリケーションの実現 こんにちは、NXPの皆さん： S32G274Aチップでプログラムを動かすにはマルチコアを使い、LinuxにはA53、LLCE_CANはM7で動かす準備をしています。 5.2に基づき「S32G2プラットフォームソフトウェア統合を使ったマルチコアアプリケーションをS32G2で有効化する」と述べました。ブートローダーを設定し、推奨するソフトウェアパッケージをインストールし、手順に従って設定してください。 zhipeng_7-1786181958976.pngzhipeng_7-1786181958976.pngzhipeng_7-1786181958976.png 5.3にエラーがあります。コンパイル時にブートローダーを構築する。 launch.batファイルが編集されました。 zhipeng_0-1786182860528.pngzhipeng_0-1786182860528.pngzhipeng_0-1786182860528.png launch.bat の実行後にエラーが発生しました。 zhipeng_0-1786180508617.pngzhipeng_0-1786180508617.pngzhipeng_0-1786180508617.png 関連するコードをコメントアウトした後。 zhipeng_5-1786181360466.pngzhipeng_5-1786181360466.pngzhipeng_5-1786181360466.png zhipeng_2-1786180921774.pngzhipeng_2-1786180921774.pngzhipeng_2-1786180921774.png CryptoDal.hを見つけましたインストールディレクトリ内のファイル。 zhipeng_4-1786181305215.pngzhipeng_4-1786181305215.pngzhipeng_4-1786181305215.png zhipeng_6-1786181450684.pngzhipeng_6-1786181450684.pngzhipeng_6-1786181450684.png どこに間違いがあるでしょうか? ありがとうございます。 Re: S32G2 Enabling Multicore Application こんにちは、ジペン ご指摘の件についてですが、以下の内容を追加した場合、エラーが発生しますか？コメントアウトしてもエラーは発生しませんか？ Joey_z_0-1786328574726.pngJoey_z_0-1786328574726.pngJoey_z_0-1786328574726.png BR ジョーイ Re: S32G2 Enabling Multicore Application こんにちは、 @Joey_z はい、追加後、3枚目の画像に「未申告」と表示されます。 コメントアウトすると、5番目の画像に「そのようなファイルまたはディレクトリはありません」と表示されます。 zhipeng_1-1786347067301.pngzhipeng_1-1786347067301.pngzhipeng_1-1786347067301.png 「CryptoDal.h」は、D:\NXP\Integration_Reference_Examples_S32G2_2022_06\code\framework\realtime\bsw\dal\cryptodal\generic\include にあります。 「Hse_Ip.h」は、D:\NXP\SW32G_RTD_4.4_3.0.2_HF01\eclipse\plugins\Crypto_TS_T40D11M30I2R0\include にあります。 両方のファイルはそれぞれのフォルダ内に見つかりました。また、ファイルパスはlaunch.batにも記載されています。 現在の問題は、コンパイルプロセス中にプラグインのパスが含まれていなかったことが原因のようです。 BR Re: S32G2 Enabling Multicore Application こんにちは、ジペン 設定でセキュアブートは有効になっていますか？セキュアブートを有効にして、問題が解消されるかどうか確認してみてください。 Joey_z_2-1786353784256.pngJoey_z_2-1786353784256.pngJoey_z_2-1786353784256.png BR ジョーイ 回复： S32G2 Enabling Multicore Application こんにちは、 @Joey_z 前回のブートローダーのコンパイルは成功しました。NORフラッシュにイメージを書き込んだ後、起動してもUARTから何も出力されません。 私はAN13750を参照しました。私の操作手順は以下のとおりです。 「S32G2_LinuxBSP_42.0_User_Manual.pdf」に従いました。Ubuntu 20 に u-boot bsp42.0-2022.04 と ATF bsp42.0-2.10 をインストールしました。 s32_mmc.cを修正しましたおよび s32_common.mk は 0001-fip-align-and-mmc-init.patch に従っています。 zhipeng_0-1787646642108.pngzhipeng_0-1787646642108.pngzhipeng_0-1787646642108.png zhipeng_1-1787646670172.pngzhipeng_1-1787646670172.pngzhipeng_1-1787646670172.png zhipeng_2-1787646683855.pngzhipeng_2-1787646683855.pngzhipeng_2-1787646683855.png u-bootとATFをコンパイルしました。 make CROSS_COMPILE=/opt/S32G/arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ARCH=aarch64 PLAT=s32g274ardb2 BL33=../u-boot/u-boot-nodtb.bin Image Layout DCD: Offset: 0x200 Size: 0x1c IVT: Offset: 0x1000 Size: 0x100 AppBootCode Header: Offset: 0x1200 Size: 0x40 Application: Offset: 0x1240 Size: 0x33e00 Boot Core: A53_0 IVT Location: SD/eMMC Load address: 0x342f8f00 Entry point: 0x34302000 fip.s32ファイルをSDカードに書き込みました。fipを交換した後も、SDカードは起動可能で、u-bootの日付も変更された。 U-Boot 2022.04-00213-g5a6f62071f (Aug 24 2026 - 10:35:21 +0800) ブートローダーを設定します。 zhipeng_3-1787647428751.pngzhipeng_3-1787647428751.pngzhipeng_3-1787647428751.png zhipeng_4-1787647490093.pngzhipeng_4-1787647490093.pngzhipeng_4-1787647490093.png zhipeng_5-1787647533346.pngzhipeng_5-1787647533346.pngzhipeng_5-1787647533346.png zhipeng_6-1787647547310.pngzhipeng_6-1787647547310.pngzhipeng_6-1787647547310.png S32Gブートイメージを生成する zhipeng_7-1787647657415.pngzhipeng_7-1787647657415.pngzhipeng_7-1787647657415.png bt_m7_blob.binを選択して、アドレス0x0に書き込みます。 fip.binを選択して、アドレス0x100000に書き込みます。 S32G274A_M7.binを選択して、アドレス0x200000に書き込みます。 zhipeng_8-1787647865193.pngzhipeng_8-1787647865193.pngzhipeng_8-1787647865193.png 現在、UARTもCANも応答していません。状況を分析するのを手伝ってください。 ありがとうございます。 回复： S32G2 Enabling Multicore Application こんにちは、ZhiPeng 情報提供ありがとうございます。 もっと詳しい情報を教えてもらえますか? 1. Aコア上でATFとubootのみを起動していますか？ AコアのUARTに何らかの出力はありますか？ 2. Mコア機能とは何ですか？UART/CAN関数のことですか? BR ジョーイ