RW612 WiFi 初始化卡在 HAL_ImuLinkIsUp() 处 我正在尝试在自定义板上运行 MQTT 示例。所用模块为 ublox IRIS-W106-30B。我按照说明使用 j-link 单独安装了 wifi 固件 blob。但是，我在 WPL_Init() 函数中陷入了无限循环。 由于类似问题，我也无法初始化BLE。 SDK 25.09.00 使用 MCUXpresso Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() 您使用的是 RD-RW61X-BGA SDK 还是 FRDM-RW612 SDK？ 为了将原始示例移植到您的模块中，您修改了哪些文件？ Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() 如果我理解正确的话，您可以在您的定制板上运行 Wi-Fi 和蓝牙示例程序，没有任何问题。当您开始将网络功能集成或移植到自己的应用程序中时，问题就出现了。 我的建议是以 MQTT 示例为基础来开发你的应用程序。如果您的使用场景需要 Wi-Fi 和 BT/BLE 同时运行，那么最好从共存示例之一入手，并在其基础上添加您特定应用的功能，而不是之后尝试向现有的自定义应用程序添加共存支持。 顺便一提，SDK 25.09 已经落后三个版本了。我建议您在继续操作之前升级到最新的 SDK 26.06。 Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() SDK_2.x_RW610 我从 mqtt 示例中复制了“main_task”及其之后的所有内容到我现有的项目中。这就留下了硬件初始化方面的主要区别。我无法确定示例中的哪些方面导致IMU无法初始化。 我可以在我的定制板上运行基础示例项目，但无法将其移植到现有项目中。 Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() 是的，我能够运行正常的应用程序代码，也能将日志记录到UART等等。 Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() 您好， 您能否测试一下简单的“Hello World”示例？ 另外，您是否已经进行了必要的修改以启用您的模块？请参考以下文章获取指导。 问候， 丹尼尔。

エラー報告モジュール MCU:S32K148 144ピンパッケージ RTDバージョン：SW32K1_S32M24x_RTD_4.4_3.0.0_QLP03_D2507 S32 DS バージョン: 3.6.6 対象OS: ベアメタル ホストOS: Windows 上記の方法では、ドライバーモジュールに「ERM」というモジュール(またはそれに類するもの)が見つかりません。私はMCALモジュールと非MCALモジュールの両方を調べました。 ERMはドライバモジュールとしてサポートされているのか、それともかつての「プロセッサ Expert」ベースのフレームワークのようにユーザーが生のポインタを操作すべきなのか? Re: Error reporting module こんにちは、 @durga_choudhuryさん はい、あなたの理解は正しいです。これらは別のソフトウェアパッケージとして提供されており、RTDの一部には含まれていません。 今回の離職理由につきましては、現在社内で検討中です。しかし、SAFとSPDはISO 26262機能安全基準に準拠した安全志向のソフトウェアコンポーネントとして開発されたことに注意が必要です。これにより、ASIL Dまでの機能安全サポートを必要とするアプリケーションへの統合が可能となります。 Re: Error reporting module 最新情報をお知らせいただき、誠にありがとうございます。 Re: Error reporting module こんにちは、 @durga_choudhuryさん S32K1デバイスには、セーフティ ペリフェラル ドライバ(SPD)が利用可能です。これらのドライバには、エラー注入モジュール(EIM)およびエラー報告モジュール(ERM)を通じたメモリエラー注入と検出をサポートする拡張マイクロコントローラエラーマネージャ(eMCEM)が含まれます。 SPDに関する詳細は、NXPの担当者またはお住まいの地域の認可代理店(代理店ネットワーク | NXP Semiconductors)にお問い合わせください。 BR、VaneB Re: Error reporting module こんにちは、 @VaneBさん フォローアップありがとうございます。つまり、これらのモジュールはSPDドライバのみでサポートされていて、無料で入手できるRTDには対応していないということですね。それで合っていますか？ なぜ誰かがモジュールのレジスタをビットバンするだけでこれらのモジュールを使えないのでしょうか?『プロセッサ Expert』ドライバモデル(S32 DS v2.2使用)の例を試してみたところ、動作しているように思えました。

KITFS24SKTFDMEVMとNXP GUIを使用してFS2400と通信できません 件名： KITFS24SKTFDMEVMとNXP GUIを使用してFS2400と通信できない こんにちは、 私はKITFS24SKTFDMEVM評価ボードを使ってFS2400のOTPを設定しプログラムしようとしています。 評価ボード: https://www.nxp.com/design/design-center/development-boards-and-designs/KITFS24SKTFDMEVM しかし、ボードをNXP GUIに接続しても、デバイスとの通信を確立できません。GUIには下記のエラーが表示され、通信は行われません。 以前は FS26 評価ボードで同じNXPのGUIを使って問題なく使っていたので、PCのセットアップとGUIのインストールは正常に動作していると思います。 評価ボードはデフォルトの設定で、ジャンパーやスイッチの設定は意図的に変更していません。確認のため、現在の構成は以下のとおりです。 S12 (OTP):オフ J30: ピン1-2接続 SW4 (WAKE2):オン S19 (WAKE3):オン J33:オープン J37: ピン2-3コネクテッド J36: ピン2-3コネクテッド J10: ピン2-3コネクテッド SW9: 全てのスイッチオン J45: ピン2-3コネクテッド J26: ピン5-6および9-10が接続 SW20: すべてのスイッチはオフです シーズン2: ON(回路図でこのスイッチを見つけられませんでした) SW18: 全てのスイッチオン SW1(メイン電源スイッチ): 3位(2-3位) 評価ボードの S32K144 MCUはプログラムしていません 。私の理解では、基板には必要なファームウェアが既にプログラムされた状態で出荷されるはずです。これが正しいのか、それともGUIがFS2400と通信する前にMCUをフラッシュする必要があるのか、誰か確認してもらえますか? 以下はGUIに表示されたエラーメッセージです。 どんなご支援でも大変感謝いたします。 よろしくお願いします。 FS85&FS84 FSBC+PMIC Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI こんにちは、 お問い合わせいただきありがとうございます。 UM12015 KITFS24SKTFDMEVMユーザーマニュアルの第5節「ソフトウェアとツールのインストールと設定」に従ってファームウェアを更新していただけますか?この手順で、発生しているエラーは解決するはずです。 アップデートを完了しても問題が続く場合は、ハードウェアの構成画像を教えていただけますか?これにより、設定を確認し、問題をさらに調査するのに役立ちます。 よろしくお願いします！ Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI こんにちは、 @ErikaC さん。 ご返信ありがとうございます。 UM12015 KITFS24SKTFDMEVMユーザーマニュアルの第5節 「ソフトウェアとツールのインストールと設定 」を確認しました。しかし、ドキュメントに記載されているKITFS2400FRDMEVM_HW_Test_Package_W20.zipファイルが見つかりません。 この.zipをダウンロードできる場所を教えていただけますかファイル？マニュアルに記載されているとおり、ファームウェアをアップデートするために必要です。 NXPのGUIでfs23xx-fw-FS24-v0.86.hexを見つけることができました。これはアップデートに使用するファームウェアファイルですか、それともKITFS2400FRDMEVM_HW_Test_Package_W20.zipに含まれている別のファイルですか？ マニュアルに記載されているリンクも確認しました: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=S32DS-IDE-ARM-V2-Xそこから実行ファイルをダウンロードしてインストールしました(これはDesign Studioで、メインのS31244_Flashファイルではありません)が、必要な.zipが見つかりませんでしたパッケージ. KITFS2400FRDMEVM_HW_Test_Package_W20.zipのダウンロード場所を教えていただけるか、アップデートに必要な正しいファームウェアパッケージの入手先を教えていただけますか? ご協力ありがとうございます。 ガネーシュ・バグワット Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI こんにちは、 KITFS2400FRDMEVM_HW_Test_Package_W20.zipフォルダは見つかりませんでした。おそらくNXPGUIの以前のバージョンに含まれていた機能でしょう。しかし、そのパッケージにはfs23xx-fw-FS24-v0.86.hexファイルのみが含まれており、ファームウェアをプログラムするために必要な唯一のファイルです。 UM12014 KITFS2400FRDMEVMユーザーマニュアルに記載されているすべての手順に従ってください。図17に示されているようにデバッガの使用が必要であり、S32 Design Studioツールもインストールする必要があります。 ファームウェアアップデート手順は、必要なデバッガ接続とユーザーマニュアルに記載されたソフトウェア環境がなければ成功裏に完了できません。 お役に立てば幸いです！ Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI こんにちは、 @ErikaC さん。 fs23xx-fw-FS24-v0.86.hexが正しいファームウェアファイルである場合、この.hexファイルを直接ロード/フラッシュするために必要な特別な手順はありますか？KITFS24SKTFDMEVM にファイルを転送すればよいのでしょうか、それとも特定のツールや設定が必要なのでしょうか？ 可能であれば、 KITFS2400FRDMEVM_HW_Test_Package_W20.zip パッケージやダウンロード先を教えていただけると、マニュアルに記載されたファームウェアアップデート手順をずっと簡単に進めます。 助けてくれてありがとう。 ガネーシュ・バグワット Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI こんにちは、 @ErikaC さん。 ありがとうございます。うまくいきました。NXP-GUIと通信できるようになりました。 唯一の問題は、これら2つの設定がデフォルトでは存在していなかったことだった。ご指摘のとおり、それらを追加した後はすべて正常に動作しました。 実行可能ファイルの下に追加されたコマンドは次のとおりです。 ${cross_prefix}gdb${cross_suffix} 改めてサポートありがとうございます。 よろしくお願いいたします。 ガネーシュ・バグワット

关于“MPC5777C-1b+2b_RAM_ECC_error_injection GHS614”示例代码 你好。我目前正在基于MPC5777C MCU进行开发。 我有一个关于开发过程的问题。 我根据“MPC5777C-1b+2b_RAM_ECC_error_injection GHS614”示例代码设计了执行 ECC 检查的代码。 正常情况下，这段代码能够正确执行 ECC 检查。 但是，当使用 Trace32 等调试器连接到 MCU 并运行 ECC 检查代码时，经常会出现无法检测到位错误的错误。 “GHS614”示例代码整体上连接到 Trace32 等调试器时是否可能无法正常工作？ 谢谢！ Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code 您好。 假设 Trace32 调试器已连接，转储窗口已打开，并且我的自定义应用程序代码正在运行，是否有可能出现这种情况：在参考 GHS614 设计的 ECC 检查函数中未检测到位错误？ Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code 你好， 我不确定你的设置，但要注意，Trace中任何打开的转储窗口都会持续读取内存，一旦检测到ECC故障会立即触发。 ECC错误永远不会发生在未损坏的地址上。ECC机制也受到EDC的保护。这根本不可能。 顺祝商祺！ Peter Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code 你好， 如果软件或调试器读取的地址损坏，则 ECC 始终会发出错误信号，而与示例软件或任何其他因素无关。 顺祝商祺！ Peter Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code 您好。 我将更详细地解释一下情况。 我的ECC校验码执行如下： (void)FCCU_ClearNCF(); /* 1 位 RAM 数据错误注入 */ GenerateRam1bitEccError(); uiErmSR0 = ERM.SR0.R; uiErmSR1 = ERM.SR1.R; uiErmSR2 = ERM.SR2.R; /// 4. 如果发生 RAM 1 位 ECC 错误，请执行以下操作。 如果((((uiErmSR0 & ERM_SR0_1b_all) == ERM_SR0_1b_PRAMC_1) || ((uiErmSR2 & ERM_SR2_1b_all) == ERM_SR2_1b_Core1_data)) && ((uiErmSR1) == CLEAR)) { /// 4.1.如果 ERM EAR 寄存器中存储的值与发生错误的地址相同，则执行以下操作。 if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_PRAMC_1].EAR.R)) { ucStatus = OK； } /// 4.2.如果 ERM EAR 寄存器中存储的值与发生错误的地址不同，请执行以下操作。 否则如果((UINT32)auiTest == (ERM.ERROR[ERM_chnl_Core1_data].EAR.R)) { ucStatus = OK； } else { ucStatus = NOT_OK }; } /// 5.如果没有发生 RAM 1 位 ECC 错误，请执行以下操作。 else { ucStatus = NOT_OK }; 该结构强制注入 1 位 RAM 数据错误，并检查 ECC 错误是否成功发生以及是否准确检测到发生地址。 如果在运行上述代码时启用 Trace32 内存转储窗口，ECC 检查的结果是否会异常执行？（即未能检测到 ECC 错误或 ECC 发生地址处的错误） 谢谢！

S32K3 ADCのDMAストリーミング最適化 こんにちは、 ADCグループが1つのチャネルしか持たず、AdcのEnable Optimized DMA Streaming Groupsの設定項目がチェックされている場合、Adc_Ipw_SetupTcdSingleAdcChannelMajorLink関数の実行時にハードフォルトが発生します。 単一チャネルの場合、Adc Group Without Interruptsの設定項目がチェックされACCESS_MODE_STREAMINGされた場合、「Select Adc Streaming 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.clock initが間違っている、コードが正常に動作しないはずがない。 2. adc_group0_valは「キャッシュ不可領域」の属性であるべきです また： DMAストリーミンググループの最適化の使い方はユーザーマニュアルに明確に説明されています。 RTD_ADC_UM.pdf Re: S32K3 ADC Optimize DMA Streaming こんにちは、@ Jason22 これが私のテスト結果です。私が提供したプロジェクトを使用し、最適化レベルを-O0に設定している場合、私たちの観察結果は同じになるはずです。 私はここに何の問題もないと思います。境界を超えた場合は確実にハードフォルトに入るはずですが、テスト結果はそうでなく、これはコンパイル最適化レベルが原因であることを意味しています。エラー状態下では、分析を続ける必要はありません。 Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent この問題を設計チームに報告してくださり、誠にありがとうございます。最終結果がある場合、どこで確認すればよいですか？もし実際にエラーが発生した場合、SW32K3_S32M27x_RTD_R23-11_7.0.0_D2511_ReleaseNotes.pdf のような文書で公開されるのでしょうか？ BR、 ジェイソン Re: S32K3 ADC Optimize DMA Streaming こんにちは、@ Jason22 デザインチームのフィードバックをお送りします。 通常、重大な影響を及ぼすバグの場合は、新しいバージョンで修正版をリリースし、リリースノートに記載します。 Re: S32K3 ADC Optimize DMA Streaming Hi@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 こんにちは@Senlent はい、あなたのプロジェクトを一切変更せずに使用しました。あなたのビデオでは、 Dma_Ip_ConvertLogicChToHwCh 関数は間接的に呼び出されます Mcl_Initは意図された動作ではありません。意図された動作は Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 間接的に呼びかける Dma_Ip_ConvertLogicChToHwCh 。私のビデオではこれを実証しています。 Mcl_Init で、すべてのブレークポイントをスキップし、その後 Mcl_Init 完了したので、ブレークポイントを再度有効にしました。その時点で、 Dma_Ip_ConvertLogicChToHwCh 再び入力され、 ロジックCh 255でした。 BR、 ジェイソン Re: S32K3 ADC Optimize DMA Streaming こんにちは@Senlent ご返信いただき、誠にありがとうございます。会社のメールアドレスを使って新しいアカウントを登録し、このスレッドが終了した後はそのアカウントを使う予定です。 あなたのプロジェクトを実行しましたが、ハードフォルトは発生していませんでした。しかし、私の疑問は依然として残ります。以下のスクリーンショットに示すように、function Adc_Ipw_SetupTcdSingleAdcChannelMajorLink は DMAチャネルの DMA_IP_CH_SET_MAJORLOOP_LOGIC_LINK_CH パラメータを設定します。 Dma_Ip_ConvertLogicChToHwCh が呼ばれると、 LogicCh 値は255.Dma_Ip_pxInit->ppxLogicChannelConfigArray はサイズ2の Dma_Ip_paxLogicChannelConfigArrayPB array を指しています 。アクセス Dma_Ip_pxInit->ppxLogicChannelConfigArray[255] は境界 外アクセスであるはずです。ハードフォルトは発生しませんでしたが、これは合理的ではないと思います。 この境界外アクセスは通話によって引き起こされます Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 、それもまた私の疑問です。関連する内容は RTD_ADC_UM.pdf で確認 し、ドライバーコードも確認しました。 最適化DMAストリーミンググループ(単一チャネル)では 、データはCDRから直接ユーザーバッファへ転送されます。マルチチャネルの場合とは異なり、まずCDRから DmaIntermediateBuffer へデータが移動され 、そこからユーザーバッファへ移動されますOptimize DMA Streaming グループ(単一チャネル) ストリーミングDMAチャネルは使用していません。設定ファイル内の AdcIpwConfigPtr->Mapping.AdcCountingDmaChanLogicId arrayの値は確かに ADC_IPW_INVALID_DMA_CHANNEL_ID (255)です。 なぜそうなのか理解できません Adc_Ipw_SetupTcdSingleAdcChannelMajorLink まだ電話をかけてないと。本来呼び出すべき関数は Without Interrupt グループ (single チャネル)ですが、wh ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER or ADC_OPTIMIZE_DMA_STREAMING_グループ is STD_ON、代わりに STD_ON == GroupPtr ->AdcWithoutInterrupt, the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink functionが呼ばれます。 プロジェクトで問題を発見しました。「データセクション」のチェックを外すと、ハードフォルトが発生しなくなります。しかし、私はこれが問題の本質的なポイントだとは思いません。 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で、あなたのプロジェクトを実行しました (これも -O0 で)。 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink -> ...... -> Dma_Ip_ConvertLogicChToHwCh 、 ロジックCh 値は依然として255です。 あなたのスクリーンショットでは、 Dma_Ip_ConvertLogicChToHwCh 結果として呼ばれる Adc_Ipw_SetupTcdSingleAdcChannelMajorLink ? Mcl_Init また Dma_Ip_ConvertLogicChToHwChも呼びますが、その場合 LogicCh 0で、あなたのスクリーンショットと一致しているように思えます。 あなたのプロジェクトでテストを実行しました。 Adc_Ipw_SetupTcdSingleAdcChannelMajorLink 間接的に呼び出す Dma_Ip_ConvertLogicChToHwCh で、私は次のことを確認しました。 &Dma_Ip_pxInit->ppxLogicChannelConfigArray[LogicCh] は 0x429F28に一致します &Dma_Ip_pxInit->ppxLogicChannelConfigArray[255] 。 その後、アドレスの値を変更しました。 0x429F28 に 0x1FFFFFF0にアクセスし、348 行目のコードを実行しました。 ハードフォールトが発生し、 BFAR 価値は 0x1FFFFFF6 、予想通りです。 これにより、アウトオブバウンズアクセスが実際に存在することが確認されています。ハードフォルトが発生するかどうかは、 Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]の値に依存します。 Re: S32K3 ADC Optimize DMA Streaming こんにちは、@ Jason22 これはおかしい。何度も試してみたのに。私が提供したELFファイルは直接デバッグできます。 Re: S32K3 ADC Optimize DMA Streaming こんにちは@Senlent 私の操作が正しかったかどうか確信が持てません。あなたのELFファイルを使ってデバッグを試みましたが、うまくいきませんでした。 私の動画で示した手順を同じように行ってもらえますか?この問題の再現が可能だと思います。 手順は以下の通りです。 行にブレークポイントを設定します Mcl_Init(NULL_PTR); 。 ブレークポイントに到達するまでプログラムを実行します。 Mcl_Init(NULL_PTR); 。 すべてのブレークポイントを無効にする（ 「すべてのブレークポイントをスキップ」ボタンをクリック）。 跨いで Mcl_Init(NULL_PTR);( 「すべてステップ」ボタンをクリックします) ブレークポイントを再度有効にし（ 「すべてのブレークポイントをスキップ」ボタンをクリック）、そして「再開」ボタンをクリックします。 あなたはそれを見ます Dma_Ip_ConvertLogicChToHwCh 再び入力され、 ロジックCh 255です。 BR、 ジェイソン 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ドライバーの設計者は私ではないので、ユーザーが問題に直面しない限り、なぜこう設計したのかは詳しくは触れません。 このフィードバックプロセスは長くなるかもしれませんが、その成果を関連するデザインチームに伝えます。

使用 KITFS24SKTFDMEVM 和 NXP GUI 无法与 FS2400 通信 主题：使用 KITFS24SKTFDMEVM 和 NXP GUI 无法与 FS2400 通信 您好， 我正在尝试使用KITFS24SKTFDMEVM评估板在FS2400上配置和编程 OTP。 评估板： https://www.nxp.com/design/design-center/development-boards-and-designs/KITFS24SKTFDMEVM 但是，当我将电路板连接到NXP GUI时，我无法与该设备建立通信。图形用户界面报告如下错误，并且无法进行通信。 我之前在FS26评估板上使用过相同的 NXP GUI，没有任何问题，所以我相信我的 PC 设置和 GUI 安装都是正确的。 评估板处于默认配置状态，我没有故意更改任何跳线或开关设置。为验证这一点，当前配置如下： S12（OTP）：关闭 J30：引脚 1-2 连接 SW4（WAKE2）：开启 S19（WAKE3）：开启 J33：开放 J37：引脚 2-3 连接 J36：引脚 2-3 连接 J10：引脚 2-3 连接 SW9：所有开关打开 J45：引脚 2-3 已连接 J26：引脚 5-6 和 9-10 连接 SW20：所有开关关闭 S2：开启（我在电路图中找不到这个开关） SW18：所有开关打开 SW1（主电源开关）：位置 3（2-3） 我没有对评估板上的 S32K144 MCU 进行编程。据我了解，电路板出厂时已经预装了所需的固件。请问有人能确认一下这个说法是否正确吗？或者说，在 GUI 能够与 FS2400 通信之前，是否需要先对 MCU 进行刷写？ 以下是图形用户界面显示的错误信息： 若能得到任何帮助，我将不胜感激。 谢谢！ FS85&FS84 FSBC+PMIC Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI 你好， 感谢您与我们联系。 请按照 UM12015 KITFS24SKTFDMEVM 用户手册第 5 节“安装和配置软件和工具”中的说明更新固件。此方法应该可以解决您遇到的错误。 如果更新完成后问题仍然存在，请您提供一张硬件配置的图片？这将有助于我们检查配置并进一步调查问题。 谢谢您！ Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI 嗨@ErikaC 如果fs23xx-fw-FS24-v0.86.hex是正确的固件文件，那么直接加载/刷写此 .hex 文件是否需要任何特定步骤？文件是保存到 KITFS24SKTFDMEVM 目录，还是需要使用特定的工具/设置？ 如果可以的话，非常感谢您能提供KITFS2400FRDMEVM_HW_Test_Package_W20.zip软件包或其下载位置，因为这将使按照手册中描述的固件更新程序进行操作变得更加容易。 感谢您的帮助。 加内什·巴格瓦特 Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI 你好， 我找不到 KITFS2400FRDMEVM_HW_Test_Package_W20.zip 文件夹。它很可能包含在早期版本的 NXPGUI 中。但是，该软件包仅包含 fs23xx-fw-FS24-v0.86.hex 文件，这是对固件进行编程所需的唯一文件。 请按照UM12014 KITFS2400FRDMEVM 用户手册中描述的所有步骤进行操作。如图 17 所示，需要使用调试器，并且还必须安装 S32 设计工作室工具。 如果没有用户手册中描述的必要调试器连接和软件环境，固件更新过程将无法成功完成。 希望这能帮到你！ Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI 嗨@ErikaC ， 感谢您的反馈， 我查阅了 UM12015 KITFS24SKTFDMEVM 用户手册的第 5 节“安装和配置软件和工具” 。但是，我找不到文档中提到的KITFS2400FRDMEVM_HW_Test_Package_W20.zip文件。 请问您能否告知我在哪里可以下载这个 .zip 文件？文件？我需要它按照手册中的说明更新固件。 我在 NXP GUI 中找到了fs23xx-fw-FS24-v0.86.hex 。这是应该用于更新的固件文件，还是包含在 KITFS2400FRDMEVM_HW_Test_Package_W20.zip 中的另一个文件？ 我还查看了手册中提供的链接： 我从https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=S32DS-IDE-ARM-V2-X下载并安装了可执行文件（这是设计工作室，但不是主 S31244_Flash 文件），但我找不到所需的 .zip 文件。代码包，软件包. 请问能否提供KITFS2400FRDMEVM_HW_Test_Package_W20.zip的下载位置，或者告诉我哪里可以找到执行更新所需的正确固件包？ 感谢您的帮助。 加内什·巴格瓦特 Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI 嗨@ErikaC ， 谢谢。成功了，我现在可以与 NXP-GUI 通信了。 唯一的问题是，这两个设置默认情况下并不存在。正如你所说，添加它们之后，一切都正常了。 在“可执行文件”下添加的命令是： ${cross_prefix}gdb${cross_suffix} 再次感谢您的支持。 问候， 加内什·巴格瓦特

LX2162A USXGMIIリンクが完了しない みなさん、こんにちは。 私はSolidrun社製のLX2162A SoMを所有しています。Clearfogの開発キットを使用していますが、近いうちにカスタムキャリアに移行する予定です。 Solidrunは基本的なRCW/DCP/DPLを提供しており、その機能は確認済みです。私の場合、DPC3の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 のパッチが適用されています。U-Bootやその他のものもパッチが適用されています。すべてのパッチはここから取得されます： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 私はMaxLinear GPY245-EKV-1（および-2）開発キットを持っており、PHYをデバイスに接続するために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/Replicator）が報告されています。コントロールレジスタが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ノードです。PHYへの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リファレンスマニュアルでは4つの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セレクトビットがクリアされているかどうかです。 この正確な故障クラスは、LinuxのPCS**ドライバ**ではなくMCファームウェアに起きている前例もあります。あるLX2162Aチケットでは、USXGMII構成でMCが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プロトコル制御レジスタにはMDIOアクセスをマッチングするためのMDEV_PORTフィールドがあり、マニュアルにはMDIOがSGMII/PCSターゲットにアクセスするまで、ソフトウェアは変更後少なくとも3プラットフォームクロックを待つ必要があると記載されています。もしMDIOアドレスデコードが間違っていると、書き込みが「永続しない」ように見えることがあります。これは異なる、またはリセット/デフォルトのPCSウィンドウを読み取っているからです。 USXGMII ANレジスタが意味を持つのは、モード選択が正しく行われた後のみであることを確認してください。 USXGMII PCS CONTROLレジスタのビット12にはAUTO_NEGOTIATION_ENABLEがあり、DEV_ABILITY / PARTNER_ABILITYはRWレジスタです。DEV_ABILITY下位ベンダーの任意の速度フィールドはゼロでなければならず、ゼロは自動交渉失敗を引き起こす可能性があります。しかし、PCCCが依然としてXFIを選択する場合、これらのBMCR/能力書き込みは本当の根本的な問題ではない。 GPY245ボードのドキュメントに明確に記載されていない限り、QXGMIIを別の必須外部プロトコルとして扱わないでください。 LX2162Aドキュメントには、PD_QXGMやRST_QXGMなどのリセット/電源停止制御ビットを含むQXGMIIプロトコルコンバータレジスタが含まれています。NXPコミュニティの資料LS1028Aでは10G_QXGMII Lynx SerDesドライバーパスも言及されています。しかし、選んでいるDPMACインターフェースLX2162Aドキュメントは依然としてUSXGMII / XFIであり、NXPのドキュメントにはLX2160クラスのデバイスがUSXGMIIをサポートし、「SXGMII」は同じ意味ではないと別途記載されています。言い換えれば、「QXGMII」という言及は、ドライバ/コミュニティの議論において、あなたが設定したUSXGMIIモードとは必ずしも異なるMAC-to-PHY契約ではなく、内部のコンバータ/ドライバの命名パスを指している可能性があります。 このClearfog SFPテストでは、DPCはシンプルなものにしてください。 MAC_LINK_TYPE_PHY enet_if = 「USXGMII」のモデルは、MDIO上で管理される外部PHYのより自然なモデルです。バックプレーン/KRスタイルのフローを意図的に使用していない限り、MAC_LINK_TYPE_BACKPLANE が PHY 側の USXGMII 設定を修正するとは期待できません。 プロトコル3が「主にXFI専用」であるとは結論付けません。リファレンス・マニュアルでは、プロトコル3をDPMAC3のSerDes1レーン用にUSXGMII / XFIとして記載しています。取得した資料から確認できないのは、「プロトコル3 + DPMAC3 + USXGMIIはGPY245で検証された」という別の検証文です。より強力な証拠に基づく主張は、ハードウェアモードは存在し、PCCCがUSXGMIIを選択しない限りデフォルトでXFIに移行すること、そして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）を観察すべきでしょうか？他に提供できる情報はありますか? ありがとう！

[LPC55S69] Zephyr MCUboot 通过 UART 进行设备固件更新时，在 LPC55S69 上使用 MCUmgr 时无法正常工作 您好，我正在尝试让 Zephyr 的 MCUboot 在 LPC55XpressoS69 上使用 0 号核心运行。我正在 Zephyr 中运行简单的 Blinky 示例应用程序。 应用程序运行正常，没有任何错误。 但是，我一直尝试使用 mcumgr 通过 UART 发送设备固件更新 (DFU)，但由于某种原因，我甚至无法在 mcumgr 和我的设备之间建立连接。我一直收到“NMP超时”的错误提示。 为了方便理解，我的目录结构如下所示： | __boards |__ lpcxpresso55s69_lpc55s69_cpu0.overlay __ src                |__ main.c __sysbuild               |__mcuboot.conf                __mcuboot.overlay __prj.conf __sysbuild.conf 我的prj.conf文件内容如下：   # Enable MCUMGR subsystem and OS/Image management commands CONFIG_MCUMGR=y CONFIG_MCUMGR_GRP_OS=y CONFIG_MCUMGR_GRP_IMG=y # DIRECT SMP over UART CONFIG_MCUMGR_TRANSPORT_UART=y CONFIG_MCUMGR_TRANSPORT_SHELL=n # Dedicate flexcomm0 to SMP — nothing else on the UART CONFIG_CONSOLE=n CONFIG_UART_CONSOLE=n CONFIG_LOG=n CONFIG_SERIAL=y CONFIG_UART_INTERRUPT_DRIVEN=y # Required for SMP UART processing thread CONFIG_NET_BUF=y CONFIG_ZCBOR=y CONFIG_BASE64=y # Required subsystems for DFU CONFIG_FLASH=y CONFIG_IMG_MANAGER=y CONFIG_MCUBOOT_IMG_MANAGER=y # Dependencies for System/Reboot management via DFU CONFIG_REBOOT=y 我的sysbuild.conf文件内容如下：   SB_CONFIG_BOOTLOADER_MCUBOOT=y SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y 我的mcuboot.conf文件内容如下：   CONFIG_LOG=y CONFIG_MCUBOOT_LOG_LEVEL_INF=y CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_UART=y CONFIG_UART_CONSOLE=n   我的 MCUboot.overlay 文件看起来像这样 /* Step 3.4 - Configure button and LED for Serial Recovery */ // zephyr,console = &flexcomm0; // zephyr,uart-mcumgr = &flexcomm0; / { chosen { zephyr,code-partition = &boot_partition; zephyr,uart-mcumgr = &flexcomm0; zephyr,shell-uart = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; / { aliases { mcuboot-button0 = &user_button_3; mcuboot-led0 = &blue_led; }; }; &gpio0 { status = "okay"; }; &gpio1 { status = "okay"; }; &blue_led { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 最后，我的 lpcxpresso55s69_lpc55s69_cpu0.overlay 文件看起来像这样 / { chosen { zephyr,code-partition = &slot0_partition; zephyr,mgmt-smp = &flexcomm0; zephyr,uart-mcumgr = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 当我运行以下 MCUmgr 命令时，会收到 NMP 超时错误，如下所示： > mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout 所以 mcumgr 肯定知道端口可用（否则它会拒绝访问），但它一直超时。 我非常确定这是配置选项错误。我多次尝试更改配置选项，但似乎都无法解决问题。我几乎可以肯定，我漏掉了一些对这个功能正常运行至关重要的配置选项。 我已经尽可能地查阅了所有相关的应用笔记和用户手册。这些方法似乎都无法帮助我解决我的具体问题：在运行 Zephyr 应用程序的 LPC55Sxx 芯片上使用 Zephyr MCUboot 进行 DFU。 任何帮助都将不胜感激，不过最好是有人能在自己的板子上测试一下，例如：LPCXpresso55S69 并确认它们可以使用任何简单的程序执行 UART DFU。 LPC55S6x LPC55S69-EVK LPC55xx Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S 嗨@Harry_Zhang ， 你的方法确实有效。事实上，我能够将命令简化到仅仅只保留一个部分。 west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" 这个方法也奏效了。非常感谢您重现我的问题，感激不尽。 Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S 你好@ZQ2 我能够在 LPCXpresso55S69 板上重现并验证该设置。 1.关键在于，在此配置中，MCUmgr 必须与 MCUboot 一起使用。该应用程序链接到 slot0（而不是闪存基地址），因此单独构建和烧录 smp_svr 应用程序将无法正常工作。MCUboot 是启动应用程序并将控制权移交给应用程序所必需的。 2. 我在文件 /c/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards 中添加了覆盖文件 lpcxpresso55s69_lpc55s69_cpu0.overlay。 &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 3. 使用以下命令构建项目： west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" -DEXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" -Dmcuboot_EXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" 4. 建成之后。您可以使用命令 grep -A20 -B5 "boot_partition" build/mcuboot/zephyr/zephyr.dts 5. 和西闪光 6. 7. 这证实了 UART 传输、SMP 服务器、MCUmgr 和 MCUboot 集成均正常工作。 BR 哈里 Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S 嗨@Harry_Zhang ， 巧合的是，就在我昨天发布这个问题之后，我正好在使用 Zephyr 的smp_svr示例。 我遇到的问题也完全一样。 我按照 Zephyr 文档中的示例进行了操作，链接如下。 我创建了一个示例项目，然后成功构建了代码，并按照文档说明，使用以下命令启用了Raw UART（串行） smp_svr 选项的配置： west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild -- -DEXTRA_CONF_FILE="raw-serial.conf;fs.conf" 然后我成功地刷入了代码。 尽管如此： C:\Users\Dev>mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout 我甚至尝试将调试探针从 Link2 改为 JLink，之后调试探针就连接到了 COM16。为了以防万一，我还使用 JLink Commander 禁用了所有大容量存储设备功能。 然后我尝试刷机并运行： > west flash -r jlink 但再次出现这种情况： C:\Users\Dev> mcumgr --conntype serial --connstring "dev=COM16,baud=115200" echo "test" 错误：NMP 超时 我究竟漏掉了什么？我猜这跟配置有关？如果是这样，我很好奇为什么 Zephyr 官方提供的smp_svr示例与 LPC55S69 不兼容，需要进行修改。 Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S 你好@ZQ2 由于 mcumgr echo 已经返回 NMP 超时，我认为您可以在调试 MCUboot DFU 流程之前验证 MCUmgr UART 通信。 您可以确认以下内容： flexcomm0 是连接到 LPCXpresso55S69 板上 COM11 的 UART。 应用程序运行正常（未停留在MCUboot串行恢复模式）。 没有控制台、shell 或日志输出与 MCUmgr 共享同一个 UART。 为了快速验证，我建议从 Zephyr 的smp_svr示例开始。 首先验证以下命令是否有效： mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" BR 哈里

[LPC55S69]Zephyr MCUboot for Device Firmware Update over UART が MCUmgr で動作しないLPC55S69 こんにちは、Core 0を使ってLPC55XpressoS69でZephyrのMCUbootを動かそうとしています。私はZephyrでシンプルなBlinkyサンプルアプリケーションを使っています。 エラーもなくアプリケーションは問題なく動いています。 しかし、mcumgrを使ってUART経由でデバイスファームウェアアップデート(DFU)を送信しようとしているのですが、なぜかmcumgrとデバイス間の接続すら確立できません。「NMPタイムアウト」が繰り返し発生します。 参考までに、私のディレクトリ構造は以下のようになっています。 | __ボード |__ lpcxpresso55s69_lpc55s69_cpu0.overlay __ src                |__ main.c __sysbuild               |__mcuboot.conf                __mcuboot.overlay __prj.conf __sysbuild.conf 私のprj.confファイルは以下のようになっています。   # Enable MCUMGR subsystem and OS/Image management commands CONFIG_MCUMGR=y CONFIG_MCUMGR_GRP_OS=y CONFIG_MCUMGR_GRP_IMG=y # DIRECT SMP over UART CONFIG_MCUMGR_TRANSPORT_UART=y CONFIG_MCUMGR_TRANSPORT_SHELL=n # Dedicate flexcomm0 to SMP — nothing else on the UART CONFIG_CONSOLE=n CONFIG_UART_CONSOLE=n CONFIG_LOG=n CONFIG_SERIAL=y CONFIG_UART_INTERRUPT_DRIVEN=y # Required for SMP UART processing thread CONFIG_NET_BUF=y CONFIG_ZCBOR=y CONFIG_BASE64=y # Required subsystems for DFU CONFIG_FLASH=y CONFIG_IMG_MANAGER=y CONFIG_MCUBOOT_IMG_MANAGER=y # Dependencies for System/Reboot management via DFU CONFIG_REBOOT=y 私のsysbuild.confは以下のとおりです。   SB_CONFIG_BOOTLOADER_MCUBOOT=y SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y 私のmcuboot.confは次のようになっています。   CONFIG_LOG=y CONFIG_MCUBOOT_LOG_LEVEL_INF=y CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_UART=y CONFIG_UART_CONSOLE=n   私のmcuboot.overlayは次のようになっています。 /* Step 3.4 - Configure button and LED for Serial Recovery */ // zephyr,console = &flexcomm0; // zephyr,uart-mcumgr = &flexcomm0; / { chosen { zephyr,code-partition = &boot_partition; zephyr,uart-mcumgr = &flexcomm0; zephyr,shell-uart = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; / { aliases { mcuboot-button0 = &user_button_3; mcuboot-led0 = &blue_led; }; }; &gpio0 { status = "okay"; }; &gpio1 { status = "okay"; }; &blue_led { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; そして最後に、私のlpCXpresso55s69_lpc55s69_cpu0.overlayは次のようになります。 / { chosen { zephyr,code-partition = &slot0_partition; zephyr,mgmt-smp = &flexcomm0; zephyr,uart-mcumgr = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 以下の MCUmgr コマンドを実行すると、以下に示すように NMP タイムアウトが発生します。 > mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout つまり、mcumgrはポートが利用可能であることを確実に認識しています(そうでなければアクセスを拒否します)が、タイムアウトが続いています。 これは設定オプションのエラーだと思います。設定オプションを何度も変更してみましたが、どれもうまくいきません。おそらく、この機能を動作させるために不可欠な設定オプションがどこかに抜けているのだと思います。 できるだけ多くのアプリケーションノートやユーザーマニュアルを調べました。私のケースにはどれも役に立たないようです。例えば、Zephyrアプリケーションを動かすLPC55Sxxチップ上のDFU MCUbootを使う場合です。 どんな助けでもありがたいですが、誰かが自分のボードで試すのが一番良いかもしれません。LPCXpresso55S69を送り、どんな簡単なプログラムでもUART DFUを実行できるか確認してください。 LPC55S6x LPC55S69-EVK LPC55xx Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S こんにちは、 @ZQ2さん LPCXpresso55S69ボード上で、この設定を再現し、検証することができました。 1.重要な点は、この構成ではMCUmgrをMCUbootと併用する必要があるということです。アプリケーションはslot0にリンクされている(フラッシュベースアドレスではありません)ため、smp_svrアプリケーションを単独でビルディングしてフラッシュするだけでは正しく動作しません。起動と制御をアプリケーションに引き渡すにはMCUbootが必要です。 2. /c/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boardsのオーバーレイファイルlpcxpresso55s69_lpc55s69_cpu0.overlayを追加します。 &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 3. 以下のコマンドを使用してプロジェクトをビルドしました。 west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" -DEXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" -Dmcuboot_EXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" 4. それを建てた後。コマンドを使うことができます grep -A20 -B5 "boot_partition" build/mcuboot/zephyr/zephyr.dts 5. そして西の閃光 6. 7. これは、UARTトランスポート、SMPサーバー、MCUmgr、およびMCUbootの統合がすべて正しく動作していることを確認するものです。 BR ハリー Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S こんにちは、 @Harry_Zhang さん。 あなたの解決策は確かに効果があります。実際、私はコマンドを単に west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" これも効果があった。私の問題を再現していただき、本当にありがとうございます。大変感謝しています。 Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S こんにちは、 @ZQ2さん mcumgr echoはすでにNMPタイムアウトを返しているので、MCUbootのDFUフローをデバッグする前にMCUmgr UART通信を検証できると思います。 以下のことを確認できます: flexcomm0はLPCXpresso55S69ボード上のCOM11に接続されたUARTです。 アプリケーションは通常通り動作しており(MCUbootのシリアルリカバリーモードにとどまっていません)。 コンソール、シェル、ログ出力のいずれも、MCUmgrが使用するUARTを共有していません。 簡単な検証として、Zephyrの smp_svr サンプルから始めることをお勧めします まず、以下のコマンドが正しく動作することを確認してください。 mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" BR ハリー Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S こんにちは、 @Harry_Zhang さん。 偶然にも、昨日この質問を投稿した直後にZephyrのsmp_svr サンプルを使っていました。 私も全く同じ問題に直面しています。 以下の リンクにあるZephyrのサンプルドキュメントに従って確認しました。 サンプル用のプロジェクトを作成し、ドキュメントに記載されている以下のコマンドを使用して、 Raw UART (serial) smp_svr オプションの設定を有効にして、コードを正常にビルドしました。 west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild -- -DEXTRA_CONF_FILE="raw-serial.conf;fs.conf" そして、コードの書き込みに成功しました。 それにもかかわらず： C:\Users\Dev>mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout デバッガープローブをLink2からJLinkに変更してみたところ、デバッグプローブがCOM16に接続されるようになりました。念のため、JLinkコマンドーを使ってマスストレージデバイスの機能も無効にしました。 次に、フラッシュして実行してみました。 > west flash -r jlink しかし、またしても： C:\Users\Dev> mcumgr --conntype serial --connstring "dev=COM16,baud=115200" echo "test" エラー:NMPタイムアウト 一体何を見落としているのでしょうか?設定に関係があるのでしょうか？もしそうなら、なぜZephyrの公式サンプルがLPC55S69 smp_svrと互換性がなく、改造が必要なのか疑問です。

请问有人可以帮我找到S32K3的功能安全手册吗？ 大家好，我正在寻找NXP S32K3 MCU系列的**功能安全**手册。请问有人能帮我找到它或者提供访问方式吗？ Re: Could someone please help me find the Safety Manual for the S32K3? HI 你已经和恩智浦签署保密协议了吗？如果您不确定公司是否与恩智浦半导体签署了保密协议，请告诉我公司的全名或地址。 如果您已经持有有效的保密协议，请参考此文档注册安全文件帐户。 获得安全文件访问权限后，您可以点击 S32K3 产品页面 文档部分的“安全”按钮 ，下载 功能安全手册 。 此致敬礼， Robin

どなたかS32K3のセーフティマニュアルを探すのを手伝ってもらえますか? 皆さんこんにちは、NXP S32K3 MCUファミリのセーフティマニュアルを探しています。どなたか見つける手助けやアクセス方法の情報を教えていただけませんか? Re: Could someone please help me find the Safety Manual for the S32K3? ハイ NXP社とは既に秘密保持契約（NDA）を締結済みですか？もし会社がNXPとNDAを結んでいるか確信が持てない場合は、会社のフルネームか住所を教えてください。 既に有効な秘密保持契約（NDA）をお持ちの場合は、この文書を参照してセキュアファイルアカウントを登録してください。 Secure Fileへのアクセスができたら、 S32K3製品ページの ドキュメントセクションで 「Secure 」をクリックして セーフティマニュアル をダウンロードできます。 よろしくお願いいたします ロビン

Kinetis 和 LPC 的调试接口有什么建议？ 我目前主要从事 Kinetis 系列芯片的开发工作，未来可能还会开发一些 LPC 芯片。我抽屉里装满了 P&E Micro 的调试接口，其中最常用的是 Cyclone ACP。 我有时会发现自己从 600 美元的 Cyclone 换成了 20 美元的 LPC-Link2，因为 Cyclone 与 MCUXpresso 存在很多奇怪的问题。说实话，LPC-Link2 基本能满足我的需求，只是速度有点慢。 我应该考虑使用Segger接口吗？请问有人可以推荐一款可靠、速度适中、在 MCUXpresso（最好也能在 CodeWarrior 11）中支持良好的接口吗？这款接口不会经常导致程序崩溃，也不会无法停止正在运行的目标。如果能支持追踪功能就更好了。 谢谢您！ Re: Debug interface recommendations for Kinetis and LPC? 嗨@richard37 感谢您的帖子！ 您不妨考虑一下 SEGGER J-Link。它与 MCUXpresso 一起使用时支持 Kinetis 和 LPC 设备，并且 CodeWarrior 11 也原生支持它。 如果您需要一种可以在开发环境和设备系列中使用的调试探针，那么它是一个很好的选择。

KinetisとLPC用のデバッグインターフェースのおすすめはありますか? 私は主にKinetisシリーズで開発をしており、近い将来LPCのパーツもいくつか手がけるかもしれません。P&E Microのデバッグインターフェースが引き出しいっぱいにあり、よく使っているCyclone ACPも含まれています。 時々、600ドルのCycloneから20ドルのLPC-Link2に切り替えることがあります。なぜなら、CycloneはMCUXpressoに多くの奇妙な問題があるからです。正直なところ、LPC-Link2は私の必要な機能のほとんどを満たしてくれるのですが、少し動作が遅いのが難点です。 Seggerインターフェースを検討しるべきでしょうか?MCUXpresso(そしてできればCodeWarrior 11でも)で十分にサポートされ、クラッシュや走行中のターゲットを止められない信頼性が高く、そこそこ高速なインターフェースを誰かおすすめできませんか?トレースサポートがあれば助かります。 よろしくお願いします！ Re: Debug interface recommendations for Kinetis and LPC? こんにちは、@richard37さん 投稿ありがとうございます！ SEGGER J-Linkを検討してみるのも良いかもしれません。MCUXpressoと組み合わせて使用した場合、KinetisとLPCの両方に対応しており、CodeWarrior 11でもネイティブサポートされています。 これにより、開発環境やデバイスファミリーの両方で使えるデバッグプローブが必要な場合に良い代替手段となります。

MCUXpresso SDK 最新版本 - 推荐的闪存数据存储方案 大家好，   我正在评估最新版本的 MCUXpresso SDK，并使用 NXP MCU。       对于将小型配置参数（设备设置、校准值、计数器等）保存到内部闪存中，目前推荐的方法是什么？     具体来说：   1. 使用专用闪存存储区还是 EEPROM 仿真（在支持的情况下）更好？   2. 频繁执行闪存写入操作时，是否存在性能或可靠性方面的考虑因素？ 3. NXP 是否有任何示例项目来展示参数存储和损耗均衡的最佳实践？ 4. 是否有推荐的用于管理持久配置数据的 SDK 库？ 我已经查阅了现有的 SDK 文档，但我希望能够获得关于新项目推荐实施方法的指导。   Re: MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage 你好@Manjuanth ， 我看到您已将此帖子发布在 S32K 的产品论坛上，但是 S32K 的 MCU 与 MCUXpresso 不兼容，请改用S32 Design Studio 。请问您使用的是哪款恩智浦MCU？ 此致， 朱利安

MCUXpresso SDK 最新バージョン - フラッシュデータストレージの推奨アプローチ チームの皆さん、こんにちは。   私は最新バージョンのMCUXpresso SDKを評価しており、NXP MCUを使って作業しています。       小さな設定パラメータ(デバイス設定、キャリブレーション値、カウンターなど)を内部フラッシュメモリに保存する場合、現在推奨されている方法は何でしょうか?     具体的には：   1. 専用のフラッシュストレージ領域を使用するのと、EEPROMエミュレーション（サポートされている場合）を使用するのとでは、どちらが良いでしょうか？   2. フラッシュメモリへの書き込み操作を頻繁に行う場合、パフォーマンスや信頼性に関して考慮すべき点はありますか？ 3. NXPは、パラメータの保存とウェアレベリングに関するベストプラクティスを示すサンプルプロジェクトを提供していますか？ 4. 永続的な設定データを管理するために推奨されるSDKライブラリはありますか? 利用可能なSDKドキュメントは確認しましたが、新規プロジェクトでの推奨実装アプローチについての指針をいただけるとありがたいです。   Re: MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage こんにちは、 @Manjuanth さん。 S32Kの製品フォーラムに投稿されているのを見ましたが、S32KのMCUはMCUXpressoと互換性がなく、代わりに S32 Design Studioを使っています。どのNXPのMCUを使っているか教えてもらえますか? よろしくお願いします、 ジュリアン

MRF300AN 27MHz 参考设计 TVS 和电源时序 您好，NXP团队，关于MRF300AN-27MHz参考设计有两个问题：问题1：我可以在漏极和地之间连接一个110V TVS进行保护吗？Vds 为 133V。这是个好选择吗？Q2：正确的开机顺序是什么？栅极偏置先于漏极，还是漏极偏置先于栅极？另外，射频驱动应该缓慢增加功率还是可以直接施加全功率？谢谢。 Re: MRF300AN 27MHz Ref DesignTVS and Power Sequence 你好， 一般而言，TVS 反向截止电压应选择高于最大正常工作漏极电压，以防止正常工作期间发生意外导通，同时还能提供对异常瞬态事件的保护。 关于上电顺序，漏极电源可以在栅极偏置之前施加，反之亦然。在稳定且经过适当调整的电路中，这两种方法都是可以接受的。 此外，建议逐步增加射频驱动功率，而不是突然施加全功率驱动，因为这有助于确保更平稳的启动，并减少设备在运行条件下的压力。 希望这能帮到你！

MRF300AN 27MHzリファレンス設計TVSとパワーシーケンス こんにちは、NXPチームの皆さん。MRF300AN-27MHzのリファレンスデザインについて2つ質問があります。Q1:110V TVSをドレインからアースにかけて保護してもいいですか?Vdsは133Vです。これは良い選択でしょうか？Q2: 正確な電源オンシーケンスは何ですか?ゲートバイアスをドレインの前に置くべきか、ドレインバイアスをゲートの前に置くべきか？また、RFドライブはゆっくりと増やすべきでしょうか、それともフルドライブを直接適用してもいいのでしょうか?ありがとう。 Re: MRF300AN 27MHz Ref DesignTVS and Power Sequence こんにちは、 一般的に、TVSの逆スタンドオフ電圧は通常動作中の最大動作ドレイン電圧より高い位置に選択し、正常運転中の意図しない導電を防ぎつつ、異常な過渡現象からの保護も提供します。 電源アップシーケンスに関しては、ドレイン電源をゲートバイアスの前に、またはその逆に適用することができます。どちらの方法も、安定していて適切に調整された回路であれば許容範囲内である。 さらに、RFドライブを急激にフルドライブするのではなく、徐々にパワーアップさせることが推奨されており、これにより起動がスムーズになり、動作時のデバイスへの負荷も軽減されます。 お役に立てば幸いです！

i.MX8MP: SAI3オーディオを有効にしてM7を実行すると、SErrorとページフォルトが発生します。 NXP公式チームの皆様、こんにちは。 i.MX 8M Plus プラットフォームを使用し、 Linux A53 と FreeRTOS M7 を実行する システムを開発しています 。M7 を実行中に SAI3 オーディオインターフェースをLinuxに割り当てようとしたところ、カーネルクラッシュ（SError/ページフォルト）が発生しました。 1. ソフトウェアのバージョンと環境： カーネルバージョン: Linux 5.10.72 U-Bootバージョン: U-Boot 2021.04 M7 SDK: i.MX8MP 用 MCUXpresso SDK (rpmsg_lite_str_echo_rtos) 公式記事を参照してください: NXPナレッジベース: remoteprocを使用してM7ファームウェアを実行中にSAI3をテストする 2. システム構成：   <1> M7ファームウェア（m7.bin）はシステムパーティションに保存され、...U-Bootステージは、bootaux 0x007e0000コマンドを使用して直接起動されます。 <2> Cortex-A53 Linux側では、SAI3 + I2C3 + SDMA3バスに搭載された物理サウンドカードチップ（SGTL5000）を使用します。 <3> Cortex-M7は、GPIO2_IO09ピンでデータを取得し、高周波サンプリング割り込みをトリガーし、RPMsg仮想シリアルポート（/dev/ttyRPMSG30）を介してコア間でA53 Linuxとやり取りする役割を担っています。 3．発生した問題： サウンドカードのリソースがA53に調整されていない場合、/dev/ttyRPMSG30デバイスの動作は正常です。 現在、A53サウンドカードが必要です。公式記事「<リモートプロシージャコールでM7ファームウェアを実行中にSAI3をテストする>」に従って、以下の調整を行いましたが、カーネルの起動時に問題が発生します。変更点は以下のとおりです。 <1> カーネルのDTS設定が復元され、サウンドカードの設定が添付ファイル に示すようにA53に変更されました。 <2> u-boot dts: A53 にサウンドカードのリソースを割り当てます。例: <3> ATF、 SAI3、sdma3、i2c3をA53に割り当て、 imx8mp_bl31_setup.cを修正します。例： <4>M7 SDK: 添付の および に示されているように、AUDIO の変更に関連する BOARD_BootClockRUN および BOARD_RdcInit 関数に関するコメント。 4. カーネルのdmesgクラッシュログ： 以下のログに示すように、カーネル起動中にシステムがフリーズします。 [ 2.992289] i2c i2c-1: IMX I2C adapter registered [ 2.997631] SError Interrupt on CPU2, code 0xbf000002 -- SError [ 2.997634] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997636] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997638] Workqueue: events deferred_probe_work_func [ 2.997642] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 2.997644] pc : i2c_imx_probe+0x31c/0x8fc [ 2.997645] lr : i2c_imx_probe+0x2b0/0x8fc [ 2.997647] sp : ffff8000126a3af0 [ 2.997648] x29: ffff8000126a3af0 x28: ffff80001135c3f0 [ 2.997654] x27: ffff0000c50aa880 x26: 0000000000000023 [ 2.997660] x25: ffff0000c50aaca0 x24: ffff0000c50aa8f0 [ 2.997666] x23: ffff800011d7c090 x22: ffff0000c4410e40 [ 2.997672] x21: ffff80001135c428 x20: ffff0000c041d800 [ 2.997677] x19: ffff0000c041d810 x18: 0000000000000020 [ 2.997683] x17: 0000000000000000 x16: 0000000000000000 [ 2.997689] x15: ffff0000c44112b8 x14: 0000000000000000 [ 2.997695] x13: ffff0000c4410e40 x12: ffff8000126a3a70 [ 2.997700] x11: aaaaaaaaaaaaaaab x10: 0000000000000060 [ 2.997706] x9 : ffff800011b993b4 x8 : ffff800011b99000 [ 2.997712] x7 : 00007dfed2122a00 x6 : 000000000007a120 [ 2.997718] x5 : 0000000000b71aff x4 : 0000000000000002 [ 2.997723] x3 : 0000000000000002 x2 : 0000000000000000 [ 2.997729] x1 : ffff0000ff86ea08 x0 : ffff800013c8000c [ 2.997736] Kernel panic - not syncing: Asynchronous SError Interrupt [ 2.997741] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997742] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997744] Workqueue: events deferred_probe_work_func [ 2.997747] Call trace: [ 2.997748] dump_backtrace+0x0/0x1a0 [ 2.997750] show_stack+0x18/0x70 [ 2.997751] dump_stack+0xd0/0x12c [ 2.997752] panic+0x16c/0x334 [ 2.997754] nmi_panic+0x8c/0x90 [ 2.997755] arm64_serror_panic+0x78/0x84 [ 2.997757] do_serror+0x64/0x6c [ 2.997758] el1_error+0x90/0x110 [ 2.997760] i2c_imx_probe+0x31c/0x8fc [ 2.997762] platform_drv_probe+0x54/0xb0 [ 2.997763] really_probe+0xec/0x4d0 [ 2.997765] driver_probe_device+0x58/0xc0 [ 2.997766] __device_attach_driver+0xa8/0x10c [ 2.997768] bus_for_each_drv+0x78/0xd0 [ 2.997769] __device_attach+0xd8/0x180 [ 2.997771] device_initial_probe+0x14/0x20 [ 2.997773] bus_probe_device+0x9c/0xa4 [ 2.997774] deferred_probe_work_func+0x80/0xc0 [ 2.997776] process_one_work+0x1cc/0x350 [ 2.997777] worker_thread+0x2bc/0x46c [ 2.997779] kthread+0x154/0x160 [ 2.997780] ret_from_fork+0x10/0x30 [ 2.998109] SMP: stopping secondary CPUs [ 2.998111] Kernel Offset: disabled [ 2.998113] CPU features: 0x0240002,2000200c [ 2.998114] Memory Limit: none 問題点をご確認いただき、解決に役立つ関連文書や修正点がないかご検討ください。ご提案やご回答をお待ちしております。よろしくお願いいたします。 回复： i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled 解決しました。M7側のオーディオ設定を完全に無効にする必要がありました。

i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled Hello NXP official team: We are developing a system using the i.MX 8M Plus platform, running Linux A53 and FreeRTOS M7 . While attempting to allocate the SAI3 audio interface to Linux while running M7, we encountered a kernel crash (SError/page fault). 1. Software version and environment: Kernel version: Linux 5.10.72 U-Boot version: U-Boot 2021.04 M7 SDK: MCUXpresso SDK for i.MX8MP (rpmsg_lite_str_echo_rtos) Refer to the official article: NXP Knowledge Base: Test SAI3 while running M7 firmware with remoteproc 2. System configuration:   <1> The M7 firmware (m7.bin) is stored in the system partition and...The U-Boot stage is started directly using the command bootaux 0x007e0000. <2> On the Cortex-A53 Linux side, we use a physical sound card chip (SGTL5000) mounted on the SAI3 + I2C3 + SDMA3 bus. <3> The Cortex-M7 is responsible for acquiring data on the GPIO2_IO09 pin and triggering a high-frequency sampling interrupt, and interacting with the A53 Linux across cores via the RPMsg virtual serial port (/dev/ttyRPMSG30). 3. Problems encountered: If the sound card resources are not adjusted to A53, the operation of the /dev/ttyRPMSG30 device is normal; Currently, an A53 sound card is required. Following the official post < Test SAI3 while running M7 firmware with remoteproc >, the following adjustments were made, but kernel booting will cause issues. The changes are as follows: <1> The kernel DTS configuration has been restored, and the sound card configuration has been changed to A53, as shown in the attached <2> u-boot dts: Allocates sound card resources to the A53, such as <3> ATF, assign SAI3, sdma3, and i2c3 to A53, modify imx8mp_bl31_setup.c, such as: <4> M7 SDK: Comments on the BOARD_BootClockRUN and BOARD_RdcInit functions related to AUDIO changes, as shown in the attached and . 4. Kernel dmesg crash log: The system freezes during boot into the kernel, as shown in the following log: [ 2.992289] i2c i2c-1: IMX I2C adapter registered [ 2.997631] SError Interrupt on CPU2, code 0xbf000002 -- SError [ 2.997634] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997636] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997638] Workqueue: events deferred_probe_work_func [ 2.997642] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 2.997644] pc : i2c_imx_probe+0x31c/0x8fc [ 2.997645] lr : i2c_imx_probe+0x2b0/0x8fc [ 2.997647] sp : ffff8000126a3af0 [ 2.997648] x29: ffff8000126a3af0 x28: ffff80001135c3f0 [ 2.997654] x27: ffff0000c50aa880 x26: 0000000000000023 [ 2.997660] x25: ffff0000c50aaca0 x24: ffff0000c50aa8f0 [ 2.997666] x23: ffff800011d7c090 x22: ffff0000c4410e40 [ 2.997672] x21: ffff80001135c428 x20: ffff0000c041d800 [ 2.997677] x19: ffff0000c041d810 x18: 0000000000000020 [ 2.997683] x17: 0000000000000000 x16: 0000000000000000 [ 2.997689] x15: ffff0000c44112b8 x14: 0000000000000000 [ 2.997695] x13: ffff0000c4410e40 x12: ffff8000126a3a70 [ 2.997700] x11: aaaaaaaaaaaaaaab x10: 0000000000000060 [ 2.997706] x9 : ffff800011b993b4 x8 : ffff800011b99000 [ 2.997712] x7 : 00007dfed2122a00 x6 : 000000000007a120 [ 2.997718] x5 : 0000000000b71aff x4 : 0000000000000002 [ 2.997723] x3 : 0000000000000002 x2 : 0000000000000000 [ 2.997729] x1 : ffff0000ff86ea08 x0 : ffff800013c8000c [ 2.997736] Kernel panic - not syncing: Asynchronous SError Interrupt [ 2.997741] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997742] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997744] Workqueue: events deferred_probe_work_func [ 2.997747] Call trace: [ 2.997748] dump_backtrace+0x0/0x1a0 [ 2.997750] show_stack+0x18/0x70 [ 2.997751] dump_stack+0xd0/0x12c [ 2.997752] panic+0x16c/0x334 [ 2.997754] nmi_panic+0x8c/0x90 [ 2.997755] arm64_serror_panic+0x78/0x84 [ 2.997757] do_serror+0x64/0x6c [ 2.997758] el1_error+0x90/0x110 [ 2.997760] i2c_imx_probe+0x31c/0x8fc [ 2.997762] platform_drv_probe+0x54/0xb0 [ 2.997763] really_probe+0xec/0x4d0 [ 2.997765] driver_probe_device+0x58/0xc0 [ 2.997766] __device_attach_driver+0xa8/0x10c [ 2.997768] bus_for_each_drv+0x78/0xd0 [ 2.997769] __device_attach+0xd8/0x180 [ 2.997771] device_initial_probe+0x14/0x20 [ 2.997773] bus_probe_device+0x9c/0xa4 [ 2.997774] deferred_probe_work_func+0x80/0xc0 [ 2.997776] process_one_work+0x1cc/0x350 [ 2.997777] worker_thread+0x2bc/0x46c [ 2.997779] kthread+0x154/0x160 [ 2.997780] ret_from_fork+0x10/0x30 [ 2.998109] SMP: stopping secondary CPUs [ 2.998111] Kernel Offset: disabled [ 2.998113] CPU features: 0x0240002,2000200c [ 2.998114] Memory Limit: none Please take a look at the problem and see if there are any relevant documents or modifications that can resolve it. Looking forward to your suggestions and replies! Thank you! 回复： i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled Resolved; the audio configuration on the M7 side needs to be completely disabled.

S32 IDE開発環境のRTDプラグインをインストールできません。 S32Z280プロセッサ用のソフトウェアを開発するには、S32 IDE開発環境にS32ZE RTDプラグインをインストールする必要があります。しかし、図1に示すように、この環境ではインストールが失敗します。NXPのWebサイトからダウンロードしようとしても、ライセンスが必要なためダウンロードできません。ライセンスの取得方法についてご教示ください。よろしくお願いいたします。 Re: S32 IDE开发环境RTD插件无法安装 どういたしまして。ご質問があればいつでもお気軽にご連絡ください！ Re: S32 IDE开发环境RTD插件无法安装 最初のリンクではアカウントログインが必要で、ログイン後もインストールパッケージのダウンロードパスが表示されませんでした。2番目のリンクからは「カーパッケージマネージャー」にアクセスしてインストールパッケージを正常にダウンロードできました。ありがとうございました。 Re: S32 IDE开发环境RTD插件无法安装 こんにちは、 Flynn_T 1. このリンクからダウンロードできますか？最新のRTDバージョンは2.0.1 QLP01のはずです。ご指摘のバージョン1.1.45はリストにありません。また、2.0.1 QLP01 RTDにはS32DS IDEバージョン3.6.1が必要です。 設計：製品情報：車載用ソフトウェア - S32Z/E - リアルタイムドライバ（RTD） 2. このリンクからダウンロードできるかどうか確認することもできます。 自動車パッケージマネージャー | NXPセミコンダクターズ BR ジョーイ Re: S32 IDE开发环境RTD插件无法安装 こんにちは、BRジョーイ S32 IDE バージョン 3.6.10 を使用しています。必要な RTD バージョンは 1.1.45 です。NXP の公式サイトで S32Z/E RTD プラグインのダウンロードリンクが見つかりませんでした。ダウンロードリンクを提供していただけますでしょうか。 宜しくお願いします Flynn_T Re: S32 IDE开发环境RTD插件无法安装 こんにちは、 Flynn_T 使用しているS32 IDEのバージョンは何ですか？使用しているRTDのバージョンは何ですか？ IDEにS32Z/E RTDプラグインをロードする場合、通常はライセンスは必要ありません。 BR ジョーイ