Problems encountered during IDE and RTD installation Hello, I have installed S32DSIDE 3.6.6 software. Then I installed the RTD package. However, the SDK cannot be found when creating a new application project, as shown in the image below. This problem has been bothering me for a long time. I look forward to your reply. Thank you. My computer configuration is as follows: My computer has JDK 8 and JDK 17, and Python versions 13, 14, and 15 installed.   Re: 关于安装IDE和RTD遇到的问题 Thanks, I discovered this problem, and then I wanted to install gcc-10.2. I found a webpage about compilers. I didn't know which one to use, so I downloaded both of these EXE files to install. However, after installation, creating a new project in the S32DS software still did not show gcc-10.2. Then I tried to download it through the extension manager, but I kept getting errors and failing to download it successfully. Could you please guide me on what to do next? Thank you! Re: 关于安装IDE和RTD遇到的问题 Hello @YangLuYao, I've translated your query, so please let me know if there are any misunderstandings. Please try selecting NXP GCC 10.2 instead. S32K1 RTD does not support GCC 11.4 yet: Best regards, Julián Re: 关于安装IDE和RTD遇到的问题 I've solved the problem, thank you! Re: 关于安装IDE和RTD遇到的问题 Sorry, the past two days were the weekend, and this is the error message I reported this morning after trying to recreate the game. Re: 关于安装IDE和RTD遇到的问题 Hello @YangLuYao, Sorry for the late reply. From the image, it seems you are trying to install NXP GCC 6.3.1 (build 1620), you should actually install v10.2 (build 1728): If this still does not work, I guess you can try to install it externally: Installing software in S32 Design studio. Things I would check: Unstable network when installing. Proxy / Firewall at your workplace. Antivirus / Security checks. Disk space. Other than that, I'm not sure what could be the root cause. You could try re-installing S32DS and trying to install NXP GCC 10.2 again. Best regards, Julián

S32K312 HSE 安全启动：pInstAuthTag 能否指向存储在 UTEST DCF 记录区域中的签名？ 您好，NXP支持团队， 我们正在 S32K312 上实施基于 HSE 的安全启动和 SMR，并想确认 SMR 签名是否可以永久存储在 UTEST DCF 记录区域中。 我们目前的实施方案如下： 我们在 UTEST 中存储了一个 512 字节的 RSA-4096 签名，起始地址为： 0x1B001A00U 已占用地址范围为： 0x1B001A00 至 0x1B001BFF 该区域属于 UTEST DCF 记录区域。 我们的项目在这个领域不需要任何 DCF 配置。因此，我们目前正在考虑使用未使用的 DCF 记录空间来存储永久网络安全数据，包括公钥和 SMR 签名。 由于我们的使用场景中软件映像及其签名是固定的，因此预计在产品生命周期内签名不会发生变化。 在 SMR 条目中，我们按如下方式配置签名引用： smrEntry.pInstAuthTag[0]= 0x1B001A00U; smrEntry.pInstAuthTag[1]= 0U； 我们预期，在后续的安全启动验证期间，HSE 将直接从 pInstAuthTag[0] 指定的 UTEST 地址读取 512 字节的签名。 通过 HSE_SRV_ID_SMR_ENTRY_INSTALL 安装 SMR 入口时，我们最初将安装服务认证标签配置为引用相同的 UTEST 地址： pSmrEntryInstall->pAuthTag[0] = 0x1B000A00U; 然而，SMR 安装服务返回了 HSE_SRV_RSP_INVALID_PARAM，显然是因为 UTEST 地址被拒绝为该服务的无效输入地址。 作为一种变通方法，在调用 SMR 安装服务之前，我们将 UTEST 中的 512 字节签名复制到共享 RAM 缓冲区中： UTEST 0x1B000A00 | | 复制 512 字节 v 共享 RAM 缓冲区 然后，我们按如下方式配置安装请求： pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; SMR条目本身仍然包含： smrEntry.pInstAuthTag[0]= 0x1B000A00U; 按照此配置，HSE_SRV_ID_SMR_ENTRY_INSTALL 返回成功，SMR 条目已成功安装。 请您澄清以下问题？ 0x1B001A00U 是 S32K312 上 hseSmrEntry_t.pInstAuthTag[0] 的有效地址吗？ 在后续的安全启动过程中，HSE_B 能否直接访问 UTEST DCF 记录区并读取 pInstAuthTag[0] 引用的签名？ 成功的 HSE_SRV_ID_SMR_ENTRY_INSTALL 响应是否确认持久的 pInstAuthTag[0] 地址对后续启动时的 SMR 验证有效，还是安装服务仅验证通过 hseSmrEntryInstallSrv_t.pAuthTag[0] 提供的签名？ 以下哪种内存区域可接受： hseSmrEntryInstallSrv_t.pAuthTag[0] 和： hseSmrEntry_t.pInstAuthTag[0] 在我们的测试中，当直接使用 UTEST 地址作为 pAuthTag[0] 时，UTEST 地址会被拒绝；但是，当将相同的签名复制到 RAM 中，而 pInstAuthTag[0] 仍然指向 UTEST 时，SMR 安装就会成功。 此配置是否可能通过 SMR 安装，但在下次 RESET 或安全启动时失败，因为 HSE 在启动时无法访问 UTEST 地址？ 当项目不需要 DCF 记录时，是否允许将未使用的 UTEST DCF 记录区域存储客户应用程序数据（例如公钥或 SMR 签名）？ 使用此 DCF 记录区域是否会与 HSE 固件、ROM 启动代码、未来的 DCF 处理、生命周期转换、调试配置或设备配置扫描产生任何冲突？ 在 UTEST 区域中存储原始 512 字节签名是否存在任何对齐、记录格式、ECC、编程、锁定或访问限制？ 如果 pInstAuthTag[0] 不支持 UTEST，持久 SMR 签名是否应该始终存储在普通应用程序代码闪存或数据闪存中？ 我们主要想确认的是，以下配置是否得到官方支持，以及是否安全适用于生产环境： /* 安全启动期间使用的持久签名位置/* smrEntry.pInstAuthTag[0] = 0x1B000A00U;   /仅在 SMR 安装期间使用的临时 RAM 副本 */ pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; MCU：S32K312 HSE 类型：HSE_B 签名算法：RSASSA-PSS，采用 RSA-4096 签名长度：512 字节 持久签名地址：0x1B001A00U 谢谢！ Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar 抱歉，签名位置不是 0x1B000A00U。它是 0x1B001A00U。 Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar 嗨@Yiming2 我在我的开发板上进行了测试，因为文档中没有明确说明是否可以使用 UTEST。我的结果也类似。 如果 pAuthTag = pInstAuthTag = 0x1B001A00，则我收到 HSE_SRV_RSP_INVALID_ADDR 响应。 然后我将 pAuthTag 放入 RAM 内存中，同时 pInstAuthTag 仍然指向 UTEST，这样就可以了。一旦通过 BOOT_SEQ 位启用安全启动，安全启动即成功，应用程序即可正常工作。HSE能够读取UTEST DCF区域中的签名。 根据测试结果，HSE 固件显然会检查地址 pAuthTag 是否位于 RAM 或代码/数据闪存中，而 UTEST 中的 pInstAuthTag 则被接受。 虽然没有相关文档记载，但确实有效。 但如果您不打算更新签名，则可以选择将 HSE_SMR_CFG_FLAG_INSTALL_AUTH 保持为零，这样将使用内部验证方案（内部哈希）进行验证。您的签名仅用于安装，pInstAuthTag 将被忽略。 我认为，如果您不打算更新镜像，那么这种设置更有意义。此外，验证速度也会快得多（哈希算法与 RSA 算法相比）。这可能是保持简单并获得更好性能的最佳方法。 如果设置了 HSE_SMR_CFG_FLAG_INSTALL_AUTH 并使用了 pInstAuthTag，则主要针对想要轻松更新应用程序的用例：应用程序和身份验证标签已更新，您无需修改或重新安装该 SMR。 DCF 扫描到停止记录为止（全部为 0xFF），其余部分将被忽略。通常情况下，DCF 区域不应该用于存储用户数据，但我认为这里没有问题。 UTEST 的唯一限制是它必须是 OTP 区域。同样，ECC 的限制也适用于代码或数据闪存——一旦对对齐的双字进行编程，就不应该再次对同一个双字进行编程，因为这会导致 ECC 错误。 此致， Lukas

S32K312 HSEセキュアブート:pInstAuthTagはUTEST DCFレコード領域に保存されている署名を指し示せますか? こんにちは、NXPサポートチームの皆さん、 S32K312上でHSEベースのSecure Boot with SMRを実装しており、SMR署名がUTEST DCFレコード領域に恒久的に保存できるかどうかを確認したいと考えています。 現在の実装は以下のとおりです。 UTESTには、以下のアドレスから始まる512バイトのRSA-4096署名が格納されます。 0x1B001A00U 占有されている住所範囲は以下のとおりです。 0x1B001A00～0x1B001BFF この地域はUTEST DCF記録領域に属します。 当プロジェクトでは、このエリアにおけるDCFの設定は一切必要ありません。そのため、未使用のDCFレコード空間を公開鍵やSMR署名を含む永久的なセキュリティデータを保存することを検討しています。 ソフトウェアイメージとその署名は当社のユースケースで固定されているため、製品のライフ期間中にシグネチャが変更されることは期待されていません。 SMRエントリでは、署名参照を次のように設定します。 smrEntry.pInstAuthTag[0]= 0x1B001A00U; smrEntry.pInstAuthTag[1]= 0U; 我々の予想では、その後のセキュアブート検証中に、HSE は pInstAuthTag[0] で指定された UTEST アドレスから 512 バイトの署名を直接読み取ります。 HSE_SRV_ID_SMR_ENTRY_INSTALLを通じてSMRエントリをインストールする際、最初にインストールサービス認証タグを同じUTESTアドレスを参照するように設定しました。 pSmrEntryInstall->pAuthTag[0] = 0x1B000A00U; しかし、SMRインストールサービスはHSE_SRV_RSP_INVALID_PARAMを返しました。これは、UTESTアドレスがサービスに対する無効な入力アドレスとして拒否されたためと思われます。 回避策として、SMRインストールサービスを呼び出す前に、UTESTから512バイトの署名を共有RAMバッファにコピーします。 UTEST 0x1B000A00 | | 512バイトをコピー V 共有RAMバッファ 次に、インストール要求を以下のように設定します。 pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; SMRエントリ自体には、以下の内容が含まれています。 smrEntry.pInstAuthTag[0]= 0x1B000A00U; この構成では、HSE_SRV_ID_SMR_ENTRY_INSTALL は成功を返し、SMR エントリは正常にインストールされます。 以下の質問について、もう少し詳しく教えていただけますか? S32K312 上の hseSmrEntry_t.pInstAuthTag[0] のアドレスとして、0x1B001A00U は有効ですか？ その後のセキュアブート時に、HSE_B直接UTEST DCFレコード領域にアクセスし、pInstAuthTag[0]で参照されたシグネチャを読み取ることはできますか? HSE_SRV_ID_SMR_ENTRY_INSTALL 応答が成功した場合、永続的な pInstAuthTag[0] アドレスが後の起動時の SMR 検証に有効であることが確認されるのでしょうか、それともインストール サービスは hseSmrEntryInstallSrv_t.pAuthTag[0] を介して提供される署名のみを検証するのでしょうか？ メモリ領域には、以下の用途で受け入れられる違いがありますか？ hseSmrEntryInstallSrv_t.pAuthTag[0] そして： hseSmrEntry_t.pInstAuthTag[0] 私たちのテストでは、UTEST アドレスを pAuthTag[0] として直接使用すると拒否されますが、同じ署名を RAM にコピーし、pInstAuthTag[0] がまだ UTEST を指している場合は SMR のインストールが成功します。 この構成はSMRインストールに合格しても、次のリセットやセキュアブート時にHSEがUTESTアドレスにアクセスできないため失敗する可能性はありますか? プロジェクトでDCFレコードが不要な場合でも、未使用のUTEST DCFレコード領域は公開鍵やSMR署名などのお客様アプリケーションデータを保存することが許されていますか? このDCFレコード領域の使用は、HSEファームウェア、ROMブートコード、FUTURE DCFプロセッシング、ライフサイクルの移行、デバッグ設定、またはデバイス構成スキャンと競合を引き起こす可能性がありますか? このUTEST領域で生の512バイト署名を保存する際、アラインメント、レコードフォーマット、ECC、プログラミング、ロック、アクセス制限などはありますか? もしUTESTがpInstAuthTag[0]でサポートされていない場合、永続的なSMRシグネチャは常に通常のアプリケーションコードフラッシュかデータフラッシュに保存されるべきでしょうか? 確認したい主な点は、以下の構成が公式にサポートされており、本番環境での使用が安全かどうかです。 /* セキュアブート中に使用される永続的な署名場所/* smrEntry.pInstAuthTag[0] = 0x1B000A00U;   / SMRインストール時のみ使用される一時的なRAMコピー */ pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; MCU:S32K312 HSEタイプ:HSE_B シグネチャアルゴリズム:RSA-PSSとRSA-4096 シグネチャ長:512バイト 永続署名アドレス:0x1B001A00U よろしくお願いします。 Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar 申し訳ありませんが、署名位置は0x1B000A00Uではありません。それは0x1B001A00Uです。 Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar こんにちは@Yiming2 UTESTが使えるかどうかがドキュメントに明示的に記載されていないので、ボードでテストしました。そして、私も同様の結果を得ました。 pAuthTag = pInstAuthTag = 0x1B001A00 の場合、HSE_ SRV_ RSP_ INVALID_ ADDR 応答を受け取りました。 その後、pInstAuthTagがまだUTESTを指している状態で、pAuthTagをRAMメモリに配置したところ、うまくいきました。セキュアブートがBOOT_SEQビットで有効化されると、セキュアブートは成功し、アプリケーションは動作します。HSEはUTEST DCFエリア内の署名を読み取ることができます。 テスト結果に基づくと、HSEファームウェアはアドレスpAuthTagがRAMまたはコード/データフラッシュメモリ内にあるかどうかをチェックし、UTESTのpInstAuthTagは受け入れられることが明らかです。 公式には文書化されていないが、効果はある。 しかし、署名を更新する予定がない場合は、HSE_SMR_CFG_FLAG_INSTALL_AUTHゼロのままにするオプションがあり、内部検証方式(内部ハッシュ)が検証に使われます。署名はインストール時のみに使用され、pInstAuthTagは無視されます。 私の意見では、イメージを更新する予定がない場合は、この設定の方が理にかなっています。また、検証もはるかに高速になります（ハッシュアルゴリズムとRSAアルゴリズムの比較）。これが、シンプルさを保ちつつパフォーマンスを向上させるための最良の方法でしょう。 HSE_SMR_CFG_FLAG_INSTALL_AUTHが設定されてpInstAuthTagを使用している場合、これは主にアプリケーションを簡単に更新したい場合のユースケースを対象としています。つまり、アプリケーションタグと認証タグが更新され、SMRを修正・再インストールする必要がなくなります。 DCFは停止レコード（すべて0xFF）までスキャンされ、残りは無視されます。通常、DCFエリアはユーザーデータ用に使われるべきではありませんが、ここでは問題が見当たりません。 UTESTの唯一の制約は、OTPエリアであるということです。また、ECCに関する同様の制限が適用されます（コードフラッシュやデータフラッシュと同様）。一度アラインメントされたダブルワードがプログラムされると、同じダブルワードを再度プログラムするとECCエラーが発生するため、再度プログラムしてはいけません。 よろしくお願いいたします。 ルーカス

S32K3 请求支持在传输完成后始终开启 LPI2C 引脚低电平超时监控 您好，NXP 我们尝试利用 I2C_MASTER_EVENT_PIN_LOW_TIMEOUT 事件来实现从设备 SDA 保持低电平时的恢复。在测试过程中，我们观察到，一旦传输完成或检测到异常情况，引脚低电平超时中断就会关闭。 我们期望此中断能够持续保持启用状态，因为需要对总线进行实时监控，并且在传输结束时不能清除超时中断启用状态。我们认为当前 RTD 7.0.1 对超时中断的处理存在缺陷。 NXP能否就如何正确处理此事提供官方建议或指导？ 此致， 显龙 Re: S32K3 Request to support always-on LPI2C Pin Low Timeout monitoring after transfer completion 你好@wuxianlong ， 感谢您提供的详细描述以及您指出的驱动程序代码。 您的观察是正确的：在当前的 RTD 实现中，LPI2C_IP_MASTER_PIN_LOW_TIMEOUT_INT 作为主传输中断处理的一部分被启用，并在主传输结束时再次被禁用。这意味着 RTD 驱动程序在传输完成后不会将此中断保持启用状态，作为永久总线监视机制。 从硬件角度来看，S32K3 LPI2C 模块支持引脚低电平超时功能。超时阈值由 MCFGR3[PINLOW] 配置，当选定的 SCL 或 SDA 线保持低电平的时间超过配置的阈值时，可以设置 MSR[PLTF] 标志。参考手册还指出，即使 LPI2C 控制器处于空闲状态，也可以设置此标志。 然而，这种硬件功能并不一定意味着 RTD 驱动程序会持续保持相应的中断启用状态。当前的 RTD 实现似乎是在进行主传输的背景下处理此事件的。 对于传输完成后持续的 I2C 总线监控，建议在应用层进行处理，例如在总线恢复逻辑中检查 MSR[PLTF] 状态。另请注意，引脚低电平问题本身必须通过软件解决。当低电平条件仍然存在时，PLTF 标志不能被清除，必须先清除该标志才能生成新的 START 条件。 此致， 帕维尔

IDEおよびRTDのインストール中に発生した問題 こんにちは、S32DSIDE 3.6.6ソフトウェアをインストールしました。 次に、RTDパッケージをインストールしました。 しかし、下の画像に示すように、新しいアプリケーションプロジェクトを作成する際にSDKが見つかりません。 この問題は長い間私を悩ませてきました。ご回答をお待ちしております。ありがとうございます。私のコンピューターの構成は以下のとおりです。 私のコンピューターには、JDK 8とJDK 17、そしてPythonのバージョン13、14、15がインストールされています。   Re: 关于安装IDE和RTD遇到的问题 ありがとうございます。この問題に気付いた後、gcc-10.2をインストールしようと思いました。コンパイラに関するウェブページを見つけました。 どちらを使えばいいのか分からなかったので、両方のEXEファイルをダウンロードしてインストールしました。 しかし、インストール後、S32DSソフトウェアで新しいプロジェクトを作成しても、gcc-10.2は表示されませんでした。 その後、拡張機能マネージャーからダウンロードしようとしましたが、エラーが発生してダウンロードに失敗し続けました。次に何をすればよいか教えていただけますでしょうか？よろしくお願いいたします。 Re: 关于安装IDE和RTD遇到的问题 こんにちは、 @YangLuYao さん。 ご質問の内容を翻訳しましたので、誤解があればお知らせください。 代わりにNXP GCC 10.2を選択してみてください。S32K1 RTDはまだGCC 11.4をサポートし ていません : よろしくお願いします、 ジュリアン Re: 关于安装IDE和RTD遇到的问题 こんにちは@YangLuYaoさん スタンドアロンツールチェーンをダウンロードする必要はありません。S32DSは既にNXP GCC 10.2を提供しています。 ツールチェーンを選択し、「 1項目をインストール/更新」をクリックした後、「次へ」をクリックすると、S32DSが再起動を促します。再起動後、インストールされていることが確認できるはずです。 もし誤りがあれば教えてもらえますか? よろしくお願いします、 ジュリアン Re: 关于安装IDE和RTD遇到的问题 問題を解決できました。ありがとうございました！ Re: 关于安装IDE和RTD遇到的问题 申し訳ありませんが、ここ2日間は週末だったため、今朝ゲームを再現しようとした際に報告したエラーメッセージはこれです。 Re: 关于安装IDE和RTD遇到的问题 こんにちは、 @YangLuYao さん。 返信が遅くなり申し訳ありません。画像から判断すると、NXP GCC 6.3.1 (ビルド 1620) をインストールしようとしているようですが、実際には v10.2 (ビルド 1728) をインストールする必要があります。 それでも動かなければ、外部インストールを試してみるのも良いかもしれません:S32 Design Studioにソフトウェアをインストールする。 私が確認する項目： インストール時にネットワークが不安定になる。 職場におけるプロキシ／ファイアウォール。 ウイルス対策やセキュリティチェック。 ディスク容量。 それ以外に根本的な原因はわかりません。S32DSを再インストールして、NXP GCC 10.2を再度インストールしてみるのも手です。 よろしくお願いします、 ジュリアン

i.MX RT1170 同步动态随机存取存储器\(SDRAM\) 配置示例（来自 SDK）：自动刷新已禁用？ 您好，NXP团队， 我们参考 MCUXpresso SDK 示例，为我们定制的基于 i.MX RT1170 的硬件创建了 SDRAM 配置： https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/main/_boards/evkbmimxrt1170/demo_apps/shell/shell.mex 我们的设计采用连接到 SEMC 接口的ISSI IS42S16320F SDRAM 。 遗憾的是，使用此配置时，我们偶尔会遇到系统不稳定的情况。在详细检查 同步动态随机存取存储器\(SDRAM\) 设置时，我们注意到示例配置中自动刷新功能似乎已被禁用： 这让我们感到惊讶，因为根据我们的了解，IS42S16320F 需要定期刷新周期来维护数据完整性，因此我们期望自动刷新功能已启用。 请您澄清以下几点？ 提供的 SDK 示例中是否故意禁用了自动刷新功能？ 如果是这样，这种配置背后的逻辑是什么？ 同步动态随机存取存储器(SDRAM)刷新周期是否由SEMC控制器或软件初始化代码在其他地方处理？ 对于采用定制硬件设计的 ISSI IS42S16320F，您是否建议显式启用自动刷新功能？ 感谢您的支持。 顺祝商祺！ i.MX RT101x Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? 你好@Masmiseim ， 示例中提供的 DCD 配置是为 RT1170-EVKB 上使用的同步动态随机存取存储器(SDRAM) 实现的。您可能知道，每个 SDRAM 设备都有自己的时序要求和初始化参数，因此示例中包含的 SEMC 配置可能与您的特定 SDRAM 不完全兼容。 在本例中，自动刷新功能作为最终 同步动态随机存取存储器(SDRAM) 初始化序列的一部分启用。但是，在初始化过程中，自动刷新位保持禁用状态，所需的刷新操作是通过 SEMC IP 命令执行的，如下图所示： 如果您想为 同步动态随机存取存储器(SDRAM) 自定义这些设置，可以使用 MCUXpresso 配置工具生成 DCD。这样，您可以根据设备要求配置 同步动态随机存取存储器(SDRAM) 参数，如下图所示：   另一方面，有一个名为“semc_cm7”的 SDK（版本 26.06）示例，演示了如何将 SEMC 外设与外部同步动态随机存取存储器(SDRAM)一起使用。 最后，Omar 在这篇社区帖子中提供了一个配置 SEMC 寄存器的示例，这可能很有用。 BR 哈比卜 Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? 始终将您尝试使用 SDK 中的任何内容视为示例，因此您应该检查并验证所有内容。

S32K322のSPIデューティサイクルは8MHzでは50%ではありません NXPチームの皆様へ           SPIトランザクション内で8MHzのSPI SCLKを周期的にする必要がある改善活動に取り組んでいます。SPI SCLKを8MHzで測定しました(S32K322ではSPI周辺機器のペリフェラルのドライバによって駆動されます)が、50%のデューティは維持されていないことがわかりました。周波数を1/2/4MHzに下げると、これらのSCLK周波数において50%のデューティ比が維持されることが確認できる。 質問 です - これはペリフェラルのドライバの ハードウェア的な制限なのでしょうか?それともドライバ設定を変えれば8MHzで望む50%の稼働率を得られるのでしょうか? 1MHzで当直が維持されて8MHzでないスクリーンショットをPFA(公開ファイル)してください 注: Saleaeのロジックアナライザーを接続しており、SPI信号を測定するためにより高いサンプリング解像度(250MS/s)を持っています Re: The SPI duty cycle of S32K322 is not 50% for 8MHz こんにちは、 LPSPIクロックのデューティサイクルは、SCKSETおよびSCKHLDタイミングパラメータによって決定されます。これらのフィールドが同じ値にプログラムされている場合にのみ、50/50のデューティサイクルが得られます。選択されたLPSPI機能クロックと8MHzを生成するために必要な分周器の値によっては、クロックジェネレータのタイミング分解能により、正確な50/50のデューティサイクルが実現できない場合があります。観測された76ナノ秒/48ナノ秒の高低時間差は、このような除算器の量子化効果と一致しているように見える。 ですので、LPSPIの機能クロック周波数、TCR[PRESCALE]、およびCCR/CCR1レジスタ(SCKSET、SCKHLD、SCKDIV)の内容から期待デューティサイクルを計算し、異なるクロックソースやディバイダ構成で50/50に近いデューティサイクルが得られるかどうかを判断してください。   BR、ペトル

EasyEVSE 1060 到 sigbrd2x 接口问题 这是对之前帖子的后续： https://community.nxp.com/t5/Power-Energy/EasyEVSE-signal-board-compatibility-and-availability/m-p/2384517 简要说明：我有一台RT1060EVKB/Sigbrd2x EVSE和一个运行v5.0.8软件的RT1064/Sigbrd2x EV，我正在尝试将它们连接起来。这条回复最初是针对上面的问题发布的，但我不太确定技术代表是否跟进了帖子里的回复。 感谢您的回复。我重新开始研究这个问题，但遇到了一些问题，我从NXP的Git仓库下载的EVSE代码v5.0.8无法正常运行。程序编译正常，图形用户界面也能正常显示，但是当我尝试使用其调试接口并请求版本信息时，对于 1060 代码，我得到了正确的 5.0.8 版本响应，但是 sigbrd2x 的版本显示为硬件版本 255，软件版本 255.255.0。我好像记得在某个地方看到过一篇帖子，说1060板上的液晶显示屏存在通信冲突问题。我会编写 sigbrd2x 和单步执行代码，所以我相当确信这部分功能正在运行。我使用的是EVSE-RT106X-CBL，而不是Arduino的接口。除了电动汽车和电动汽车供电设备（EVSE）之间无法通信之外，我的主要症状是上面报告的版本信息似乎有问题，而且我无法跳过EVSE液晶屏上的“固件下载”状态，如果sigbrd2x通电（我是单独给它们供电的），1060上的EVSE代码也无法启动。感觉像是沟通问题。是否有针对此问题的补丁或变通方案？如果是这样，能否提供一些关于如何解决此问题的文档？ 顺祝商祺！ 克里斯·爱德华兹 Re: EasyEVSE 1060 to sigbrd2x interface issues 嗨@chrisedwards ， 感谢您对 NXP MIMXRT 系列产品的关注！ RT1060 似乎正在读取空闲/上拉的 SPI 总线，但没有收到任何有效数据。这意味着 RT1060 ↔ Sigbrd2x SPI 链路从未建立——这也解释了为什么 EVSE 停留在“固件下载”状态，以及为什么双方无法通信。 建议步骤： - 用示波器测量 SPI 线路（SCK/MOSI/MISO/CS）。如果 MISO 保持高电平，则表示板没有响应 → 确认 0xFF。 - 根据信号板手册中的连接器引脚图检查 EVSE-RT106X-CBL 的接线——确认所有 SPI 线 + GPIO 都已正确连接。 - LCD 与 SPI 引脚冲突：暂时禁用 LCD 并重新读取版本以找出问题所在。 - 请按照用户指南中的开机顺序操作，或者先给主机通电。 此致， 加文 Re: EasyEVSE 1060 to sigbrd2x interface issues 嗨，加文， 检查Sigboard的QSPI闪存： 分别给电路板供电后，我没有在U17的SPI引脚上看到任何数据传输（我认为交换机的固件就是从这里获取的）。我确实在我的电动汽车配置（物理上与U17不同的板）的这些引脚上看到了流量。 检查Sigboard的主机接口SPI： 当给 1060 供电，然后给 sigbrd2x 供电（1060 和 sigbrd 分别供电）时，我在主机连接器的 spi 引脚（19、21、23、24）上看不到任何流量；当我通过连接到 J32 的电缆给 sigbrd 供电，并且 J2 和 J3 设置正确时，也看不到任何流量。 从查阅用户指南（UG10140）可知： 我注意到LED灯D18、D21和D33始终不亮。我的电动汽车充电桩上的 sigbrd2x 确实可以。两种设置下，D24指示灯均不亮。D19 闪烁。 禁用图形用户界面后，调试步骤的最终状态： 通过在 EVSE_config.h 中将 ENABLE_EVSE_UI 设置为 0 来禁用 LCD 后，1060 显卡连接到 sigbrd2x 板后可以正常启动。使用从 1060 显卡 J32 接口为 sigbrd 供电的线缆，我可以获取到 sigboard 硬件的版本号 (v2) 和 sigboard 软件的版本号 (v1.2.0)。 信号板的U17端口仍然没有信号传输，D18、D21、D24和D33指示灯也没有亮起。D19闪烁。信号板主机连接器上的 SPI 引脚仍然没有活动。 所以……算是有进展，但感觉转变根本没有发生。用户指南暗示，LED 指示灯亮起表示开关无法工作。 谢谢，并致以最诚挚的问候！ 克里斯

S32K3 転送完了後の常時接続LPI2Cピン低タイムアウト監視のサポート要請 こんにちは、NXP 私たちはI2C_MASTER_EVENT_PIN_LOW_TIMEOUTイベントを利用して、SDAを低く保つスレーブデバイスの復旧を試みました。テスト中に、転送が完了したとき、または異常状態が検出されたときに、ピンロータイムアウト割り込みがオフになることが確認されました。 バスのリアルタイム監視が必要であり、タイムアウト割り込みの有効化は転送終了時に解除されてはならないため、この割り込みは継続的に有効にしておく必要があると考えています。現在のRTD 7.0.1におけるタイムアウト割り込みの処理には欠陥があると考えています。 NXPはこの問題を正しく扱うための公式な推奨や指針を提供できるでしょうか? 敬具 仙龍 Re: S32K3 Request to support always-on LPI2C Pin Low Timeout monitoring after transfer completion こんにちは@wuxianlongさん 詳しい説明とドライバーコードの指摘をありがとうございます。 ご指摘のとおりです。現在のRTD実装では、マスター転送割り込み処理の一環としてLPI2C_IP_MASTER_PIN_LOW_TIMEOUT_INTが有効になり、マスター転送が終了すると再び無効になります。つまり、RTDドライバーは転送完了後にこの割り込みを恒久的なバス監視機構として有効にしないことを意味します。 ハードウェアの観点から見ると、S32K3 LPI2Cモジュールはピンロータイムアウト機能をサポートしています。タイムアウトの閾値はMCFGR3[PINLOW]によって設定され、MSR[PLTF]フラグは選択したSCLまたはSDA回線が設定された閾値より長く低いままの状態で設定できます。リファレンス・マニュアルには、LPI2Cコントローラがアイドル状態でもこのフラグを設定できると記載されています。 しかし、このハードウェア機能があるからといって、RTDドライバーが対応する割り込みを継続的に有効に保つとは限りません。現在のRTD実装は、このイベントをアクティブなマスター転送の文脈で管理しているようです。 転送完了後の連続的なI2Cバス監視では、アプリケーションレベルで処理することが推奨されており、例えばバス復旧ロジックの一部としてMSR[PLTF]の状態を確認するなどです。また、ピンローの状態自体はソフトウェアで解決しなければならないことにもご注意ください。PLTFフラグは低条件がまだ存在している間はクリアできず、新たなSTART条件を生成する前にクリアしなければなりません。 よろしくお願いします、 パベル

IMX95 无法重新父级 can1 我尝试启用 can1 我的设备树引脚遵循 imx95 evk，并禁用 &micfil IMX95_PAD_PDM_CLK__AONMIX_TOP_CAN1_TX 0x39e IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_CAN1_RX 0x39e 但是出现了以下错误。 [ 9.968941] CAN 设备驱动程序接口 [ 9.976800] scmi-pinctrl-imx scmi_dev.8:设置配置错误 -13 [ 9.976814] scmi-pinctrl-imx scmi_dev.8:pin_config_set 操作对引脚 121 失败 [ 9.976893] clk：无法将 can1 重新父级设置为 syspll1_pfd1_di：-1 [ 9.978973] 内部错误：同步外部中止：0000000096000010 [#1] SMP [9.978986]链接的模块：flexcan（+）can_dev neoisp（+）at24 rpmsg_ctrl rpmsg_char pwm_fan enetc4_uio（O）fsl_ecat_enetc4 fsl_ecat_enetc_core moal（O）mlan（O）熔丝 [ 9.979017] CPU: 5 UID: 0 PID: 357 Comm: (udev-worker) Tainted: GMO 6.18.2-rt3-1.0.0-1.0.0 #1 PREEMPT_RT [ 9.979026] 已污染：[M]=MACHINE_CHECK，[O]=OOT_MODULE [ 9.979028] 硬件名称：Axiomtek i.MX95 scm136 板 (DT) [9.979031] pstate：60400009（nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--） [ 9.979035] pc : flexcan_read_le+0x0/0x20 [flexcan] [ 9.979060] lr : flexcan_probe+0x454/0x834 [flexcan] [ 9.979067] sp : ffff800086133820 [9.979069]x29：ffff800086133850 x28：ffff8000862b0000 x27：ffff000085a182a0 有人知道怎么解决这个问题吗？ Re: IMX95 failed to reparent can1 嗨，刘志明 谢谢你的回复。 你说得对，我需要更改系统管理器配置。 Re: IMX95 failed to reparent can1 嗨@HenryHsu 这是我之前在 i.MX95 EVK 上的测试结果，请根据以下修改检查您的 dts 文件。   dts修改：     diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index ab7bd4fdaadf..5eb3011f0894 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -380,7 +380,7 @@ &flexcan1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_flexcan1>; xceiver-supply = <&reg_can1_stby>; - status = "disabled"; + status = "okay"; }; &flexcan2 { @@ -623,23 +623,23 @@ spidev0: spi@0 { }; }; -&micfil { - #sound-dai-cells = <0>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pinctrl_pdm>; - pinctrl-1 = <&pinctrl_pdm_sleep>; - assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>, - <&scmi_clk IMX95_CLK_AUDIOPLL2>, - <&scmi_clk IMX95_CLK_PDM>; - assigned-clock-parents = <0>, <0>, <0>, <0>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>; - assigned-clock-rates = <3932160000>, - <3612672000>, <393216000>, - <361267200>, <49152000>; - status = "okay"; -}; +// &micfil { +// #sound-dai-cells = <0>; +// pinctrl-names = "default", "sleep"; +// pinctrl-0 = <&pinctrl_pdm>; +// pinctrl-1 = <&pinctrl_pdm_sleep>; +// assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2>, +// <&scmi_clk IMX95_CLK_PDM>; +// assigned-clock-parents = <0>, <0>, <0>, <0>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>; +// assigned-clock-rates = <3932160000>, +// <3612672000>, <393216000>, +// <361267200>, <49152000>; +// status = "okay"; +// }; &mu7 { status = "okay"; @@ -960,19 +960,19 @@ IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x4000031e >; }; - pinctrl_pdm: pdmgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e - >; - }; + // pinctrl_pdm: pdmgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e + // >; + // }; - pinctrl_pdm_sleep: pdmsleepgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e - >; - }; + // pinctrl_pdm_sleep: pdmsleepgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e + // >; + // }; pinctrl_ptn5110: ptn5110grp { fsl,pins = <     系统管理器修改： diff --git a/configs/mx95evk.cfg b/configs/mx95evk.cfg index 9250d02..6722097 100755 --- a/configs/mx95evk.cfg +++ b/configs/mx95evk.cfg @@ -389,7 +389,7 @@ SYS ALL # Resources M7P OWNER # CPUs must be first -CAN_FD1 OWNER +// CAN_FD1 OWNER FSB READONLY IRQSTEER_M7 OWNER LPIT1 OWNER @@ -612,6 +612,7 @@ CAMERA5 OWNER CAMERA6 OWNER CAMERA7 OWNER CAMERA8 OWNER +CAN_FD1 OWNER CAN_FD2 OWNER CAN_FD3 OWNER CAN_FD4 OWNER   结果：  

EasyEVSE 1060からsigbrd2xへのインターフェースの問題 これは前回の投稿の続報です。 https://community.nxp.com/t5/Power-Energy/EasyEVSE-signal-board-compatibility-and-availability/m-p/2384517 簡単な概要:私はRT1060EVKB/Sigbrd2x EVSEと、v5.0.8ソフトウェアを搭載したRT1064/Sigbrd2x EVを設置しようとしています。これはもともと上の質問への回答として投稿されたものでしたが、技術担当者がスレッドの回答をフォローアップしたかどうか確信が持てませんでした。 ご回答ありがとうございます。作業を再開しましたが、NXPのGitリポジトリから入手したEVSEコードv5.0.8が動作しないという問題が発生しています。ビルドは問題なく、GUIも表示しますが、デバッグインターフェースを使ってバージョン情報を要求しようとすると、1060コードの5.0.8は正しい応答が出てきます。一方、sigbrd2xのバージョンはhw: v 255、sw: v255.255.0と表示されます。どこかの投稿で、1060ボードのLCDディスプレイに通信上の競合問題が発生しているという記事を読んだ記憶がある。sigbrd2xとstepコードのプログラミングはできるので、その側は確実に実行されているとかなり自信があります。ArduinoヘッダーではなくEVSE-RT106X-CBLを使っています。主な症状は(EVとEVSEの両側が連携しない以外に)上で報告されているバージョンで疑わしいこと、そしてEVSE LCDの「ファームウェアダウンロード」状態を突破できず、1060のEVSEコードがsigbrd2xを起動すると起動しません(別々に電源を入れています)。コミュニケーションの問題のように感じられる。この問題に対するパッチや回避策はありますか？もしそうなら、解決方法のドキュメントを教えてもらえますか? よろしくお願いいたします。 クリス・エドワーズ Re: EasyEVSE 1060 to sigbrd2x interface issues こんにちは、 @chrisedwards さん、 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！ RT1060はアイドル/プルアップされたSPIバスを読み取っているのに有効なデータが返ってこないようです。つまり、RT1060 ↔ Sigbrd2x SPIリンクが確立されなかったことになります。これがEVSEが「ファームウェアダウンロード」のままで、両者が通信しない理由も説明できます。 推奨される手順： - SPIライン（SCK/MOSI/MISO/CS）をスコープします。MISOが高ければ、0xFFが確認される→、委員会は反応しません。 - 信号ボードマニュアルのコネクタピン配置に対してEVSE-RT106X-CBL配線を確認 — すべてのSPIライン+GPIOが正しく接続されていることを確認します。 - LCDとSPIのピン競合：LCDを一時的に無効にして、バージョンを再読み込みして問題を切り分けます。 - ユーザーガイドの電源を入れ順にするか、ホストに先に電源を入れる。 よろしくお願いします、 ギャビン Re: EasyEVSE 1060 to sigbrd2x interface issues こんにちは、ギャビンさん。 sigboardのqspiフラッシュを確認してください。 基板を別々に電源を供給すると、U17のSPIピン(スイッチのファームウェアがここにあると思われます)にはトラフィックが見当たりません。私のEVセットアップ（物理的に異なる基板）のU17のこれらのピンでトラフィックが発生しているのを確認しました。 sigboardのホストインターフェースSPIを確認してください: 1060に電源を供給してからsigbrd2xに電源を供給した場合（1060とsigbrdは別々に電源供給）、またはJ2とJ3が適切に設定されている状態でJ32につながるケーブルを介してsigbrdに電源を供給した場合、ホストコネクタのSPIピン（19、21、23、24）にトラフィックは確認できません。 ユーザーガイド(UG10140)を詳しく調べてみると: LED D18、D21、D33が全く点灯しないことに気づきました。私のEVセットアップに搭載しているsigbrd2xでは、確かに動作します。どちらの設定でもD24は点灯しません。D19が瞬きする。 GUIを無効化した後のデバッグ手順の終了状態： EVSE_config.hでENABLE_EVSE_UIを0に設定してLCDを無効にすると、1060はsigbrd2xに接続している間に起動します。1060のJ32ケーブルでsigbrdを駆動し、sigboardのハードウェア(v2)とsigboard sw v1.2.0のバージョン番号を入手できます。 信号板のU17には依然としてトラフィックがなく、LED D18、D21、24、D33も点灯していません。D19が点滅する。sigboardのホストコネクタ上のSPIピンには、依然として何の反応もありません。 それで...進歩はあるけど、スイッチが全く出てこないように感じる。ユーザーズガイドでは、LEDはスイッチが動作していないことを示しています。 ありがとうございます。よろしくお願いいたします。 クリス

汎用I/O (GPIO) S32K324 MCUに基づく、S32DSを使ってGPIOを高インピーダンス状態に設定する方法。 Re: GPIO ハイ 以前の同様の議論を参照してください: S32K3 GPIO HIGH-Z ピンが以前に内部プルを有効にしていた可能性がある場合、S32K3XXRM のトライステート定義を満たすために、 Siul2_Port_Ip_SetPullSel (..., PORT_INTERNAL_PULL_NOT_ENABLED) を呼び出して PUE=0 を確実にする必要があります。 よろしくお願いいたします ロビン

S32K356 RTD Selection We plan to use the S32K356, but found that only versions 7.0.0 and 7.0.1 are available, but the corresponding autosar...If using autosar R21, which version would you recommend? Re: S32K356 RTD选择 I also tried SW32K3_S32M27x_RTD_R21-11_6.0.0_P05_D2510, but it failed many times. I suspect it's related to the S32Ds version. I've also tried 3.6.7. So, which version of S32D32 should I use? Re: S32K356 RTD选择 Hello @wenming , You are right - even if the S32K356 is mentioned in the Supported Derivatives section of the  SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_ReleaseNotes.pdf , S32K356 project can't be created. The RTD 6.0.0 P05 release notes state that this P05 release adds the S32DS/CT support for the S32K356 derivative.  Best regards, Pavel Re: S32K356 RTD选择 Based on the description of version 6.0.0, it does not support S32K356. Re: S32K356 RTD选择 Hello @wenming , S32K3 RTD versions 6.0.0 (AUTOSAR R21-11) is the recommended option for S32K356 with AUTOSAR R21. Best regards, Pavel Re: S32K356 RTD选择 Hello @wenming , Thank you for the screenshot. From the error message, this does not look like an S32DS version limitation. The error happens while S32DS is collecting/downloading the items to be installed, and the key message is: Unexpected end of ZLIB input stream The failed items are S32DS platform/debug related artifacts, for example: com.nxp.s32ds.doc.platform.resources com.nxp.s32ds.lrc.gdb.arm64.linux.win32 This usually indicates that one of the artifacts was not downloaded completely or was corrupted during download/extraction. So the issue looks more like an update-site/download/cache problem than a direct RTD 7.0.1 versus S32DS 3.6.7 compatibility limitation. Regarding the Release Note: the listed S32DS version should be understood as the baseline/tested S32DS version for that RTD release. However, S32DS is modular, and the RTD installation may still require related platform, tools, debugger, compiler, or documentation components to be updated or installed if they are missing or outdated in the current installation. Please try the following: Restart S32DS and try the installation again. Make sure the network connection to the NXP update site is stable. If possible, use the official offline update-site ZIP/package instead of relying only on online download during installation. Check that the required GCC 10.2 toolchain is installed in S32DS. If the issue remains, please try a clean S32DS 3.6.x installation and then install the base RTD 7.0.1 package first before applying any additional patch/update package. So based on the current screenshot, I would not conclude that RTD 7.0.1 cannot be used with S32DS 3.6.7. The current error points rather to an incomplete/corrupted download of required S32DS update artifacts. For reference, I was able to install SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip successfully in S32DS 3.6.6. In my setup, I only had to additionally install the GCC 10.2 toolchain required by the S32K3 RTD package.   Best regards, Pavel Re: S32K356 RTD选择 I've upgraded my S32DS version to 3.6.10, which can install RTD 7.0.1 without requiring additional components. We'll use S32DS 3.6.10 + RTD 7.0.1 for development now. If autosar is needed later...If there's news of an update to version R21, please let me know. Thank you. Re: S32K356 RTD选择 As shown in the image above, version 6.0.0 QLP01 also fails to install. Another issue is that the RTD release note states that only S32DS 3.6.2 is required for installation. Why is it prompting me to update components when I use version 3.6.7? This is related to the release...The note does not match; what could be the reason? Re: S32K356 RTD选择 How do I resolve the S32DS version incompatibility issue? Why can't I install RTD7.0.1 in S32DS3.6.7, and it keeps prompting me to update? Re: S32K356 RTD选择 Hello @wenming , Q1: How do I resolve the S32DS version incompatibility issue? Could you please be more specific about the exact incompatibility message you see?   Q2: Why can't I install RTD7.0.1 in S32DS3.6.7, and it keeps prompting me to update? The update prompt itself is not an error. S32DS may ask to update related platform/tool packages when the selected RTD package depends on newer or additional components.   Also, please make sure that the GCC 10.2 toolchain required by the S32K3 RTD package is installed in S32 Design Studio.   Best regards, Pavel Re: S32K356 RTD选择 This is an error message when installing RTD 7.0.1. Does it seem to be a version limitation? Also, the S32DS version described in the RTD release should, in principle, be ready to install without needing to update the S32DS components. If component updates are still required, it would be better to recommend the newer installation version, which would be easier to use.

S32K1 相補型PWM こんにちは、NXPの専門家の皆様 私たちは日産のエアコンコンプレッサープロジェクトでS32K142チップを使用しました。しかし、日産は、チップのFTMがどのようにして相補的なPWM出力の実現を保証するのかを知りたいと要請した。そのため、この機能の検証のために、説明資料や裏付け資料、またはテストレポートの提供にご協力をお願いしたいと考えております。ありがとう。 Re: S32K1 Complementary PWM こんにちは@ Chenxu1 チップレベルの保護は主にアーキテクチャ上のもので、1つのチャネルがPWMタイミングを定義し、伴随チャネルは内部補数ロジックによって生成され、オプションのデッドタイム/同期更新ハードウェアにより非重複と整合性のある更新が維持されます。 S32K-RM Rev14.1: Re: S32K1 Complementary PWM こんにちは、Senlentさん。ご返信ありがとうございます。 FTMが相補的なPWMを出力する仕組みについては、我々は明確に理解している。チップレベルでは、補完的な波形が位置をずれていないことをどう保証しているのでしょうか?これがお客様が知りたいことです。 Re: S32K1 Complementary PWM こんにちは@ Chenxu1 AN5303および提供されたベアメタルコードを読み取ってテストできます。 https://www.nxp.com/docs/en/application-note/AN5303.pdf 参考までに、前回のテスト時に記録した手順をいくつかご紹介します。 相補型PWMモードを設定し、2µsのデッドタイムを挿入しました（プロジェクト全体を保存し忘れましたが、変更は非常に簡単です）。

FRDM-MCXA156：MCUXpresso IDE 中的 SWO 跟踪（数据、配置文件和中断）功能无法正常工作 大家好， 我目前正在使用FRDM-MCXA156开发板，在调试过程中遇到了SWO（串行线输出）问题。 虽然应用程序调试成功，但我无法在SWO 跟踪窗口中接收任何数据，包括： SWO 数据 SWO概况 SWO中断跟踪 SWO ITM 控制台 为了排查问题，我已经核实了以下内容： 使用配置工具已正确配置SWO 引脚。 TRACE 时钟已启用并配置为96 MHz ，与 MCU 内核时钟匹配（MCXA156 运行频率为 96 MHz）。 该项目正在使用LinkServer和板载MCU-Link探针进行调试。 尽管进行了这些配置，但在调试过程中所有 SWO 跟踪窗口仍然为空。 为了方便参考，我附上了SWO 跟踪配置、 SWO 数据、 SWO 配置文件和其他窗口的截图，以及相关的项目配置。 对于可能导致此问题的原因，或者在FRDM-MCXA156上启用 SWO 跟踪是否需要任何额外的配置步骤，我非常感谢您能提供任何指导或建议。 感谢您抽出时间提供帮助。 #swo #frdm-mcxa156 开发板 MCXA Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 关于之前的帖子， 下面附上 SWO 启用配置和时钟的屏幕截图。 谢谢！ Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 你好@sidsal 对于 FRDM-MCXA156 板，将 SWO 信号连接到板载调试器的电阻 R36 默认情况下为 DNP（未安装）。请您填充 R36 并再次测试一下好吗？ 谢谢！ BR 爱丽丝 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 感谢@Alice_Yang指出这一点。我检查了 FRDM-MCXA156 原理图，并确认将 P0_2/SWO 信号连接到板载 MCU-Link 调试器的 R36 标记为 DNP。 我还注意到，在 FRDM-MCXN947 上，等效的 SWO 连接 (R130) 装配了一个 0 Ω 电阻。请问FRDM-MCXA156上的R36是否也应该安装一个0Ω电阻，以便通过板载MCU-Link调试器进行SWO跟踪？ 另外，能否请您解释一下为什么 FRDM-MCXA156 默认情况下 R36 未填充 (DNP)？是否有特殊的电路板设计原因或限制，要求该元件保持空置状态？所以我不能使用SWO功能吗？ 感谢您的帮助。 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 你好@sidsal “请问FRDM-MCXA156上的R36是否也需要连接一个0Ω电阻，才能通过板载MCU-Link调试器进行SWO跟踪？ ” 是的。如果要使用 SWO 功能，则需要安装一个 0 Ω 电阻或相应地焊接连接。 另外，能否请您解释一下，为什么FRDM-MCXA156芯片上的R36插槽默认是空的（DNP）？“ 我认为这是因为并非所有用户都需要 SWO 功能，所以默认情况下没有安装 0 Ω 电阻。 谢谢！ BR 爱丽丝 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 感谢@Alice_Yang的支持。

错误报告模块 MCU：S32K148，144引脚封装 RTD 版本：SW32K1_S32M24x_RTD_4.4_3.0.0_QLP03_D2507 S32 DS 版本：3.6.6 目标操作系统：裸机 主机操作系统：Windows 根据以上信息，我在驱动程序模块中找不到名为“ERM”（或任何类似名称）的模块。我查看了 MCAL 和非 MCAL 模块。 ERM 是否支持作为驱动模块，还是用户需要像以前基于“Processor Expert”的旧框架那样操作原始指针？ Re: Error reporting module 非常感谢您提供的最新信息。 Re: Error reporting module 你好@durga_choudhury 是的，你的理解是正确的。它们作为单独的软件包提供，不包含在 RTD 中。 关于此次分居的原因，我目前正在进行内部审查。但是，值得注意的是，SAF 和 SPD 是根据 ISO 26262 功能安全标准开发的安全导向型软件组件。这使得它们能够集成到需要功能安全支持（最高可达 ASIL D）的应用程序中。 Re: Error reporting module 你好@VaneB 感谢您的跟进。所以你的意思是说，这些模块仅在 SPD 驱动程序中受支持，而不受免费提供的 RTD 支持。是这样吗？ 是否有任何理由不能直接通过位操作模块的寄存器来使用这些模块？我尝试了“Processor Expert”驱动程序模型（使用 S32 DS v2.2）的示例，它似乎可以正常工作。 Re: Error reporting module 你好@durga_choudhury 对于 S32K1 设备，可以使用功能安全外设驱动程序 (SPD)。这些驱动程序包括扩展微控制器错误管理器 (eMCEM)，它支持通过错误注入模块 (EIM) 和错误报告模块 (ERM) 硬件模块进行内存错误注入和检测。 有关 SPD 的更多信息，请联系您的 NXP 代表或您所在地区的授权代理商之一（代理商网络 | NXP 半导体）。 BR，VaneB

S32K3 ADC 优化 DMA 流 你好， 当 ADC 组只有一个通道并且选中了“启用 DMA 流组”配置项时，执行 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 函数时会发生硬故障。 对于单个通道，如果选中“无中断 ADC 组”配置项，并且启用了“ACCESS_MODE_STREAMING，选择 ADC 流式 DMA 通道”，则可执行此操作。否则，配置文件中的 DMA 通道数为 255，这在这里是合理的。但我不太明白的是，为什么当 ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER 或 ADC_OPTIMIZE_DMA_STREAMING_GROUPS 为 STD_ON 时，而不是 STD_ON==GroupPtr ->AdcWithoutInterrupt 时，会调用 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 函数。这似乎不合理，而且调用此函数会导致硬故障。 BR， 杰森 Re: S32K3 ADC Optimize DMA Streaming 嗨@ Jason22 下次请不要使用QQ邮箱账号，请使用公司邮箱账号。 我测试过了，但没有发现任何问题。 我附上了我的测试项目和测试结果供你参考。 另外，我检查了你的代码，发现了一些错误。 1.时钟初始化错误，你的代码无法成功运行。 2.“ adc_group0_val ”应归类为“不可缓存区域” 另外： 用户手册中对优化 DMA 流组的使用说明进行了详细说明。 RTD_ADC_UM.pdf Re: S32K3 ADC Optimize DMA Streaming 嗨@ Jason22 这是我的检测结果。如果您使用的是我提供的项目，并且优化级别设置为 -O0，那么我们的观察结果应该是一样的。 我觉得这里没什么问题。如果超出边界，肯定会进入硬故障，但测试结果并没有，这只能说明是编译优化级别的问题。没有必要在错误状态下继续分析。 Re: S32K3 ADC Optimize DMA Streaming 您好@Senlent 我不确定我的操作是否正确——我尝试用你的 ELF 文件进行调试，但没有成功。 请您按照我视频中演示的步骤操作一下好吗？我相信您能够重现这个问题。 步骤如下： 在该行设置断点 Mcl_Init(NULL_PTR); 。 运行程序直到它到达断点。 Mcl_Init(NULL_PTR); 。 禁用所有断点（点击“跳过所有断点”按钮）。 跨过 Mcl_Init(NULL_PTR);（单击“全部执行”按钮） 重新启用断点（单击“跳过所有断点”按钮），然后单击“恢复”按钮。 你会发现 Dma_Ip_ConvertLogicChToHwCh 再次输入，然后 逻辑 是 255。 BR， 杰森 Re: S32K3 ADC Optimize DMA Streaming 嗨@Senlent 很高兴你能看到 LogicCh 是 255。在你的项目中，它确实运行正常，但这属于越界访问，对吗？关于您所说的：“如果超出边界，就应该绝对进入硬故障”——我并不完全同意。C 语言不像 C++ 那样有运行时边界检查。对于指针数组，是否发生硬故障取决于越界访问所获得的值。 考虑一个指针数组：uint32* pArr[2] = {0x20400000, 0x20400004}。假设 pArr 的地址为 0x204300A0，则 pArr[2] 的值存储在地址 0x204300A8 处。如果 0x204300A8 包含 0x20400008，则 *pArr[2]（越界访问，最终读取地址 0x20400008 处的值）不会导致硬故障。但是，如果 0x204300A8 包含 0x1FFFFFF0，则 *pArr[2]（最终从 0x1FFFFFF0 读取）将导致硬故障。两者都是越界访问，但是否会发生硬故障取决于概率。 准确地说，硬故障并非由越界访问本身直接引起，而是因为对指针数组的越界访问得到了一个无效指针，而访问该无效指针触发了硬故障。 正因如此，在你的项目中，访问 Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]->LogicChId.HwChId 不会导致硬故障，但在我的项目中却会导致硬故障。 BR， 杰森 Re: S32K3 ADC Optimize DMA Streaming 嗨@ Jason22 我会把设计团队的反馈意见发给你。 通常情况下，如果这是一个影响重大的漏洞，他们会在新版本中修复，并在发布说明中加以说明。 Re: S32K3 ADC Optimize DMA Streaming 嗨@Senlent 非常感谢您向设计团队报告这个问题。如果有最终结果，我应该在哪里查看？如果确实存在错误，是否会在类似于 SW32K3_S32M27x_RTD_R23-11_7.0.0_D2511_ReleaseNotes.pdf 的文档中公布？ BR， 杰森 Re: S32K3 ADC Optimize DMA Streaming 您好@Senlent 是的，我直接使用了你的项目，没有做任何修改。在你的视频中， Dma_Ip_ConvertLogicChToHwCh 函数被间接调用 Mcl_Init ，这不是预期行为。预期行为是…… Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 间接呼叫 Dma_Ip_ConvertLogicChToHwCh 。我的视频演示了这一点：在运行期间 在 Mcl_Init 过程中，我跳过了所有断点，之后 Mcl_Init 完成后，我重新启用了断点。此时， Dma_Ip_ConvertLogicChToHwCh 再次输入， 逻辑 是255。 BR， 杰森 Re: S32K3 ADC Optimize DMA Streaming 您好@Senlent 非常感谢您的回复。我已经使用公司邮箱注册了一个新账号，本帖关闭后我将使用该账号。 我运行了你的项目，发现没有发生硬故障。但是，我的问题仍然存在。如下面的屏幕截图所示，该函数 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 配置 DMA_IP_CH_SET_MAJORLOOP_LOGIC_LINK_CH DMA通道的参数。当 Dma_Ip_ConvertLogicChToHwCh 被称为， 逻辑 值为 255。 Dma_Ip_pxInit->ppxLogicChannelConfigArray 指向 Dma_Ip_paxLogicChannelConfigArrayPB 数组，大小为 2。访问 Dma_Ip_pxInit->ppxLogicChannelConfigArray[255] 这应该是越界访问。虽然没有发生硬故障，但我认为这并不合理。 这种越界访问是由调用引起的。 关于 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink ，这是我的另一个问题。我已经查看了相关内容。 RTD_ADC_UM.pdf 并且还检查了驱动程序代码。 优化DMA流组（单通道）时，数据直接从CDR传输到用户缓冲区，这与多通道情况下数据先从CDR移动到用户缓冲区的情况不同。 DmaIntermediateBuffer 然后从那里传输到用户缓冲区。 优化DMA流组（单通道） 不使用流式 DMA 通道。在配置文件中，以下值： AdcIpwConfigPtr->Mapping.AdcCountingDmaChanLogicId 数组确实存在 ADC_IPW_INVALID_DMA_CHANNEL_ID （255） 我不明白为什么 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 仍然需要调用。真正应该调用这个函数的是 无中断组（单通道） ，但当 ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER 或者 ADC_OPTIMIZE_DMA_STREAMING_GROUPS 是 STD_ON ，而不是 STD_ON == GroupPtr ->AdcWithoutInterrupt ， Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 函数被调用。 我找到了项目中的问题所在：当我取消选中“数据部分”时，硬故障就不再发生了。然而，我认为这并非问题的关键所在。 BR， 杰森 Re: S32K3 ADC Optimize DMA Streaming 您好@Senlent 最后一条回复里的图片不清晰。我已经以附件的形式再次上传了图片。我用数字给图片编号。 BR， 杰森 Re: S32K3 ADC Optimize DMA Streaming 嗨@ Jason07 @Jason22 请将优化构建选项设置为 -O0。 这是我在单步调试过程中观察到的结果。 这可能是因为版本优化（-Os）阻止了调试器准确映射源代码变量。 Re: S32K3 ADC Optimize DMA Streaming 您好@Senlent 我的项目优化程度为 我运行了你的项目（也使用了 -O0参数），发现它在 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink -> ...... -> Dma_Ip_ConvertLogicChToHwCh ， 逻辑 数值仍然是 255。 在你的截图中，是 Dma_Ip_ConvertLogicChToHwCh 因……而被称为 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink ？ Mcl_Init 也叫 Dma_Ip_ConvertLogicChToHwCh ，在这种情况下 逻辑 为 0，这似乎与您的屏幕截图一致。 我在你的项目中运行了一个测试。 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 间接调用 Dma_Ip_ConvertLogicChToHwCh ，我观察到 &Dma_Ip_pxInit->ppxLogicChannelConfigArray[LogicCh] 是 0x429F28 ，与 &Dma_Ip_pxInit->ppxLogicChannelConfigArray[255] 。 然后我修改了地址处的值。 0x429F28 到 0x1FFFFFF0 ，并执行了第 348 行的代码。 发生了一次硬故障，并且 渔业和海事局 数值为 正如预期的那样，值为 0x1FFFFFF6。 这证实了越界访问确实存在。是否发生硬故障取决于该值。 Dma_Ip_pxInit->ppxLogicChannelConfigArray[255] . Re: S32K3 ADC Optimize DMA Streaming 嗨@ Jason22 这很奇怪，我已经尝试过好几次了。您可以直接调试我提供的 ELF 文件。 Re: S32K3 ADC Optimize DMA Streaming 嗨@Senlent 对不起。步骤4是点击“跨过”按钮。 BR， 杰森 Re: S32K3 ADC Optimize DMA Streaming 嗨@ Jason22 我可能还是没理解你的问题。我想请问一下这个项目运行是否符合预期？如果是这样，会有什么问题吗？ 我看到 LogicCh 显示为 255，但程序运行正常。这样做有什么问题吗？ Re: S32K3 ADC Optimize DMA Streaming 嗨@ Jason22 我可以将此问题转交给设计团队确认。 由于 RTD 驱动程序并非我设计，除非用户遇到问题，否则我不会深入探讨他们这样设计的原因。 反馈过程可能需要一些时间，但我会将调查结果转达给相关的设计团队。

LX2162A USXGMII 链路始终无法建立连接。 大家好， 我有一个由Solidrun公司生产的LX2162A系统模块。我目前使用的是Clearfog开发套件，但很快会换成定制的载体。 Solidrun 提供基本的 RCW/DCP/DPL，我已经验证了其功能。就我而言，dpmac3 的 DPC 适用于 SFP 笼，我可以通过 SFP DAC 电缆和各种 SFP 模块获得 XFI 连接。 RCW“rcw_2000_650_2900_3_11_0_auto”设置为SerDes1=3，SerDes2=11，我使用的是QorIQ内核（lf-6.6.52-2.2.0）和mc-utils（10.39.0），但两者都应用了一些Solidrun补丁。Uboot和其他一些东西也被打上了补丁。所有补丁均来自此处： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 我有一套 MaxLinear GPY245-EKV-1（和 -2）开发套件，需要通过 DAC 电缆使用 USXGMII 将 phy 连接到设备。这似乎很正常。最终，这款物理芯片将被集成到 SerDes2=7 的第 6 道和第 7 道中，但我必须使用 Clearfog 上的 SFP 插槽进行测试。 Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP 我只是想配置 dpmac3 通过 DPC 使用这个 USXGMII 链路： mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; （我也尝试过 MAC_LINK_TYPE_BACKPLANE） 已通过“restool dpmac info dpmac.3”确认显示“DPMAC 以太网接口：DPMAC_ETH_IF_USXGMII”。 在Linux系统中，我添加了MaxLinear驱动程序并修复了一些问题： gpy_update_interface() 修复（LKML，Daniel Golle）。这导致 USXGMII 接口返回 -EINVAL，使 phy_state_machine 崩溃。 已修复 pcs-lynx.c 中的 lynx_pcs_config_usxgmii() 函数。同时通过 mdiobus_c45_modify() 写入 MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART)，因为该函数只写入了 MII_ADVERTISE，而从未在复制器块本身上启用 AN。这一问题与本论坛上的另一篇帖子（“LS1028A 10g-qxgmii phy 启动”）相吻合，该帖子也发现了相同的症状（MMD31.0/复制器）。控制寄存器卡在 0)，手动设置第 12 位后，AN 开始工作。 这是 DPMAC3 Linux 设备树条目： &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; 其中 `gpy245_0` 是 MDIO 节点。MDIO 到物理层的流量正常。 我在 lynx_pcs 驱动程序中添加了一个打印输出，用于显示读取结果： mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 问题： 鉴于对该 PCS 实例上的 MDIO_MMD_VEND2 寄存器的写入似乎不会持久，在 LX2162A 系列 SoC 上的 USXGMII 接受配置之前，是否需要已知的额外步骤（SerDes/PCS 块使能、协议特定的初始化或类似步骤）？协议 3 是否已针对 dpmac3 上的 USXGMII 进行了全面验证，还是主要针对 XFI 进行设计/测试？ 其他问题： 也许我不了解 GPY245 和 USXGMII。我看到有些人称之为 QXGMII，但我不知道 LX2162A 是否能够实现这个功能。 或许我需要联系 Solidrun，但他们所有的补丁似乎都没有限制 LX2162A 的功能。 谢谢！ Re: LX2162A USXGMII link never completes LX2162A 端的文档显示，它支持您所使用的路径上的 USXGMII ，但您所描述的症状看起来不像缺少 Linux pcs-lynx 写入，而更像是所选的 PCS 实例实际上仍未处于 USXGMII 应用程序模式，或者 MC 固件正在对错误的 10G PCS 选择器进行编程。 对于SerDes1 协议 3 ，LX2162A 参考手册将所有四个 SerDes1 通道列为 USXGMII / XFI，其中第一个通道为 USXGMII / XFI.3，这对应于您在 Clearfog SFP 路径上测试的 DPMAC3 用例。对于您未来的自定义载波目标， SerDes2 协议 7还将通道 6 和通道 7 记录为 USXGMII / XFI.13 和 USXGMII / XFI.14。 需要注意的是，USXGMII / XFI 条目不会自动显示为“USXGMII”。参考手册指出，在同一通道上，USXGMII 和 XFI 之间的默认值为 XFI。模式是通过协议配置寄存器 C (PCCC)选择，其 SXGMII*_XFI 位选择 0b = USXGMII 和 1b = XFI/SFI。因此，我首先要检查的不是 Linux BMCR 写入本身，而是DPMAC3 的特定 SXGMII 实例在 MC/DPC 初始化后是否清除了其 PCCC XFI 选择位。 MC 固件中出现此类故障并非 Linux PCS 驱动程序中的故障，此前也有过先例：一个 LX2162A 工单显示，MC 在 USXGMII 配置的 PCCC 中清除了错误的 10G 接口选择器，而 MC 固件工程版本 10.35.101 解决了该问题。另一张工单指出，MC 设置由 MC 固件完成，NXP 以二进制形式提供 MC。由于您使用的是 MC 10.39.0，因此您应该已经过了那个特定的旧修复程序，但您看到的故障模式仍然与“MC 没有将预期的 PCS 置于 USXGMII 模式”或“正在处理错误的 PCS 实例”一致。 接下来我会这样做： 在 Linux 进行任何更改之前，请阅读 PCCC。 在 RCW + MC + DPL/DPC 加载之后，但在 Linux PCS 驱动程序运行之前，读取 PCCC 并确认相关的 SXGMII*_XFI 位为 0。适用于 DPMAC3 / USXGMII/XFI.3预计会是第一个 SXGMII 选择器，而不是 MAC13/14 选择器。如果该位保持为 1，则该通道仍然是 XFI/SFI，并且您的 VEND2/USXGMII PCS 写入不会应用于活动的 USXGMII PCS 路径。 检查 MDIO 访问是否连接到预期的 PCS 管理端口。 SXGMII 协议控制寄存器有一个 MDEV_PORT 字段，用于匹配 MDIO 访问。手册中指出，软件在更改该字段后必须至少等待 3 个平台时钟周期，然后才能对 SGMII/PCS 目标进行 MDIO 访问。如果 MDIO 地址解码错误，写入操作可能会“无法持久”，因为您正在读取不同的或重置/默认的 PCS 窗口。 确认 USXGMII AN 寄存器只有在模式选择正确后才有意义。 USXGMII PCS CONTROL 寄存器的第 12 位具有 AUTO_NEGOTIATION_ENABLE，而 DEV_ABILITY / PARTNER_ABILITY 是 RW 寄存器。DEV_ABILITY 下供应商任意速度字段必须非零，因为零会导致自动协商失败。但如果 PCCC 仍然选择 XFI，那么这些 BMCR/能力写入并不是真正的根本问题。 除非 GPY245 板文档明确说明，否则不要将 QXGMII 视为单独的必需外部协议。 LX2162A 文档确实包含 QXGMII 协议变流器寄存器，包括 RESET/掉电控制位，例如 PD_QXGM 和 RST_QXGM。NXP 社区关于 LS1028A 的资料也提到了 10G_QXGMII Lynx SerDes 驱动程序路径。但是您选择的已记录的 LX2162A DPMAC 接口仍然是 USXGMII / XFI，NXP 文档单独指出 LX2160 类设备支持 USXGMII，“SXGMII”不是同一回事。换句话说：“QXGMII”在驱动程序/社区讨论中的引用可能描述的是内部转换器/驱动程序命名路径，不一定与您配置的USXGMII模式不同的MAC到PHY协议。 对于本次 Clearfog SFP 测试，请保持 DPC 简单。 MAC_LINK_TYPE_PHY with enet_if = "USXGMII"  是 MDIO 上管理外部 PHY 的更自然模型。除非您有意使用背板/KR 风格的流程，否则我不认为 MAC_LINK_TYPE_BACKPLANE 可以修复面向 PHY 的 USXGMII 设置。 我不会得出协议 3“主要仅限 XFI”的结论。参考手册将协议 3 记录为 DPMAC3 的 SerDes1 通道的 USXGMII / XFI。我无法从检索到的材料中证实的是，有单独的验证声明称“协议 3 + DPMAC3 + USXGMII 已通过 GPY245 验证”。更有力、有证据支持的说法是：硬件模式存在，默认为 XFI，除非 PCCC 选择 USXGMII，并且已知 MC 固件有先例对错误的 10G PCS 选择器进行编程。 针对您具体的回读： 写入 ADV=0xd601 BMCR=0x1a00 回读 ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 如果 PCS 实例未完全启用/选择用于 USXGMII，或者 MDIO 管理窗口未指向预期的 PCS 实例，则这正是我所期望的结果。在添加更多 Linux 端写入之前，我会先验证 PCCC 和 MC 日志。 LX2162A 协议 3 已记录在案，适用于 DPMAC3 上的 USXGMII / XFI，但 USXGMII 依赖于 MC/PCCC 选择 USXGMII PCS；如果 VEND2/BMCR 写入没有持久性，首先要证明 DPMAC3 的正确 PCCC 位已清除，并且 MDIO 正在寻址正确的 SXGMII PCS 实例。 Re: LX2162A USXGMII link never completes @yipingwang非常感谢您的详细解答！ 你说的都很有道理，我已经开始更多地了解这个平台了。我已经开始使用 AN13329.pdf 中的建议。部分地址和功能似乎无法正常工作（可能是版本不匹配），但至少我可以获取如下所示的 MC 日志： => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ 我尝试通过 uboot 来操作 PCCC。以下是相关内容： crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... 我真心希望 0x1ea10b0 是正确的地址。根据 LX2162ARM.pdf 文件，那*可能*是正确的地址，解码后显示： A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI 是否应该观察正确的寄存器地址（PCCC）？我还能提供其他信息吗？ 谢谢！

旧ハードウェアと新ハードウェアのバージョン番号の違い 左側の旧バージョン（332）は使用できるのに、右側の新バージョン（B222）は使用できないのはなぜですか？332とB222の違いは何ですか？ B222を正しく動作させるにはどうすればよいですか？ Re: 新舊硬件版號差別 こんにちは、ダレンさん。 このことはアプリケーションチームと話し合いました。提供されたスクリーンショットから判断すると、GUIが新しいB222バージョンをサポートするために更新や再設計されていない可能性があり、これが古い332バージョンが正しく動作するのに対し、B222が動作しない理由を説明している可能性があります。 さらに調査のために、当社のアプリケーションエンジニアがチームと共に詳細を確認したいと考えています。彼が直接連絡し、分析を継続し、バージョン332とB222の違いやB222での正常動作を可能にするために必要な手順について話し合う予定だと聞いています。 BRs、トーマス

RW612 WiFi InitがHAL_ImuLinkIsUp()で停止する 私はカスタムボード上でMQTTのサンプルを実行しようとしています。使用されているモジュールはublox IRIS-W106-30Bです。j-linkを使用してWiFiファームウェアブロブを個別にインストールする手順に従いました。しかし、WPL_Init() 関数内で無限ループに陥ってしまっています。 私も同様の問題でBLEを初期化できませんでした。 MCUXpressoを使用したSDK 25.09.00 Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() SDK_2.x_RW610 mqtt のサンプルから、「main_task」以降のすべてを既存のプロジェクトにコピーしました。残る大きな違いは、ハードウェアの初期化部分です。サンプルコードのどの部分がIMUの初期化不良の原因となっているのか特定できません。 カスタムボード上でベースサンプルプロジェクトを動かすことはできますが、既存のプロジェクトにポートすることはできません。 Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() RD-RW61X-BGA SDKを使っていますか?それともFRDM-RW612のSDKですか? 元の例をモジュールに移植するためにどのファイルを修正しましたか? Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() こんにちは、 簡単な「Hello World」の例をテストしていただけますか？ また、モジュールを有効にするために必要な変更は既に適用済みですか？詳しい手順については、以下の記事をご参照ください。 よろしくお願いいたします。 ダニエル。 Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() はい、通常のアプリケーションコードを実行したり、UARTにログを記録したりできます。 Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() 私の理解が正しければ、カスタムボード上でWi-FiとBluetoothのサンプルを問題なく実行できるということですね。問題は、ネットワーク機能を自分のアプリケーションに統合または移植し始めたときに発生します。 私のおすすめは、MQTTの例をアプリケーションの基盤として使うことです。もしWi-FiとBT/BLEを同時に動作させる必要がある場合は、既存のカスタムアプリケーションに共存サポートを追加するよりも、共存例の一つから始めて、その上にアプリケーション固有の機能を追加する方が良いでしょう。 ちなみに、SDK 25.09はすでに3つのリリースから遅れています。続ける前に最新のSDK 26.06にアップグレードすることをお勧めします。