Differences between old and new hardware version numbers _0-1785831056367.png Why can the older version (332) on the left be used, while the newer version (B222) on the right cannot? What is the difference between 332 and B222? How can I make B222 work properly? Re: 新舊硬件版號差別 Hi Darren, I discussed this with our applications team. Based on the screenshots provided, it appears that the GUI may not have been updated or reworked to support the newer B222 version, which could explain why the older 332 version operates correctly while B222 does not. To investigate this further, our applications engineer would like to review the details together with your team. I have been informed that he will contact you directly to continue the analysis and discuss the differences between versions 332 and B222, as well as the steps required to enable normal operation with B222. BRs, Tomas

多台Ara240是否支持P2P通信？ 标题说明了一切。 能否通过合适的 PCIe 交换机连接多个 Ara240，并使用 P2P 通信来运行更大的模型？ Re: Will multiple Ara240's support P2P communication? db16122_0-1785805134624.png ARA24 的在线资源非常有限，但对 BAR2 的内容会有帮助。

XIP FLASHリマップを有効にした状態でイメージスワップ後にMCUBootイメージをデバッグ/フラッシュする 皆さん、 なぜ特定の状況でフラッシュドライバーが故障するのか、何か理由があるのか教えてほしいです。 私たちはカスタムボードをIMXRT1176に使っています。このMCUのボードはEmbedded Artistsのキャリアボードをベースにしています。私たちのプロジェクトでは、フラッシュメモリに0x30100000と0x30200000の2つのパーティションがあります。私たちはMCU-LinkとLinkserverを使ってバイナリをフラッシュしています。バイナリは-この場合確認された署名です。FLASHのリマップ機能を有効にしているので、スワップは行われません。 我々は2つの状況を観察する。 1.フラッシュメモリにブートローダーがあり、パーティション1にイメージファイルがあれば、すべて正常に動作します。 2. OTAアップグレードを完了し、MCUbootが2つ目のパーティションから新しいイメージを起動すると、linkserverからエラーが出るため、FLASHパート1への書き込みができません。 ================================================= NC:フラッシュドライバーの起動 MIMXRT1170_SFDP_QSPI.cfx(すでに常駐中) NC:フラッシュドライバーを実行するためにVECTRESETを送信中 Nc: フラッシュバリアント「iMXRT1170_SFDP_FlexSPI1_A_QSPI 2026年5月15日 18:32:39」検出(16MB = 256*64K 0x30000000) Pb: 1/1(0) 0x30100000でセクター16-31を1048576バイトで書き込み 追伸:(0) 30100000 で:0バイト - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) ステータス 0x1 - ドライバーがドライバーエラーを報告 - EXTSPIJドライバー rc 1 - 操作失敗 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) ステータス 0x1 - ドライバーがドライバーエラーを報告 - EXTSPIJドライバー rc 1 - 操作失敗 最初のパーティションは erase-range コマンドで消去済みであることに注意してください。また、私たちのファームウェアがフラッシュドライバーで処理すると期待通りに動作することも確認できます。リンクサーバーを手動で操作しようとした場合にのみ失敗します。 =================================================== Q1。何か明確な理由はありますか?パーティション2を消すべきなのか、それとも両方の区画を消すべきなのでしょうか? Q2。もしスロット1のためにバイナリをビルドした場合、パーティション2のイメージで動作するコアに接続したとき、このバイナリは動作しますか?Flashのリマップは動作しますか? ご協力ありがとうございます。 よろしくお願いします！ ヤクブ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled ギャビンさん、こんにちは。ご返信ありがとうございます！あなたはこれらの概念を理解する上で本当に役立ちました。 もし可能なら、もう一つだけ一緒に考えていただけませんか? これはOTAアップデート後に取得したパーティション情報です。 =========== 画像 0; 名前 APP; 状態 永続的: スロット 0 APP_PRIMARY; オフセット 0x100000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 1.1.1+0> 画像ペイロードのSHA256: C825709456C098E38090... log_addr 0x30100000 は 0x30200000 にリマップされます スロット 1 APP_SECONDARY; オフセット 0x200000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 2.1.1+0> 画像ペイロードのSHA256: EBFCCC0D3E970230E404... log_addr 0x30200000 は 0x30200000 に再マッピングされます *アクティブ* =============== 次に、このスクリプトを実行してスロット0をクリアします。 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 あなたの説明によると、リマップオーバーレイが有効になっているため、スロット1が消去されると予想していました。しかし、そうではありません。電源リセット後に得られた結果は以下のとおりです。 ========= フラッシュREMAP_OVERLAYが有効です。 画像 0; 名前 APP; 状態 なし: スロット 0 APP_PRIMARY; オフセット 0x100000; サイズ 0x100000 (1048576): 画像が見つかりませんでした スロット 1 APP_SECONDARY; オフセット 0x200000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 2.1.1+0> 画像ペイロードのSHA256:EBFCCC0D3E970230E404... log_addr 0x30200000 0x30200000への再マップ *アクティブ*========= まだslot0に何も書き込めないのは予想外です。eraseコマンドはremapコマンドの論理マッピングをバイパスするが、loadコマンドはバイパスしないということはあり得るのでしょうか？ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled こんにちは、 @jslota13245 さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！ ご提供いただいた情報に基づき、以下の理由を考慮すべきだと考えます。故障の原因は FlexSPIリマップは引き続き有効です OTAアップデート後。MCUbootがリマップでslot1(partition2)を起動すると、アプリケーションにremapを残します。LinkServerのフラッシュ  .cfx  ドライバはAHB論理アドレスを通じて処理されるため、リマップは書き込みTo  0x30100000  (partition1)を物理  0x30200000  (partition2)に静かにリダイレクトします。物理はすでに確認済み画像を保持しており、空白ではありません。NORフラッシュは上書きできません。 以前の  erase-range 0x30100000  実際、同じ理由でパーティション2も消去しました。独自のファームウェアは、プログラムによって動作します。 FlexSPI IPコマンドモードでは、明示的な物理オフセットを使用することで、リマップをバイパスします。注: VECTRESET / デバッガーアタッチ 再マッピングは明確ではない。PORまたは明示的なレジスタ書き込みのみがそれを可能にする。 Q1: どのパーティションを消去すべきですか? 重要なのは、パーティションを消去するだけでなく、まずリマップを無効にすることです。推奨： LinkServerでプログラミングを行う前に、リマップレジスタをクリアしてください。 次に、両方のパーティション（slot0とslot1）を消去します。direct-XIPは最高バージョンを選択するため、slot1に古くなった画像が残るとMCUbootが再度選び、再マッピングを有効化するため、問題が再発します。 Q2: Partition2イメージを実行するコアに接続した場合、slot1バイナリは動作しますか? 画像にはリンクが必要です プライマリスロット ( 0x30100000 ) 用に一度だけ実行します。同じバイナリはリマップによりどちらのスロットからでも実行されます。スロット1 用に別途ビルドする必要はありません。デバッグ用にアタッチすると、リマップは論理アドレスの整合性を保つため、コードの読み取りやブレークポイントは問題なく動作します。しかし、同じリマップはフラッシュを書く際に物理ターゲットを変えるため、LinkServerでslot0をプログラムする前にリマップを無効にする必要があります 。 よろしくお願いします、 ギャビン Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled @Gavin_Jia  親愛なるギャビンへ、 私のコメントをあなたの返信に見て、見落としていることがあれば教えていただけますか? ご協力ありがとうございました！ よろしくお願いします、 ヤクブ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled こんにちは、 @jslota13245 さん。 前回のメッセージを見落としてしまい、申し訳ありませんでした。 残念ながら、回答が受理されると自動的に問題は解決済みとみなされ、CASEの更新は受け取れなくなりました。この度の見落としにつきまして、心よりお詫び申し上げます。 こちら側でも同様の問題を再現してみます。調査に少々お時間をください。調査結果や進捗状況については随時ご報告いたします。 皆様のご理解とご協力に、心より感謝申し上げます。 よろしくお願いします、 ギャビン Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled こんにちは、 @jslota13245 さん。 あなたの調子が良いといいのですが！ さらに調査を続け、この投稿でいくつかの予備的な結論を提示します:https://www.cnblogs.com/henjay724/p/13538105.html 消去と書き込みは、リマップの影響を受けません。どちらも物理アドレスに対してFlexSPIのIPコマンドを通すため、消去範囲0x30100000物理スロット0は本当に消去されています。だからslot0は「画像なし」と表示され、slot1はそのまま残っているのです。先ほどの「消去処理がスロット1に当たる」という表現は正確ではありませんでした。申し訳ありません。書き込みが失敗する理由は、書き込み自体ではなく、読み出し検証にある。 最も簡単な解決策は、イメージをフラッシュする前にリマップ機能を無効にすることだと私は考えています。あるいは、フラッシュ書き込み後にIPコマンドを使用してメモリからデータを読み戻します。読み戻されたデータが書き込まれたデータと一致する場合、障害の原因はAHBチェックサムが不正に操作されたことだけであることが証明されます。 さらに、公式声明は以前の推測を支持しています:https://mcuxpresso.nxp.com/mcuxsdk/latest/html/examples/ota_examples/_doc/flash_remap_readme.html#mcuboot-and-flash-remapping-feature

RW612 FLEXCOMM3/I2S3 サポートドライバー 当社では、以下の固定ハードウェア配線でRW612 FLEXCOMM3/I2S3を使用しています。 - GPIO24 = PCM6120 SDOUTからのI2Sデータ入力 - GPIO25 = PCM6120 BCLKへのI2S SCK出力 - GPIO26 = PCM6120 FSYNCへのI2S WS出力 コーデックはスレーブモードのPCM6120です。 RW612は、BCLK/WSを生成し、オーディオデータを受信するI2Sマスターとして設計されています。 確認した内容: - GPIO25/GPIO26はプレーンGPIOモードで正しく駆動可能です - クロックFLEXCOMM3 12.288 MHzのオーディオ PLLです - PCM6120とのI2C通信が正常に動作している - PCM6120レジスタ構成が受け入れられます 観察された行動： 1. kI2S_MasterSlaveNormalMasterでI2S RXとして構成されたFLEXCOMM3は、GPIO25/GPIO26でSCK/WSエッジを生成しません。 2. kI2S_MasterSlaveNormalMaster で I2S TX として構成された FLEXCOMM3 も動作しません。FIFOSTAT.TXNOTFULL=1 ですが、FIFOWR への書き込み後も TXLVL は 0 のままで、ピンに SCK/WS エッジが表示されません。 3. PCM6120はクロックの欠落を報告します（ASI_STS=0xFF、DEV_STS1=0x80）。 質問: 1.RW612 FLEXCOMM I2S RXがノーマルマスターモードでSCK/WSを外部ピンに駆動することが期待されますか? 2. 「マスタークロック生成+外部コーデックからデータ受信」というユースケースで単一のFLEXCOMMインスタンスがサポートされているのか、それともデュアルFLEXCOMMアーキテクチャ(TXマスター+RxスレーブとI2Sブリッジ)が必要か? 3.FLEXCOMM3 I2S TXマスターの場合、I2S_TxInit()、FIFOWR書き込み、およびMAINENABLE以外に、FIFO書き込みを受け入れるための追加の前提条件はありますか？ 4. FLEXCOMM3のGPIO24/25/26（AONドメイン）におけるI2Sクロック出力に関して、既知の制限事項はありますか？ この話題について助けてください Re: RW612 FLEXCOMM3/I2S3 Supporting driver こんにちは、 @duyhung さん。お元気でお過ごしでしょうか。 テストを行うためにFreeRTOSを使っているのか、それともZephyrを使っているのか、教えていただけますか?FRDM-RW612ボードを使用していますか？ また、どのバージョン(SDKかZephyr)を使っているか、また開発の基準として例を取っているかも教えてください。 さらに、RW612(UM11865)のリファレンス・マニュアルには28.2節にI2Sペリフェラルの基本構成ガイドが含まれていますが、この一般的な手順を踏んだか確認していただけますか? Re: RW612 FLEXCOMM3/I2S3 Supporting driver こんにちは、 @RomanVR さん。 ご回答ありがとうございます。下記の説明をご覧ください。 1. RTOS 私たちは使用しています ベアメタルとFreeRTOSの両方でテストを実施しました。これらのテストにはZephyrは関与していません。すべての初期化およびI2S設定はNXP SDKsドライバで直接行います。 2. ボード 私たちは ない FRDM-RW612を使用します。私たちは カスタム開発ボード RW612ETA2Iをベースにしています。MCUは同じですが、ボードのレイアウトが異なります。 オーディオコーデック(PCM6120)は以下の固定ピンで FLEXCOMM3 / I2S3 に接続されています: 信号GPIO方向 I2Sデータ（PCM6120からのSD出力） GPIO24 入力 I2S SCK（BCLKからPCM6120へ） GPIO25 出力 I2S WS（FSYNCからPCM6120） GPIO26 出力 I2C SDA (PCM6120設定) GPIO56 (FC14) 双方向 I2C SCL（PCM6120設定） GPIO57 (FC14) 双方向 AUX_EN（PCM6120電源） GPIO54 出力 3. SDKバージョン 私たちは SDK_2.x_RD-RW612-BGA、バージョン25.03.00 を使用しています。 4. 基本例 私たちは rdrw612bga_i2s_dma_record_playback 参考例として。この例では FLEXCOMM1（TXマスター）+ FLEXCOMM0（RXスレーブ）+ I2Sブリッジ。動作確認済みです。 しかし、ハードウェアの制約により、 シングルFLEXCOMM（FC3のみ） PCM6120へのI2Sリンク全体について。PCM6120はスレーブモードで動作する必要があります。なぜなら、BCLKのソースとなる外部クロックがないからです。FC3を次のように構成しようと試みました kI2S_MasterSlaveNormalMaster データを受信しながらSCK/WSを生成するようにする。 5. UM11865 セクション 28.2 – I2S 設定手順 セクション28.2 UM11865確認し、6つの構成すべてを確認しています 手順は以下の通りです: ステップ1:Flexcommを有効にし、CLOCK_EnableClock+RESET + CLOCK_AttachClk ステップ2:FIFOXの設定(FIFOCFG=0x35、ENABLETX=1、SIZE=8) ステップ3:IO_MUX_SetPinMux(IO_MUX_FC3_I2S)でI2Sピンを設定し、AON MCI_IOMUX有効化 ステップ4:レート設定(CFG1 MSTSLVCFG=0b11=NormalMaster、DIV=3 → BCLK=3.072MHz) ステップ6：FIFOCFGでDMAを有効にする すべての手順に従ったにもかかわらず、以下のことが観察されました。 - GPIO25/GPIO26にSCK/WSエッジがない - TX FIFOがデータを受け付けない: TXNOTFULL=1だが、FIFOWR書き込み後もTXLVLは0のまま セクション28.2のステップ4には「コントローラの動作に関しては、クロックが I2S レート」ですが、PERSEL=I2S_RECEIVE が NormalMasterはパッドにSCK/WSを駆動する予定です。 もう少し詳しく教えていただけますか: 1.PERSEL=I2S_RECEIVE (0b101) は SCK/WS を出力として駆動できますか？ MSTSLVCFG=NormalMaster の場合？ 2. PERSEL=I2S_TRANSMITを指定してFIFOWRに書き込みを行った後、TXLVLが0のままになるのはなぜですか？ FIFOWR書き込みを受け入れる前にMAINENABLEが必要ですか？ 6．観察された問題点 – 具体的な質問 上記の設定がすべて完了したら、 GPIO25とGPIO26はゼロエッジを生成します。PCM6120 はクロックが欠落していることを報告します (ASI_STS = 0xFF、 DEV_STS1 = 0x80)。 さらに診断を実行しました。FC3を次のように構成しました。 I2S TXマスター （RXマスターの代わりに）そして、 FIFOWRへの書き込みはTXLVLをインクリメントしない — FIFOSTATは 0x30 （TXNOTFULL=1、TXLVL=0）私たちが書く単語の数に関係なく。 TXマスタプローブ後の関連レジスタの状態：   CFG1 = 0x17003C (MSTSLVCFG=3 = ノーマルマスター、DATALEN=24、MAINENABLE=0) DIV = 3 (分周器=4、BCLK = 12.288MHz / 4 = 3.072MHz) FIFOCFG = 0x35 (ENABLETX=1、TXI2SE0=1) FIFOSTAT = 0x30 (書き込み後、TXNOTFULL=1、TXLVL=0) MAINENABLE=1 の後: STAT = 0x5 (BUSY=1、LR=1 — クロックロジックが内部で動作中) GPIO25/GPIO26のSCK/WSエッジ: 0 NXPへの具体的な質問： FLEXCOMM3 I2Sが kI2S_MasterSlaveNormalMaster (TXまたはRX)として設定されている場合、RW612上でSCK/WSがGPIO25/GPIO26(AONドメイン)に駆動され ない ことが期待される動作でしょうか?STATではペリフェラルが内部で動作していると示されていてもです。 あるいは、単一のFLEXCOMMトポロジー(1つのFCがクロックマスターとRXデータ受信機の両方として)はRW612 I2Sハードウェアで サポートされている のでしょうか?それともRW612は常に2つの別々のFlexCommインスタンス(1つのTXマスター+1つのI2Sブリッジ経由のRXスレーブ)を必要とするのでしょうか? よろしくお願いします。 Re: RW612 FLEXCOMM3/I2S3 Supporting driver こんにちは、 @duyhung さん。セットアップの詳細情報を提供していただきありがとうございます。 参考マニュアル(RM00278)に基づき、I2Sインスタンスが通常のマスターモードで設定されている場合、SCKおよびWS信号は生成されるものの、データの送受信はしないように設定されており、これはCFG1[MSTSLVCFG]レジスタの31.1.RM00278 2節に詳述されています。I2Sドライバーでは、この構成は「I2S_TxInit(;「関数」は、使用中のFlexcommインスタンスと送信機インスタンスとしてのFIFOも設定します。 上記の情報に基づくと、共有信号を使用したダブルFlexcommトポロジー（既にテストした例で行われているように）が推奨されます。これは、 UM11865のセクション3.6.2.1.1の図9に示されている同様の例で実証されています。 RomanVR_0-1785886440838.png また、I2SとDMA再生のサンプルコードをベースにしている場合、そのサンプルコードに加えた変更点について教えていただけますでしょうか？

i.MX8MP Sエラー。リモートプロセスがM7コアとarecordプラグインを起動しますhw:wm8962audio,0 こんにちは、 FRDM-i.MX8MP(Linux 6.12.34-lts-next)では、WM8962でのALSAキャプチャは、Cortex-M7をリモートプロックで起動するまで問題なく動作します。M7ファームウェアが起動すると、arecordによってカーネルパニックが発生します。   要約： - M7なし: arecord OK - M7 の起動後: fsl_sai_runtime_resume でパニックが発生 → regmap_write (SError 0xbf000002) - BSP純正ファームウェアで再現しました： - imx8mp_m7_DDR_hello_world.elf - imx8mp_m7_DDR_rpmsg_lite_str_echo_rtos.elf SO、これはカスタムM7アプリに特有のものではありません。   再現: 1) Linuxを起動し、M7を停止したままにする 2) arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t.wav→ OK 3) echo stop > /sys/class/remoteproc/remoteproc0/state echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware echo start > /sys/class/remoteproc/remoteproc0/state 4) 同じ arecord → カーネルパニック (SError)   パニック経路（略式）： snd_pcm_capture_open → ... → fsl_sai_runtime_resume → regmap_write → SError 0xbf000002   試した内容: - imx8mp-cm7 DTノードからオプションの「オーディオ」(AUDPLL)クロックを削除→それでも失敗します - M7でAudioMIX所有権/Audio PLL initを無効にするclock_config →純正のままhello_worldでも失敗します   質問: 1) i.MX8MPでLinuxのSAI/wm8962とM7リモートプロックの同時使用はサポートされていますか? 2) SDK BOARD_BootClockRUN()をM7にマッピングすることは、A53のオーディオパワードメインと衝突しますか? 3) AudioMIX / fsl_sai のランタイム再開時に発生する SError に対する、6.12 の既知の修正方法はありますか？ 4) オーディオがLinuxに所有されている必要がある場合(M7ではUART/RPMsgのみ)M7におすすめclock_configはありますか?   ありがとうございます。   ------------------------- imx8mp-cm7 dts ノード -------------------------- imx8mp-cm7 {         compatible = "fsl,imx8mn-cm7" ;         rsc-da = < 0x55000000 >;         クロック= < & clk IMX8MP_CLK_M7_DIV >;              //<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;         クロック名= "core" , "uart4" ;         mbox-names = "tx" , "rx" , "rxdb" ;         mboxes = < & mu 0 1               & mu 1 1               & mu 3 1 >;         メモリ領域= < & vdevbuffer >, < & vdev0vring0 >, < & vdev0vring1 >, < & rsc_table >, < & m4_reserved >;         ステータス= "正常" ;         fsl、起動遅延ミリ秒= < 500 >;     };   ------------------ パニックログ ------------------ root@FRDM-test:/lib/firmware# echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware root@FRDM-test:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t_ex.wav [ 58.448085] CPU0 の SError 割り込み、コード 0x00000000bf000002 -- SError [ 58.448101] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448109] 汚染: [C]=CRAP、[O]=OOT_MODULE [ 58.448111] ハードウェア名: NXP FRDM-IMX8MPLUS (DT) [ 58.448113] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 58.448118] pc : _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448130] lr : regmap_unlock_spinlock+0x14/0x20 [ 58.448136] sp : ffff8000854e3670 [ 58.448138] x29: ffff8000854e3670 x28: ffff8000854e3c30 x27: 0000000000000001 [ 58.448147] x26: ffff0000d06da088 x25: 0000000000000000 x24: ffff0000d06da390 [ 58.448153] x23: ffff0000d1c18f60 x22: ffff0000d0363c10 x21: 0000000001000000 [ 58.448160] x20: 0000000000000000 x19: ffff0000d14a3000 x18: 0000000000000002 [ 58.448168] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 58.448174] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 58.448180] x11: 0000000000000000 x10: ffff0000dccabb90 x9 : 0000000000000390 [ 58.448188] x8 : ffff0000dccabbac x7 : ffff8000854e3940 x6 : ffff0000dccabba0 [ 58.448194] x5 : ffff8000808ed440 x4 : 0000000000000008 x3 : ffff8000808ece60 [ 58.448200] x2 : 0000000001000000 x1 : ffff0000dcca5280 x0 : 0000000100000001 [ 58.448208] カーネルパニック - 同期していません: 非同期SError割り込み [ 58.448211] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448217] 汚染: [C]=CRAP、[O]=OOT_MODULE [ 58.448221] ハードウェア名: NXP FRDM-IMX8MPLUS (DT) [ 58.448223]通話追跡: [ 58.448225] dump_backtrace.part.0+0xd4/0xe0 [ 58.448234] show_stack+0x18/0x30 [ 58.448240] dump_stack_lvl+0x60/0x80 [ 58.448246] dump_stack+0x18/0x24 [ 58.448251] パニック+0x168/0x360 [ 58.448258] add_taint+0x0/0xbc [ 58.448264] arm64_serror_panic+0x64/0x70 [ 58.448269] do_serror+0x3c/0x70 [ 58.448273] el1h_64_error_handler+0x30/0x54 [ 58.448279] el1h_64_error+0x64/0x68 [ 58.448283] _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448289] regmap_write+0x58/0x80 [ 58.448294] fsl_sai_runtime_resume+0xc4/0x280 [snd_soc_fsl_sai] [ 58.448304] pm_generic_runtime_resume+0x2c/0x44 [ 58.448312] __genpd_runtime_resume+0x30/0x80 [ 58.448318] genpd_runtime_resume+0x130/0x2c4 [ 58.448325] __rpm_callback+0x48/0x1e0 [ 58.448330] rpm_callback+0x68/0x80 [ 58.448334] rpm_resume+0x3bc/0x6a0 [ 58.448340] __pm_runtime_resume+0x50/0x9c [ 58.448344] snd_soc_pcm_component_pm_runtime_get+0x3c/0x138 [ 58.448350] __soc_pcm_open+0x60/0x488 [ 58.448355] soc_pcm_open+0x30/0x58 [ 58.448359] snd_pcm_open_substream+0x594/0x850 [ 58.448364] snd_pcm_open+0x118/0x24c [ 58.448368] snd_pcm_capture_open+0x4c/0x7c [ 58.448372] snd_open+0xa0/0x19c [ 58.448379] chrdev_open+0xb0/0x21c [ 58.448386] do_dentry_open+0x138/0x4c4 [ 58.448392] vfs_open+0x2c/0xf0 [ 58.448397] path_openat+0x6fc/0x1074 [ 58.448403] do_filp_open+0xa0/0x15c [ 58.448407] do_sys_openat2+0xc8/0x100 [ 58.448413] __arm64_sys_openat+0x64/0xc0 [ 58.448420] invoke_syscall+0x48/0x104 [ 58.448427] el0_svc_common.constprop.0+0xc0/0xe0 [ 58.448433] do_el0_svc+0x1c/0x28 [ 58.448438] el0_svc+0x30/0x100 [ 58.448444] el0t_64_sync_handler+0x120/0x12c [ 58.448450] el0t_64_sync+0x190/0x194 [58.448458] SMP: セカンダリCPUを停止します [ 58.448464] カーネルオフセット: 無効 [ 58.448466] CPU機能: 0x00,00000080,00200000,4200420b [ 58.448469] メモリ制限: なし [ 58.762124] ---[ カーネルパニック終了 - 同期していません: 非同期SError割り込み ]---   i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 こんにちは@humm Q1。はい、ただし両者が同じオーディオ資源を競合できない場合に限ります。 Q2。はい、対立は起こります。Linuxがオーディオを制御する場合、M7側はAUDIOMIXのマッピングや電源オンおよびSAI PLL初期化に関するコードを削除し、AUDIOMIXは完全にA53/Linuxのaudiomix_pdマネジメントに委ねられます。 Q3。いいえ、これはfsl_saiドライバーのバグではなく、リソース所有設定の問題です。 Q4。M7 SDK BOARD_RdcInit() — 最も重要なステップ:SAI3/SDMA3/I2C3のM7(DID1)割り当てを取り除くことです。RDC_PDAP_SAI3、RDC_MDA_SDMA3*、RDC_PDAP_SDMA3、およびRDC_PDAP_I2C3のDID1への割り当てを削除し、これらのリソースがA53からアクセスできるようにします。 B.R Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 こんにちは@pengyong_zhang ご指導いただき、誠にありがとうございました。 ご助言に従い、RDCの設定を更新し、SDMA3をドメイン0(A53/Linux)に割り当て、ドメイン0とドメイン1間でSAI3、I2C3、SDMA3の権限を共有しました。 以下は、私が適用したRDCの変更点の差分です。 -RDC_MDA RDC_MDA_SDMA3p DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3p DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3b DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3b DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3_SPBA2 DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3_SPBA2 DID0 0x0 0x0 -RDC_PDAP RDC_PDAP_SAI3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SAI3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_SDMA3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SDMA3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_I2C3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_I2C3 PDAP_D0D1_ACCESS 0x0 0x0 これらの変更を適用すると、ArecordはLinux上でSErrorをトリガーせずに動作し、M7コアがRTOSファームウェアを動かしている間も問題ありません。 ご協力ありがとうございました！

启用 XIP FLASH 重映射后，在镜像交换后对 MCUBoot 镜像进行调试/刷写。 各位亲爱的朋友们， 我想请教一下，为什么我们的U盘会在某种特定情况下出现故障？ 我们使用定制的电路板，搭载 IMXRT1176，我们的电路板基于 Embedded Artists 的该 MCU 载板。我们的项目中，闪存中有两个分区，分别为 0x30100000 和 0x30200000。我们使用 MCU-Link 和 Linkserver 来烧录二进制文件。在这种情况下，二进制文件会使用 --confirmed 进行签名。我们启用了 FLASH 重映射功能，因此不会执行交换操作。 我们观察到两种情况： 1.如果闪存中有引导加载程序，并且分区 1 中有镜像，则一切都按预期工作。 2. OTA 升级完成后，MCUboot 从第二个分区启动新镜像，此时我们将无法再写入 FLASH 分区 1，因为链路服务器会报错： ================================================= Nc：正在打开闪存驱动程序 MIMXRT1170_SFDP_QSPI.cfx（已驻留） Nc：发送 VECTRESET 以运行闪存驱动程序 Nc：检测到 Flash 变体“iMXRT1170_SFDP_FlexSPI1_A_QSPI 2026 年 5 月 15 日 18:32:39”（16MB = 256*64K，地址为 0x30000000） Pb：1/1 (0) 正在写入地址 0x30100000 的扇区 16-31，共 1048576 字节 PS：（0）位于 30100000：0 字节 - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) 状态 0x1 - 驱动程序报告驱动程序错误 - EXTSPIJ 驱动程序返回码 1 - 操作失败 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) 状态 0x1 - 驱动程序报告驱动程序错误 - EXTSPIJ 驱动程序返回码 1 - 操作失败 请注意，我已经使用 erase-range 命令擦除了第一个分区。我还可以确认，当我们的固件通过闪存驱动程序执行此操作时，它能按预期工作。只有当我尝试手动使用链接服务器时才会失败。 =================================================== 问题一：这样做有什么明显的原因吗？我们应该总是擦除分区 2 还是两个分区都擦除？ Q2. 如果我们为 slot1 构建了一个二进制文件，那么当我们将其连接到运行在分区 2 中的镜像的核心时，该二进制文件是否能正常工作？Flash 重映射能否使其正常工作？ 提前感谢您的帮助！ 此致！ 雅库布 Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled 你好 Gavin，非常感谢你的回复！你真的帮我理解了这些概念。 如果可以的话，能否请您再帮我解决一件事？ 这是我通过OTA更新获取到的分区信息： =========== 图片 0；名称 APP；状态 永久： 插槽 0 APP_PRIMARY；偏移量 0x100000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：C825709456C098E38090... log_addr 0x30100000 重映射为 0x30200000 插槽 1 APP_SECONDARY；偏移量 0x200000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：EBFCCC0D3E970230E404... log_addr 0x30200000 重映射为 0x30200000 *积极的* =============== 然后我运行这个脚本来清除 slot0。 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 根据你所说，我原本以为会删除 slot1，因为重新映射叠加层已启用。然而，事实并非如此。断电重启后出现的情况是： ========= Flash REMAP_OVERLAY 已激活。 图片 0；名称 APP；状态 无： 插槽 0 APP_PRIMARY；偏移量 0x100000；大小 0x100000 (1048576)： 插槽 1 APP_SECONDARY；偏移量 0x200000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：EBFCCC0D3E970230E404... log_addr 0x30200000 重映射为 0x30200000 *活跃*========= 我仍然无法向 slot0 写入任何内容，这出乎我的意料。是否有可能擦除操作绕过了重映射的逻辑映射，而加载操作则没有？ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled 你好@jslota13245 ， 感谢您对 NXP MIMXRT 系列产品的关注！ 根据您提供的信息，我认为应该考虑以下原因。故障是由以下原因造成的： FlexSPI 重映射仍然启用 OTA 之后。当 MCUboot 通过重映射启动 slot1（分区 2）时，它会将重映射保留到应用程序中。LinkServer 的  .cfx  闪存驱动程序通过 AHB 逻辑地址进行编程，因此重映射会静默地将您的写入操作重定向到  0x30100000  （分区1）到物理  0x30200000  （分区 2）——其中已包含已确认的图像，并且不为空。NOR闪存无法覆盖它。 你之前的  erase-range 0x30100000  实际上，出于同样的原因，我也删除了分区2。你自己的固件之所以能工作，是因为它通过以下方式进行编程： FlexSPI IP 命令模式，具有明确的物理偏移量，绕过重映射。注意：VECTRESET / 调试器附加 重映射并不明确——只有 POR 或显式寄存器写入才能实现。 问题1：要删除哪个分区？ 关键在于先禁用分区重映射，而不仅仅是删除分区。受到推崇的： 使用 LinkServer 进行编程之前，请清除重映射寄存器； 然后擦除两个分区（slot0 和 slot1）。由于 direct-XIP 会选择最高版本，因此插槽 1 中遗留的过时映像会导致 MCUboot 再次选择它并重新启用重映射，从而导致问题再次出现； Q2：当把 slot1 二进制文件附加到运行 partition2 镜像的核心上时，它能正常工作吗？ 图片应该链接 一次用于主槽（ 0x30100000 ）；同一个二进制文件通过重映射从任一槽运行——无需单独构建槽1的**版本**。当您附加到调试位置时，重映射会保持逻辑地址一致，因此代码读取/断点可以正常工作。然而，同样的重映射操作在写入闪存时会改变物理目标，所以你 在用 LinkServer 对 slot0 进行编程之前，必须先禁用重映射。 此致， 加文 Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled @Gavin_Jia 亲爱的加文： 请您看一下我对您回复的评论，看看我们是否遗漏了什么？ 非常感谢你的帮助！ 此致， 雅库布 Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled 你好@jslota13245 ， 很抱歉错过了您之前的消息。 遗憾的是，一旦答案被标记为已接受，系统就会自动认为问题已解决，我将不再收到有关此案件的更新信息。对于我的疏忽，我深表歉意。 我将尝试在我这边重现这个问题。请给我一些时间进行调查，如有任何调查结果或进展，我会及时向您汇报。 感谢您的耐心和理解。 此致， 加文 Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled 你好@jslota13245 ， 希望你一切都好！ 我继续深入调查此事，以下文章提供了一些初步结论： https://www.cnblogs.com/henjay724/p/13538105.html 擦除和编程功能不受重新映射的影响。两者都通过物理地址上的 FlexSPI IP 命令进行擦除，因此您的擦除范围 0x30100000 确实擦除了物理插槽 0——这就是为什么插槽 0 显示“未找到映像”而插槽 1 完好无损的原因。我之前关于擦除操作会命中插槽1的说法不准确，对此我深表歉意。写入操作仍然失败的原因是读取验证，而不是写入操作本身。 我认为最简单的解决方法仍然是在刷写镜像之前禁用重映射功能。或者，在刷写固件后，使用 IP 命令从内存中读取数据；如果读取的数据与写入的数据匹配，则证明故障仅仅是由于 AHB 校验和被欺骗所致。 此外，官方声明也支持了之前的猜测： https://mcuxpresso.nxp.com/mcuxsdk/latest/html/examples/ota_examples/_doc/flash_remap_readme.html#mcuboot-and-flash-remapping-feature

複数のAra240はP2P通信に対応しますか? 件名が全てを物語っている。 適切なPCIeスイッチで複数のAra240を接続し、P2P通信で大型モデルを動かすことはできますか? Re: Will multiple Ara240's support P2P communication? db16122_0-1785805134624.png ARA24のオンラインリソースはかなり限られているが、BAR2の内容には役立つだろう。

i.MX8MP S错误。远程进程启动 M7 核心并录制 plughw:wm8962audio,0 您好， 在 FRDM-i.MX8MP (Linux 6.12.34-lts-next) 上，在通过 remoteproc 启动 Cortex-M7 之前，wm8962 上的 ALSA 捕获工作正常。任何 M7 固件启动后，arecord 都会触发信号内核崩溃。   摘要: - 没有 M7：记录正常 - 启动 M7 后：fsl_sai_runtime_resume 出现 panic → regmap_write (SError 0xbf000002) - 使用电路板支持包。官方固件复现： - imx8mp_m7_DDR_hello_world.elf - imx8mp_m7_DDR_rpmsg_lite_str_echo_rtos.elf 所以这看起来并不局限于我们定制的M7应用程序。   复制： 1）启动Linux，保持M7停止运行。 2) arecord -Dplughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t.wav→ 确定 3) echo stop > /sys/class/remoteproc/remoteproc0/state echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware echo start > /sys/class/remoteproc/remoteproc0/state 4) 相同记录 → 内核崩溃 (SError)   恐慌路径（缩写）： snd_pcm_capture_open → ... → fsl_sai_runtime_resume → regmap_write → SError 0xbf000002   已尝试： - 从 imx8mp-cm7 DT 节点中移除可选的“音频”（AUDPLL）时钟 → 仍然失败 - 在我们的 M7 clock_config 中禁用 AudioMIX 所有权/音频 PLL 初始化 → 仍然无法使用默认的 hello_world 程序运行。   问题： 1) i.MX8MP 是否支持同时使用 Linux SAI/wm8962 和 M7 remoteproc？ 2) SDK BOARD_BootClockRUN() 将 AudioMIX 映射到 M7 是否与 A53 音频功率域冲突？ 3) 是否有针对 AudioMIX / fsl_sai 运行时恢复 SError 的 6.12 版本已知修复方案？ 4) 当音频必须由 Linux 控制时（M7 仅支持 UART/RPMSg），推荐的 M7 时钟配置是什么？   谢谢。   ------------------------- imx8mp-cm7 dts 节点 -------------------------- imx8mp-cm7 {         compatible = "fsl,imx8mn-cm7" ;         rsc-da = < 0x55000000 >;         clocks = < & clk IMX8MP_CLK_M7_DIV >;              //<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;         clock-names = "core" , "uart4" ;         mbox-names = "tx" , "rx" , "rxdb" ;         mboxes = < & mu 0 1               & mu 1 1               & mu 3 1 >;         memory-region = < & vdevbuffer >, < & vdev0vring0 >, < & vdev0vring1 >, < & rsc_table >, < & m4_reserved >;         状态= "正常" ;         fsl，启动延迟毫秒= < 500 >；     };   ------------------ 崩溃日志 ------------------ root@FRDM-test:/lib/firmware# echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware root@FRDM-test:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t_ex.wav [58.448085]CPU0上的SError中断，代码0x00000000bf000002——SError [ 58.448101] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448109] 已污染：[C]=CRAP，[O]=OOT_MODULE [ 58.448111] 硬件名称：NXP FRDM-IMX8MPLUS (DT) [58.448113]pstate：20000005（nzCv daif-PAN-UAO-TCO-DIT-SSBS BTYPE=--） [ 58.448118] pc : _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448130] lr : regmap_unlock_spinlock+0x14/0x20 [ 58.448136] sp : ffff8000854e3670 [58.448138]x29：ffff8000854e3670 x28：ffff8000854e3c30 x27：0000000000000001 [ 58.448147] x26: ffff0000d06da088 x25: 00000000000000000 x24: ffff0000d06da390 [ 58.448153] x23: ffff0000d1c18f60 x22: ffff0000d0363c10 x21: 0000000001000000 [ 58.448160] x20: 0000000000000000 x19: ffff0000d14a3000 x18: 0000000000000002 [ 58.448168] x17: 0000000000000000 x16: 00000000000000000 x15: 0000000000000000 [ 58.448174] x14: 0000000000000000 x13: 00000000000000000 x12: 0000000000000000 [ 58.448180] x11: 0000000000000000 x10: ffff0000dccabb90 x9 : 0000000000000390 [ 58.448188] x8 : ffff0000dccabbac x7 : ffff8000854e3940 x6 : ffff0000dccabba0 [ 58.448194] x5 : ffff8000808ed440 x4 : 0000000000000008 x3 : ffff8000808ece60 [ 58.448200] x2 : 0000000001000000 x1 : ffff0000dcca5280 x0 : 0000000100000001 [ 58.448208] 内核崩溃 - 未同步：异步 SError 中断 [ 58.448211] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448217] 已污染：[C]=CRAP，[O]=OOT_MODULE [ 58.448221] 硬件名称：NXP FRDM-IMX8MPLUS (DT) [ 58.448223]调用跟踪： [ 58.448225] dump_backtrace.part.0+0xd4/0xe0 [ 58.448234] show_stack+0x18/0x30 [ 58.448240] dump_stack_lvl+0x60/0x80 [ 58.448246] dump_stack+0x18/0x24 [ 58.448251] panic+0x168/0x360 [ 58.448258] 添加污点+0x0/0xbc [ 58.448264] arm64_serror_panic+0x64/0x70 [58.448269]do_serror+0x3c/0x70 [ 58.448273] el1h_64_error_handler+0x30/0x54 [ 58.448279] el1h_64_error+0x64/0x68 [ 58.448283] _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448289] regmap_write+0x58/0x80 [ 58.448294] fsl_sai_runtime_resume+0xc4/0x280 [snd_soc_fsl_sai] [ 58.448304] pm_generic_runtime_resume+0x2c/0x44 [ 58.448312] __genpd_runtime_resume+0x30/0x80 [ 58.448318] genpd_runtime_resume+0x130/0x2c4 [ 58.448325] __rpm_callback+0x48/0x1e0 [ 58.448330] rpm_callback+0x68/0x80 [ 58.448334] rpm_resume+0x3bc/0x6a0 [ 58.448340] __pm_runtime_resume+0x50/0x9c [ 58.448344] snd_soc_pcm_component_pm_runtime_get+0x3c/0x138 [ 58.448350] __soc_pcm_open+0x60/0x488 [ 58.448355] soc_pcm_open+0x30/0x58 [ 58.448359] snd_pcm_open_substream+0x594/0x850 [ 58.448364] snd_pcm_open+0x118/0x24c [ 58.448368] snd_pcm_capture_open+0x4c/0x7c [ 58.448372] snd_open+0xa0/0x19c [ 58.448379] chrdev_open+0xb0/0x21c [ 58.448386] do_dentry_open+0x138/0x4c4 [ 58.448392] vfs_open+0x2c/0xf0 [ 58.448397] path_openat+0x6fc/0x1074 [ 58.448403] do_filp_open+0xa0/0x15c [ 58.448407] do_sys_openat2+0xc8/0x100 [ 58.448413] __arm64_sys_openat+0x64/0xc0 [ 58.448420] invoke_syscall+0x48/0x104 [ 58.448427] el0_svc_common.constprop.0+0xc0/0xe0 [ 58.448433] do_el0_svc+0x1c/0x28 [ 58.448438] el0_svc+0x30/0x100 [ 58.448444] el0t_64_sync_handler+0x120/0x12c [ 58.448450] el0t_64_sync+0x190/0x194 [ 58.448458] SMP：停止辅助 CPU [ 58.448464] 内核偏移：已禁用 [ 58.448466] CPU 特性：0x00,00000080,00200000,4200420b [ 58.448469] 内存限制：无 [ 58.762124] ---[ 内核崩溃结束 - 未同步：异步 SError 中断 ]---   i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 嗨@humm Q1. 是的，但前提是两者不能争夺相同的音频资源。 Q2. 是的，会有冲突。在 Linux 控制音频的情况下，M7 端必须移除 AUDIOMIX 映射以及与开机和 SAI PLL 初始化相关的代码，将 AUDIOMIX 完全交给 A53/Linux 的 audiomix_pd 管理。 Q3. 不——因为这不是 fsl_sai 驱动程序中的错误，而是资源所有权配置问题。 Q4.M7 SDK BOARD_RdcInit() — 最关键的一步：移除 SAI3/SDMA3/I2C3 的 M7 (DID1) 分配。移除分配给 DID1 的 RDC_PDAP_SAI3、RDC_MDA_SDMA3*、RDC_PDAP_SDMA3 和 RDC_PDAP_I2C3，同时保持 A53 可以访问这些资源。 B.R Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 嗨@pengyong_zhang 非常感谢您的指导。 根据您的建议，我更新了 RDC 配置，将 SDMA3 分配给功能域 0 (A53/Linux)，并在功能域 0 和功能域 1 之间共享了 SAI3、I2C3 和 SDMA3 权限。 以下是我应用的RDC更改的差异： -RDC_MDA RDC_MDA_SDMA3p DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3p DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3b DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3b DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3_SPBA2 DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3_SPBA2 DID0 0x0 0x0 -RDC_PDAP RDC_PDAP_SAI3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SAI3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_SDMA3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SDMA3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_I2C3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_I2C3 PDAP_D0D1_ACCESS 0x0 0x0 应用这些更改后，arecord 在 Linux 上可以正常工作，不会触发任何 SError，即使 M7 内核正在运行其 RTOS 固件。 再次感谢你的帮助！

EZH-V 在 IMXRT700 上的应用案例 NXP团队，大家好！ 根据 IMXRT700 的规格说明，它的架构分为媒体、计算和感知功能域三个功能域，芯片上的每个核心都需要自己独立的镜像才能运行。但似乎只有极少数文献记载了 EZH-V 内核的使用情况。 我已阅读应用笔记 AN14614、AN14618 和 AN14654，但关于此核心及其在 RT700 图形处理中的作用的信息仍然很少。据说它是用来实现智能DMA引擎的，但在其他MCX系列MCU中并没有提到这个内核的存在，而且Arm CM33内核可以通过mcuxpresso sdk提供的API直接使用智能DMA。 我现在非常困惑，我还能直接在 iMXRT700 上使用 smartDMA 吗？还是必须按照 AN14614 的说明，通过 LLVM 为 EZH-V 版本镜像？这似乎相当违反直觉，因为 IPC 通信本应由 Cpu0 直接驱动，却不得不求助于 RPMsg。 除此之外，我还没有看到 NXP 提供任何实际的演示或用例来明确地使用 EZH-V 内核。我还查看了一些可用的源头文件，发现其中只提供了一些非常直观的基本操作。请问EZH-V的用途是什么？ Re: EZH-V use case for IMXRT700 好的，快速更新一下，在查看了 Zephyr 主线中的 smartDMA 驱动程序后，我现在明白情况了。 smartDMA 一直以来都被设计成一个独立组网 (SA)的子系统，拥有自己的内核，有可能独立运行固件，但从未真正作为完全独立组网 (SA)的 RISC-V 内核推出。 TomC818_0-1785476896221.png 在当前现有的示例中，smartDMA 从未真正接触过自定义固件安装路径，而只是用作一个略微特殊的 DMA IP。 所以现在的问题应该是，我是否还能以旧的方式使用 smartDMA；直接通过 CM33 调用，而不是进行复杂的 IPC 设置。截至撰写本文时，smartDMA IP 尚未作为官方维护的 mimxrt700_evk 支持的 IP 公开。 TomC818_1-1785477330180.png Re: EZH-V use case for IMXRT700 嗨@mayliu1 ， 感谢您的快速回复，所以您的意思是 smartDMA 不再与 CM33 内核耦合，因此必须通过 EZH-V 内核使用吗？ 在恩智浦的其他MCU系列（例如MCX）中，智能DMA与CM33耦合，可以通过API直接调用。应用笔记AN14172和AN14916记录了此类用例，并且这些用例不涉及构建RISC-V内核的独立组网 \(SA\)镜像。 TomC818_0-1785417939531.png 那么i.MXRT700目前的架构是怎样的呢？所有关于EZH-V的文档都非常含糊不清，而且我目前还没有找到任何全面介绍EZH-V使用的演示或指南。 NXP 是否修改了 smartDMA 的架构，使其不再是 CM33 核心系统的一部分，而是归入 RISC-V 配套核心？我还能通过 CM33 直接调用 smartDMA 吗？ Re: EZH-V use case for IMXRT700 嗨@TomC818 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 根据 AN14614 和 i.MX RT700 参考手册，我的理解是 i.MX RT700 上的 SmartDMA 功能是通过 EZH-V RISC-V 内核实现的，而不是作为传统的 DMA 外设（如 eDMA）。 总的来说，eDMA 仍然是标准内存传输操作的首选解决方案，并且可以通过 CM33 内核直接配置。然而，与 SmartDMA 相关的处理，例如某些图形/数据后处理或数据格式转换任务，通常是由在 EZH-V 内核上运行的固件实现的。 根据 AN14614，CPU0 负责加载和启动 EZH-V 固件，之后实际处理由 EZH-V 执行。从这个角度来看，EZH-V 的行为更像是一个可编程协处理器，而不是传统的 DMA 引擎。 因此，RT700 上的 SmartDMA 最好被视为在 EZH-V 内核上运行的可编程处理引擎，而不是仅由 CM33 直接驱动的传统 DMA 外设。 希望对你有帮助 顺祝商祺！ 5月 Re: EZH-V use case for IMXRT700 嗯……如果恩智浦实际上并没有准备或计划支持“借助 EZH-V，Cortex-M33 内核可以腾出空间执行其他任务。在 EZH-V 执行分配的任务时，CM33 内核可以并行执行其他任务。 ”根据参考手册所述，考虑到 RT700 的文档和示例仍然非常不完善且杂乱无章，我认为我将寻求 ST 或 Infineon 以外的其他选择。对于这款MCU的大多数市场化独特功能，支持非常有限，寥寥无几。对于如此复杂且异构的架构，如此少的例子和指南简直是无稽之谈。 Re: EZH-V use case for IMXRT700 在 i.MX RT700 上，SmartDMA 的公开方式与由 CM33 直接控制的传统独立 DMA 外设不同。 SmartDMA 功能是通过 EZH-V 引擎提供的，因此典型的使用模型是 CM33 加载并启动 EZH-V 固件，然后根据需要与其协调。 mayliu1_1-1785830645435.png

我需要为SPI配置DMA。 我正在使用 S32DS IDE 和 RTD 3.0，请问有人能告诉我如何通过 SPI 启动 DMA 吗？最好能提供详细的步骤说明或示例代码。 Re: I need to configure DMA for SPI 谢谢你的回复 请对 s32k322 MCU 执行此操作 Re: I need to configure DMA for SPI 嗨@ershi RTD 附带两个使用 DMA 进行 SPI 通信的示例代码，一个使用低级驱动程序 (Ip)，一个使用高级驱动程序 (MCAL)。您可以参考主题HOWTO: S32 Design Studio - 从示例创建新的 S32DS 项目，以获取有关如何导入示例的指导。 另外，您可以参考主题“示例 S32K31 SPI 多数据包发送和接收：DMA 缓存问题的解决方案”中提供的示例。 BR，VaneB Re: I need to configure DMA for SPI 嗨@ershi 虽然这些示例并非专门为 S32K322 设计，但除非参考手册另有说明，否则其功能在 S32K3 系列中通常相同。因此，您可以将此项目作为您实现的参考，并根据您的特定设备进行必要的调整。 Re: I need to configure DMA for SPI 我已经配置好了一切，但它仍然无法正常工作。第一次调用 (Lpspi_Ip_AsyncTransmit) 时返回 LPSPI_IP_STATUS_SUCCESS，第二次调用时返回失败 LPSPI_IP_STATUS_FAIL。我可以使用这个 API 通过 SPI 发送数据，而无需使用 DMA 调用 Lpspi_Ip_SyncTransmit()。我附上了一些配置截图。 Re: I need to configure DMA for SPI 嗨@ershi 能否也分享一下RM和IntCtrl_Ip驱动程序的配置图片？ Re: I need to configure DMA for SPI 嗨@VaneB 我已附上 RM 和 IntCtrl_IP 驱动程序配置的屏幕截图，以及一段简短的视频片段，供您详细参考。 我注意到LPSPI配置页面中有一处不同。在SPI常规选项卡中， Spi_Phy_TxDmaChannel下的命名在TX和RX配置中有所不同。 如果您需要任何其他详细信息，请告诉我。 InterruptsInterruptsInterruptsInterruptsInterruptsInterruptsInterruptsInterrupts打断 RMRMRMRMRMRMRMRMRM Lpi.png Re: I need to configure DMA for SPI 嗨@ershi 感谢您分享所有信息。 我只有一点看法。在 Dma_Ip 驱动程序配置中，您已将 DMA_SPI_CALLBACK_0 定义为中断回调。然而，LPSPI DMA 回调函数已由驱动程序提供，可以在 Lpspi_Ip_Irq.c 文件中找到。文件。 对于 LPSPI2，配置的回调函数应为： TX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqTxDmaHandler RX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqRxDmaHandler Re: I need to configure DMA for SPI 嗨@ershi 请问您是如何实现SPI通信的？另外，您是否测试过我之前分享的示例代码？ Re: I need to configure DMA for SPI 嗨@VaneB 谢谢你的解释。 我更新了 Dma_Ip 配置，以便对于 LPSPI2，TX 和 RX DMA 通道现在使用 Lpspi_Ip_Irq.c 中的回调函数： TX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqTxDmaHandler NXP RX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqRxDmaHandler 然而，在我这边，基于 DMA 的 LPSPI 传输仍然没有按预期工作。我附上了当前配置的截图供您参考。如果还有其他设置需要调整，请告诉我。 Re: I need to configure DMA for SPI 嗨@ershi 您是将 LPSPI2 SOUT 信号直接连接到 SIN，还是使用逻辑分析仪来验证发送和接收的数据？ Re: I need to configure DMA for SPI 嗨@VaneB 我已经删除了之前的配置，现在SPI数据正在通过DMA传输，但问题是数据不匹配。 #define RX_MSG_SIZE (15U) #define TX_MSG_SIZE (15U) uint8_t txBuffer_check[TX_MSG_SIZE] = {0x48,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x10,0x11,0x12,0x13,0x14,0x15}; uint8_t rxBuffer_check[]={0}; if(Lpspi_Ip_AsyncTransmit(&Lpspi_Ip_DeviceAttributes_SpiExternalDevice_1_Instance_2_BOARD_InitPeripherals,txBuffer_check,rxBuffer_check,TX_MSG_SIZE,spi_DMA_Function) == LPSPI_IP_STATUS_SUCCESS) { Dma_Ip_ReturnType 状态 = {0},状态1 = {0}; Dma_Ip_LogicChannelStatusType channelStatus ={0},channelStatus1 ={0}; status = Dma_Ip_GetLogicChannelStatus(DMA_LOGIC_CH_0,&channelStatus); status1 = Dma_Ip_GetLogicChannelStatus(DMA_LOGIC_CH_1,&channelStatus1);   返回 SYS_SUCCESS； } Re: I need to configure DMA for SPI 嗨@VaneB ， 我已经重写了代码，现在运行完美。数据输入正确。 谢谢你的帮助。 Re: I need to configure DMA for SPI 嗨@VaneB 在我们之前关于配置 SPI 的 DMA 的讨论中。我注意到接收缓冲区的数据与逻辑分析仪的数据不匹配，而发送缓冲区工作正常。我已在 Dropbox 中添加了详细信息。

关于 RW612 OTBR 线程认证架构的问题 您好，NXP团队，   我注意到了线程组认证的元器件：   “NXP RW612 无线 MCU 集成三频 OTBR” （线程 1.4）   我还找到了以下方面的单独认证：   - NXP i.MX MPU 搭载 IW610 三频 OTBR - NXP i.MX MPU 搭载 IW612 三频 OTBR - NXP RW612 无线 MCU，集成三频 OTBR   我想更好地了解 RW612 OTBR 认证所使用的认证架构。   请问您能否澄清一下：   1. 是否使用 RW612 作为独立组网 \(SA\) 的基于 MCU/RTOS 的线程边界路由器获得认证？   2. 认证配置中是否使用了外部 RCP/NCP 设备？   3. 认证过程中使用了哪个软件平台（FreeRTOS、Zephyr 或其他平台）？   4. 是否有公开的参考设计或文档描述了经过认证的 RW612 OTBR 实现？   我们的目标是了解 RW612 OTBR 认证是否代表基于 MCU 的独立组网 \(SA\)线程边界路由器解决方案，而不是基于 Linux 主机的 OTBR 架构。   感谢您的支持。   顺祝商祺！ 赵京焕   Re: Question about RW612 OTBR Thread Certification Architecture 你好， 希望你一切都好。我叫里卡多，这个案子交给了我。 A1：是的。RW612 OTBR 认证是一个真正的独立组网 (SA)单芯片解决方案。 A2：不。与 i.MX MPU + IW610/IW612 OTBR 认证（使用带有外部 IW6xx 无线电协处理器的 Linux 主机，RCP 模式）不同，RW612 认证不使用任何外部 RCP 或 NCP 设备。 A3：让我确认一下。 A4：有关测试配置、测试报告或认证范围的具体详情，请直接联系 Thread Group，网址为threadgroup.org 。 顺祝商祺！ 里卡多 Re: Question about RW612 OTBR Thread Certification Architecture 你好@KyonghwanCho ， 感谢您的耐心等待。 我已经确认所使用的软件平台是 FreeRTOS。 另外，请查看下方的 OTBR 用户指南和版本指南。 ot-nxp/examples/br/README-OTBR.md 位于 版本/v1.4.0.5_26.03 · NXP/ot-nxp ot-nxp/src/rw/rw612/README.md 位于 版本/v1.4.0.5_26.03 · NXP/ot-nxp 顺祝商祺！ 里卡多

代码、连接、NXP 与 WS2812 你好， 我是 NXP 微控制器的新手，想用它来连接一个 16 像素的 WS2812B RGB LED 灯条。 您会推荐哪款NXP开发板用于这个项目？ 我也很希望获得一些关于控制 WS2812B LED 的示例项目、SDK 示例或文档。 谢谢。 Re: Code, Connections, NXP with WS2812 感谢您对恩智浦产品的关注！ FRDM-MCXA366是您项目的理想板。 NXP 提供了一份专用的面向初学者的应用笔记，详细演示了如何使用 MCX A366 控制WS2812B LED 。该文档包括板推荐、硬件连接、源代码和分步设置说明。 AN14980 – 在 MCX A366 上使用 FlexIO 模拟 WS2812 总线 本应用笔记详细解释了如何使用 MCX A366 上的 FlexIO 模块来模拟 WS2812 通信协议并驱动 WS2812B LED。 这应该能提供你开始设计所需的一切。 如有任何疑问，请随时提出。 顺祝商祺！ 阿隆德拉 Re: Code, Connections, NXP with WS2812 你好，阿隆德拉， 谢谢你的建议！我们的设计仍在评估阶段。 在决定使用哪款电路板之前，我想确认一下 LPC5514JBD64E 是否也支持 WS2812 LED？ 此致， 基肖尔

S32K388 TCP/IP 协议栈 5.0.0 无法正常工作 嗨@PavelL ， 我之前使用以下配置成功运行了 TCP/IP 协议栈示例项目： • S32KDS 版本 3.6.5 • RTD（实时驱动程序）版本 7.0.0 • TCP/IP协议栈版本4.0.0 但是，升级到以下版本并执行相同的设置步骤后，却无法正常工作： • S32KDS 版本 3.6.8 • RTD（实时驱动程序）版本 7.0.1 • TCP/IP协议栈版本5.0.0 我已附上我的项目。再次感谢你的帮助。 Re: S32K388 TCP/IP stack 5.0.0 not working 你好@James_Zhang_SE ， 我需要时间进行调查。我会尽力在本周内回复。 感谢您的理解。 顺祝商祺！ 帕维尔 Re: S32K388 TCP/IP stack 5.0.0 not working 你好@James_Zhang_SE ， 由于工作繁忙，回复有所延迟，敬请谅解。 根本原因是 EthIf_Cfg.c正如我们之前在这个帖子中讨论过的，S32K388 TCP/IP 堆栈 4.0.0 在编译时缺少 lwip 文件夹 该示例现在在我的 S32K388EVB-Q289 上运行正常。 总之，我对你的项目做了很多修改，但最关键的是 EthIf_Cfg 文件。所有修改后的文件都可以在附件的压缩包中找到。您可以自行查看更改。 请注意，所提供的代码不提供任何担保。 用补丁替换文件后，请不要忘记执行代码更新。 顺祝商祺！ 帕维尔 Re: S32K388 TCP/IP stack 5.0.0 not working 你好，帕维尔， 非常感谢您的帮助！按照之前的步骤操作后，我能够 ping 通并测试 TCP 回环地址。我有几个问题想问一下： 对于 Ethif 配置修复和 RTD 变通方案，它们是否会在驱动程序和示例项目的未来版本中添加？ 由于我对这个技术栈不太熟悉。当出现故障时，您是否有系统性的调试方法建议？ Re: S32K388 TCP/IP stack 5.0.0 not working 你好@James_Zhang_SE ， 感谢您分享您的最新情况。   如果我之前的帖子帮助您解决了问题，请将其标记为解决方案，因为这可能会帮助其他遇到类似问题的用户。   关于第一点：   我已经将 EthIf_Cfg 问题报告给了相关的软件团队。修复程序的发布日期尚未确定。目前内部仍在讨论 RTD 变通方案应该在何处实施，是在 MAC 驱动程序中还是在时钟配置区域中。目前，我们只能接受现状，并手动应用变通方案。   关于第二点：   我通常的调试流程是检查引脚配置、时钟配置、中断配置、FIFO 大小以及所需的 RTD 变通代码。gPTP 示例也是一个很好的参考，因为它们提供了可用于比较的功能性以太网相关配置。 顺祝商祺！ 帕维尔

我想使用 Flexio 作为特殊的 SPI，同时输出 20 位 MOSI 信号。 需要同时控制 20 个芯片 DAC，我想使用 Flexio 作为特殊的 SPI 来控制这些 DAC 设备。如下所示： 一个 cs， 一声钟响， 使用 20 个 MOSI 板，通过 20 个引脚同时向 20 个 DAC 设备输出 DAC 值，请问可以提供 MCUEXPROS 代码和项目吗？ 谢谢您！ 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 这个问题太难了，是不是没人能给出任何建议？ 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 1、cs拉低级别 2、每次传输20通道MOSI，每个通道传输一位，一次传输使用一个移位寄存器。 3、传输8次，使用全部8个移位寄存器，每个通道传输8位。 4、步骤 2、3 是一次 DMA 传输。使用 3 倍的 DMA 来传输每个通道的 24 位数据，因为 DAC 芯片是 24 位的。 5、拉高 cs。 这样可以吗？ 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 有人在吗？ Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time 我使用的芯片是mcxn947。 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 嗨@justdomyself 对于类似的实现，我建议查看 FlexIO QSPI 应用笔记 AN14175 和 MCUXpresso SDK 中的 FlexIO SPI DMA 示例。 AN14175 示例演示了如何使用 FlexIO 定时器和移位器创建自定义串行接口，这更接近于您使用一个时钟和多个数据输出同时驱动 20 个 DAC 通道的要求。 FlexIO SPI DMA 示例对于理解 FlexIO 定时器、移位器和 DMA 的基本配置也很有用。 BR 哈里 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time AN14175    对应的工程代码在哪个位置？从哪下载？ 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 导入的时候报错： justdomyself_0-1785394860116.png 编译的时候报错： justdomyself_1-1785394889652.png debug 的时候报错： justdomyself_2-1785394917545.png 执行 BOARD_PowerMode_OD   。debug直接崩溃报上图错误。 能不能给个新一点的可以用的工程，  我的软件版本：MCUXpresso IDE v25.6 [Build 136] [2025-06-27] 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 嗨@justdomyself 搜索 | 恩智浦半导体 请在NXP官方网站上搜索AN14175。 您可以点击关联文件：AN14175SW 下载该软件。 Harry_Zhang_0-1785384066285.png BR 哈里 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 嗨@justdomyself 您可以下载与 AN14175 对应的 SDK 版本。 BR 哈里

S32K358 eMIOS ISRが85℃で停止 親愛なるNXPサポートチームへ、 S32K358において、約85℃の温度試験中に問題が発生しています。   私たちのアプリケーションでは6つのeMIOSチャネルを使用し、それぞれが200Hzの周波数で両方のPWMエッジで割り込みを生成するように設定されています。   85°Cでは、MCUが時々1つのeMIOS ISR内に閉じ込められることがあります。ISRは終了しません。コードがeMIOSレジスタを読み取り割り込みフラグを確認するためですが、フラグは0(ファイルEmios_Mcl_Ip_Irq.c)です 😞   もし (0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。S) & (uint32)eMIOS_S_FLAG_MASK))   デバッグの結果、問題が発生するとeMIOSのベースアドレスを含む変数がNULL(Emios_Ip_paxBase)であることに気づきました。アプリケーションが正しく動作すれば、同じポインタが有効で、eMIOSレジスタも正しく読み込まれます。 ある条件下では、ISR実行中にeMIOSペリフェラルへの参照が破損またはクリアされているようです。   スタックオーバーフロー、メモリ破損、同時アクセス、ISR処理、温度関連の挙動など、既知の問題や根本原因について何か兆候はありますか?   よろしくお願いいたします。 サイモン Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、ベインさん。 現在、RTD 7.0.0を使用しています。 Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん どのRTDバージョンを使用していますか？追加情報があれば助かります。 また、RTD バージョン 6.0.0 より前のバージョンでは、関数スコープ内の静的変数のメモリ マッピングが正しくないことに関連する既知の問題がありました (ARTD-159985)。 この問題は、Emios_Mcl_Ip.c で定義されている変数 Emios_Ip_paxBase に関する問題です。また、Emios_Mcl_Ip_Irq.c には、一貫性のない初期化特性が割り当てられています。詳細はソフトウェアリリースノートに記載されています。 BR、VaneB Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん 観察された挙動を再現できる簡単なアプリケーションを教えていただけますか?また、カスタムボードを使っているのか評価ボードなのか確認してもらえますか? さらに、問題が85°Cで発生していることを確認するための検査方法について教えていただけますか? Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん この情報を提供していただき、誠にありがとうございます。 コードがEMIOS1_1_IRQで詰まっているようで、あなたの設定からeMIOS 1チャンネル19に対応しているため、この特定の部分に分析を絞り込んでみます。 デバッグを簡素化し、他のモジュールからの干渉を排除するために、このeMIOS構成のみを含む最小限のテストプロジェクトを作成してください。これにより、問題の動作を特定し、根本原因をより深く理解するのに役立ちます。参考までに、スレッド S32M27x/S32K3 – eMIOSの利用法で示されている例を確認できます。 同じ現象は依然として発生しますか？また、評価ボードがあるなら、同じコードをそこで試せたら素晴らしいです。 Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @VaneB さん。 現在、カスタムボードでS32K358を使ってこれらのeMIOS_1チャンネルを使って200HzのPWMを生成しています:ch3、ch9、ch11、ch12、ch13、ch19。コードはSIMulinkを使用して生成されます 自作の基板を85℃の恒温恒湿槽に入れたところ、しばらくすると動作が停止する現象が見られました。 S32DS (3.6.7) でデバッグしていたときISR(EMIOS1_1_IRQ)に組み込まれていることが分かり、エントリ/エグジット近くのカスタムカウンターやEmios_Pwm_IrqHandler・Emios_Pwm_Ip_IrqHandler関数にも組み込み、どのコード部分が実行されているかを検出しました。 いくつかのテストの結果、内部で詰まったときに static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { /* エミオスチャネルでイベントが発生しているか確認してください */ もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。S) & (uint32)eMIOS_S_FLAG_MASK)) { /* EMIOSチャネルでイベントが発生しているか確認してください */ もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))) { Emios_Pwm_Ip_IrqHandler(インスタンス、チャネル); } そうでなければ { /* 何もしない - 偽の中断があった場合は直ちに戻ってください */ } } }   if条件: もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。S) & (uint32)eMIOS_S_FLAG_MASK))   なぜなら、何らかの理由でEmios_Ip_paxBase[インスタンス]が0を指すため、常に0です。つまり、誰も割り込みフラグをクリアしていないため、割り込みフラグは脱出できないループに入ってしまいます。   この問題を検出するために使用したコードは以下のとおりです。 static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { uint32_t s; uint32_t c; uint32_t s_flag; uint32_t s_ovr; dbg_pwm_last_instance = インスタンス; dbg_pwm_last_channel = チャネル; dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[インスタンス]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。S;     dbg_emiosipirq_static_state1++; /* もし (インスタンス == 1) { スイッチ(チャネル) { CASE 16: dbg_emiosipirq_static_cnt_ch16++; 休憩;             CASE 17:                 dbg_emiosipirq_static_cnt_ch17++;                 休憩; ケース18: dbg_emiosipirq_static_cnt_ch18++; 休憩;             case 19:                 dbg_emiosipirq_static_cnt_ch19++;                 休憩; デフォルト： dbg_emiosipirq_static_cnt_oth1++; 壊す; } } それ以外 ヤージュ dbg_emiosipirq_static_cnt_oth2++; } */ /* Lettura reale dei registri vista dal codice */ /* s = Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。S; c = Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。C; s_flag = s & (uint32)eMIOS_S_FLAG_MASK; s_ovr = s & (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s = s; dbg_pwm_last_c = c; dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK; dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s_and_flag = s_flag; dbg_pwm_last_s_and_ovr = s_ovr; if (s_flag != 0U) ヤージュ dbg_pwm_s_flag_yes++; } それ以外 ヤージュ dbg_pwm_s_flag_no++; } if (s_ovr != 0U) ヤージュ dbg_pwm_s_ovr_yes++; } それ以外 ヤージュ dbg_pwm_s_ovr_no++; } if ((s_flag == 0U) && (s_ovr != 0U)) ヤージュ dbg_pwm_flag0_ovr1_count++; } そうでなければ、((s_flag != 0U) && (s_ovr != 0U)) ヤージュ dbg_pwm_flag1_ovr1_count++; } else if ((s_flag != 0U) && (s_ovr == 0U)) ヤージュ dbg_pwm_flag1_ovr0_count++; } それ以外 ヤージュ dbg_pwm_flag0_ovr0_count++; } */ /* EMIOSチャネルでイベントが発生しているか確認してください */ もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。S) & (uint32)eMIOS_S_FLAG_MASK)) { dbg_emiosipirq_static_state2++; /* EMIOSチャネルでイベントが発生しているか確認してください */ もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))) { dbg_emiosipirq_static_state3++; Emios_Pwm_Ip_IrqHandler(インスタンス、チャネル); } そうでなければ { dbg_emiosipirq_static_state4++; /* 何もしない - 偽の中断があった場合は直ちに戻ってください */ } } そうでなければ { dbg_emiosipirq_static_state5++; Emios_Pwm_Ip_IrqHandler(インスタンス、チャネル); Emios_Pwm_Ip_IrqHandler(1, 19); } } Emios_Ip_paxBaseが指すべきアドレスを格納したグローバル変数は以下のとおりです。 dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[インスタンス]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。S; また、NVICレジスタの実行時を読み取るカスタムコードも入れました。添付すると、Thread、ジェネラルレジスタ、NVICレジスタと変数式、EMIOSレジスタ、6つのテスト用レジスタが入ったファイルがあります。 また、この動作をテストするために使用したS32DSプロジェクトをプライベートメッセージでお送りします。 これらの情報が役に立てば幸いです。何かご不明な点がございましたら、いつでもお気軽にお問い合わせください。 BR、 サイモン Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、ベインさん。 今週中に、その動作を再現する簡単なプロジェクトを用意してみます。 Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @VaneB さん。 カスタムボードで、eMIOS1チャネル6チャネルのみを含む簡易設定で問題をテストしました。残念ながら、この設定ではエラーを再現できません。アプリケーションは正しく動作し、EMIOS_1_IRQで詰まることはありません。 現在、カスタムボード用に開発したプロジェクト全体をEVBにロードすることが可能かどうかを検討しています。進める前に、カスタムボードとEVBのハードウェアの違いが、予期せぬ挙動やEVBの損傷を引き起こす可能性があるかどうかも知りたいです。 BR、 サイモン Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん 当社の評価ボードは主に室温での使用を想定しており、非常に低温または非常に高温での試験や認証はされていません。 評価ボードは室温範囲外でも使用できますが、その条件下での性能を保証することはできません。 Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @VaneB さん。 何度か試みた結果、カスタムボード上で動作するアプリケーションをできるだけ忠実に再現するEVBプロジェクトを作成することができました。特に、すべてのピンを自分のカスタムプロジェクトと同じように設定しました。 このプロジェクトをカスタムボードで85°Cの条件下でテストしましたが、eMIOS ISRの問題は依然として発生し、アプリケーションが固着し続けました。 その後、全く同じプロジェクトをEVB上で同じ温度条件（90℃以上）でテストしましたが、問題は再現できませんでした。EVBはフリーズすることなく正常に動作し続けました。 この時点で、問題の根本原因を特定し、解決策を見つけるために、次にどのような手順を踏むことをお勧めしますか？ 追加の情報、測定値、またはデバッグデータが必要な場合は、お知らせください。 完全なEVBプロジェクトと、カスタムボードおよびEVB上のK358の写真を含むZIPファイルを添付しました。 再開まで今しばらくお待ちください。 BR シモーネ Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん この問題はカスタムボードで観察されていますがEVBでは見られません。根本原因がハードウェアに関連している可能性を調べる価値があります。 ハードウェア設計をEVBの回路図と比較し、S32K3ハードウェア設計ガイドラインを確認して、関連する推奨事項が適切に実装されているか確認することをお勧めします。 Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @VaneB さん。   ハードウェア設計は我々側でレビュー済みで、明らかなハードウェア問題は見つかりませんでした。また、ハードウェア設計や動作条件が異なるため、NXP EVBとは直接比較できません。   お客様がカスタムボードで温度に関する問題を観察した場合、NXPから一対一のサポートをどう受けることができるのでしょうか?   BR、 サイモン Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @VaneBさん この件について、私たち自身も調査中なので、皆様のご意見をいただきたいと思います。 特に、根本原因がRAMの破損（例えば、境界外書き込みやスタックの上書き）に関係している場合、S32K358ではどのレジスタまたは診断情報を確認することをお勧めしますか？ eMIOS ISRが詰まる前にメモリ破損が発生していないかを特定するのに役立つ、特定のフォールト状態レジスタ、ECC/エラー報告レジスタ、MPU関連レジスタ、スタック監視機能、その他のデバッグレジスタはありますか? デバッグ時に検査すべき最も有用なレジスタについて、何かご助言いただければ大変ありがたいです。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 サイモン Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん これはあなたのボードに特有のハードウェア関連の問題のようで、再現できないため、このサポートチャネルからは正確な根本原因の診断が難しいです。さらなるサポートは、代理店または地元のNXP担当者にご連絡することをおすすめします。

FlexBuild LSDK-25.12のイメージ固有のSBOMおよびCVE評価サポート こんにちは、NXPチームの皆様、 FlexBuildと組み合わせたLSDK-25.12_DEBIAN-13_LF-6.12.20を使って、i.MX8MP用のDebianベースの製品イメージを構築しています。RED / EN 18031に基づく脆弱性評価および適合性評価をサポートするために、最終出荷画像におけるソフトウェアコンポーネントおよび既知の脆弱性を特定するための繰り返し可能なプロセスを確立する必要があります。 FlexBuild 25.12のソースツリーを調査した結果、以下のことが判明しました。 SBOM-flexbuild.spdx.jsonは、ビルドイメージの内容ではなく、FlexBuildツール自体を説明するパッケージエントリが1つだけ含まれます。 SCR.txt SDK全体のソフトウェアコンテンツレジスタであり、特定のターゲットイメージに実際にインストールされたコンポーネントを表すものではありません。 フレックスビルダーでは、画像固有のSBOMやCVEマニフェスト生成メカニズムを特定できませんでした。 これらの調査結果を踏まえ、以下の点を明確にしていただけますか? NXPは現在、FlexBuild Debianビルドから画像ごとのSPDX文書のような画像固有のSBOMを生成する公式または推奨の方法を提供していますか? もしこの能力が計画されている場合、目標のリリースや予想される稼働状況を教えていただけますか? NXPは現在、Debian Linux SDKs / FlexBuild向けにVigiles統合を提供している、または提供する予定がありますか?これはYoctoで利用可能なmeta-timesysワークフローに相当します。 直接統合が利用できない場合、Vigiles FAQに記載されているように、CSVマニフェストを手動で作成してインポートする方法は、FlexBuildベースのイメージに対して依然として推奨されるアプローチですか？ このリリースに含まれる以下のコンポーネントのセキュリティアドバイザリー、CVE適用情報、セキュリティ修正の公式情報源は何ですか? Linux-IMX LF-6.12.20-2.0.0 uboot-imx lf-6.12.20-2.0.0 imx-atf imx-optee-os NXPが提供するファームウェアおよびDDR、HDMI、VPU、ワイヤレスファームウェアなどのバイナリパッケージ 例えば、NXPのセキュリティアドバイザリー、リリースノートの修正済みCVEリスト、特定の維持管理されているGitブランチ、あるいは他の公式ソースに頼るべきでしょうか? LSDK-25.12および関連するlf-6.12.20 BSPコンポーネントの保守およびセキュリティ更新のライフサイクルはどのようなものですか? 特に： このリリースのセキュリティ修正はどのくらいの期間提供されますか? バックポートされた修正を監視するために、どのブランチまたはリポジトリを監視すべきでしょうか？ NXPは、継続的な脆弱性マネジメントプロセスを必要とする製品に対してどのようなアップグレード頻度を推奨していますか? 私たちの目標は、実際の出荷イメージに対して、再現性があり、証拠に基づいたSBOMおよびCVE評価プロセスを確立することです。公式ドキュメント、サポートツール、推奨手順の参考文献があればぜひ教えていただけると助かります。 よろしくお願いします。 Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 こんにちは、 @Chavira さん。 Debianディストリビューションのサポート状況についてのご説明ありがとうございます。 Debianとの統合自体は、概念実証として提供されていることを理解しています。しかし、残された疑問は基盤となるBSPコンポーネントに関するものであり、私たちが知る限り、Yocto BSPリリースで消費されているリポジトリやブランチと同じです。 - Linux-IMX(LF-6.12.20-2.0.0) - uboot-IMX(LF-6.12.20-2.0.0) - IMX-ATF - IMX-optee-OS - NXP提供のファームウェアバイナリ(DDR、HDMI、VPU、ワイヤレス) どのビルドシステムやルートファイルシステムが使われているかに関わらず、確認していただけますか: 1. これらのコンポーネントのセキュリティ修正はlf-*リリースブランチを通じて提供されるのか、またYocto BSPリリースノートに公開されている修正CVE情報は、これらのコンポーネントのCVE修復状況の権威ある情報源なのか? 2. lf-6.12.20世代に関して、これらのコンポーネントに適用されるセキュリティ修正を得るために、どの後続のlf-*リリースやブランチを監視すべきか? 3. lf-6.12.20 BSPコンポーネント生成のメンテナンス期間はどのくらいで、継続的な脆弱性マネジメントプロセスを維持する必要がある製品に対してNXPはどのアップグレードの頻度を推奨していますか? [[ ## completed ##]] 私たちはNXPにDebianベースのイメージのサポートや検証を求めているわけではありません。NXP BSPコンポーネント自体の公式なセキュリティ修正情報源を特定するSO、それをCAN追跡・適用できます。 よろしくお願いします。 Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 こんにちは、 @Leo_dev さん。 NXPサポートまでご連絡いただきありがとうございます。 残念ながら、DebianはNXPによって概念実証ディストリビューションと見なされており、YoctoベースのBSPリリースと同じレベルのサポート、検証、長期的なメンテナンスを受けていません。 実際、起動時には、ソフトウェアが機能やサポートの保証なしに提供されていることを示す免責事項が表示されます。その結果、Debian上で直面する問題は、Yoctoベースのイメージで再現される問題と同じレベルの調査や検証を受けられない場合があります。 本番開発や完全にサポートされたユースケースには、NXPが提供するYocto BSPの使用を推奨します。 私たちの公開されているすべてのソースコードはGitHub上でホストされており、以下の組織を通じてアクセスCANです。 https://github.com/nxp-imx よろしくお願いします、 チャビラ Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 こんにちは、 @Leo_dev さん。 1. はい。NXP BSPコンポーネントのセキュリティ修正は通常、公式のlf-releaseブランチを通じて提供されます。i.MX Linux BSPリリースノート(RN00210)および関連するマニフェスト/変更ログは、統合修正やCVE修復状況の追跡における主要なNXP参照資料です 2. LF6.12.20世代については、LF6.12.34_2.1.0などの後続のBSPリリースを監視します。LF6.12.49_2.2.0、LF6.18.2_1.0.0、およびそれ以降のリリースでは、セキュリティや保守の修正がこれらのブランチに引き継がれます。 3.継続的な脆弱性管理が必要な製品に対して、NXPの推奨方法は、新しいBSPのメンテナンスや四半期ごとのリリースを定期的に追跡・評価し、セキュリティアップデートやバグ修正を取得することです

CGM-RD (UM12423) — NHS2634 が割り込みピンをアサートせず、NHS2x34_Init() が永久にハングアップする NHS2x34_Init() は、NHS2634 の割り込みピンがハイになるのを無期限に待機してハングアップします。これがハードウェアの問題なのか、電源供給シーケンスの問題なのか、それともファームウェアの設定の問題なのかを判断するのにご協力をお願いします。 イベント情報の順序: 1. NHS2634_HOSTIF_InitSpiAndInterrupt() が実行され、成功を返します。 2. NHS2x34_PMC_ResetAFE() が呼び出されます。これは、PMC制御レジスタへのSPI書き込み（AFEリセットビットの設定）を実行します。成功（ステータス＝0）を返します。 3. その後、コードは次のループで待機し、チップがSPIコマンドを受け入れる準備ができたら割り込みピンをハイにするのを待ちます。このループは決して終了しない。 while (!NHS2634_HOSTIF_GetInterruptPinLevel()) { } 既に実行された診断： 1. SEGGER RTT ログにより、ループが実際に回転していること (ライブ ポーリング カウンターが継続的に数千万まで増加していること) が確認され、フリーズしたりクラッシュしたりしていないことが確認されました。CPUは動作しており、ピンを積極的に再チェックしています。 2. デバッガ（J-Link/GDB）を接続し、ループの途中で2回停止しました。プログラムカウンタはNHS2634_HOSTIF_GetInterruptPinLevel()の中にあり、GPIO_PinRead()を2回呼び出しており、アクティブポーリングと一致している。 3. PMC制御レジスタに書き込みを行った直後に、その内容を読み戻してください。リセットビットと書き込み保護バイトを反映したゼロでないパターンを期待していましたが、返0x00000000されました。 4. 生のSPIループバックテストを実行しました(MOSIからMISOへのショートをセンサーコネクタに直接接続し、NHS2634モジュールを完全に切り離しました)。送信したバイトのエコーではなく、特徴的なテストパターンに対して0x00000000が返ってきた。 5. 上記の手順をNHS2634モジュールを完全に取り外した状態で繰り返した。結果はコネクテッド時と全く同じでした。 私が明らかにしようとしていること： 私はNXPが提供する公式SDKを使っており、ドライバーコードは変更していません。これがハードウェアの問題なのか、電源供給シーケンスの問題なのか、それとも私の側のファームウェア設定の問題なのか、また、これが私のユニット固有のハードウェア障害のように見えるのかどうかを判断する必要があります。 次にどこを調べれば良いか、何かアドバイスをいただけるとありがたいです。 MCU-リンク-PRO、 MCUXPRESSO-VSC、 血液グルコースモニター  @nxp 、 @nxp5 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) MCXA MCX C MCX N パッケージとIO|GPIO パワー Re: CGM-RD (UM12423) — NHS2634 never asserts INTERRUPT pin, NHS2x34_Init() hangs forever SPIループバックが0x00を読み取れなかったため、ホストマイクロコントローラのSPIペリフェラル/ GPIO ルーティング は 実際には データを 転送していません ホストピン の 多重接続 、クロック、GPIO初期化 を修正してください

CGM-RD (UM12423) — NHS2634 始终无法置位中断引脚，NHS2x34_Init() 函数无限期挂起 NHS2x34_Init() 无限期地挂起，等待 NHS2634 的中断引脚变为高电平。我希望有人能帮我确定这究竟是硬件问题、电源时序问题还是固件配置问题。 事件顺序： 1. NHS2634_HOSTIF_InitSpiAndInterrupt() 运行并返回成功。 2. 调用 NHS2x34_PMC_ResetAFE()。这将向 PMC 控制寄存器发出 SPI 写入操作（设置 AFE RESET 位）。它返回成功（状态 = 0）。 3. 然后，代码在以下循环中等待，期望芯片在准备好接受进一步的 SPI 命令时将其中断引脚置为高电平。这个循环永远不会结束。 while (!NHS2634_HOSTIF_GetInterruptPinLevel()) { } 诊断程序已运行： 1. 通过 SEGGER RTT 日志确认循环确实在旋转（实时轮询计数器持续递增至数千万），没有冻结或崩溃。CPU 已启动并正在主动重新检查引脚。 2. 连接调试器（J-Link/GDB），并在循环过程中两次停止。程序计数器位于 NHS2634_HOSTIF_GetInterruptPinLevel() 内部，两次调用 GPIO_PinRead()，这与主动轮询一致。 3. 写入 PMC 控制寄存器后立即将其读回。预期会收到一个非零模式，反映复位位加上刚刚发送的写保护字节，但返回的是 0x00000000。 4. 运行原始 SPI 回环测试（将传感器连接器上的 MOSI 和 MISO 直接短接，NHS2634 模块完全断开）。使用特殊测试模式时，仍然返回 0x00000000，而不是发送字节的回显。 5. 将 NHS2634 模块完全拔掉后，重复上述所有步骤。结果与连接时完全相同。 我想确定的是： 我使用的是NXP官方提供的SDK，没有修改驱动程序代码。我需要确定这是否是我的硬件问题、电源时序问题或固件配置问题，以及这是否像是我的设备特有的硬件故障。 非常感谢您能提供一些关于下一步该如何着手的指导。 MCU-LINK-PRO 、 MCUXPRESSO-VSC 、血糖监测仪 @nxp ， @nxp5 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） MCXA MCXC MCX N 代码包，软件包和 I/O|GPIO 电源 Re: CGM-RD (UM12423) — NHS2634 never asserts INTERRUPT pin, NHS2x34_Init() hangs forever 由于 SPI 回环读取 0x00 失败，因此主机微控制器的 SPI 外设/ GPIO 路由 实际上 并未 传输数据 。 任何 数据。修复主机引脚 复用 、时钟和 GPIO 初始化。

S32K358 eMIOS ISR 卡在 85°C 尊敬的恩智浦技术支持团队： 我们在 S32K358 上进行 85°C 左右的温度测试时遇到了问题。   在我们的应用中，我们使用了 6 个 eMIOS 通道，每个通道都配置为在 PWM 的两个边沿生成中断，频率为 200Hz。   在 85°C 时，MCU 有时会卡在某个 eMIOS 中断服务例程 (ISR) 中。ISR 无法退出，因为代码会通过读取 eMIOS 寄存器来检查中断标志，但该标志的值为 0（文件 Emios_Mcl_Ip_Irq.c）。 😞   如果( 0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32) eMIOS_S_FLAG_MASK ))   调试后我们发现，当问题出现时，包含 eMIOS 基地址的变量（ Emios_Ip_paxBase）为 NULL 。而当应用程序正常运行时，该指针有效，并且 eMIOS 寄存器也能被正确读取。 似乎在某些情况下，对 eMIOS 外设的引用在 ISR 执行期间会被损坏或清除。   您是否有任何关于可能存在的已知问题或根本原因的线索，例如堆栈溢出、内存损坏、并发访问、中断服务例程处理或温度相关行为？   顺祝商祺！ 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨，范恩 我目前使用的是 RTD 7.0.0 版本。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 你使用的是哪个版本的RTD？任何其他信息都将不胜感激。 此外，在 6.0.0 之前的 RTD 版本中，存在一个与函数作用域内静态变量的内存映射不正确相关的已知问题 (ARTD-159985)。 此问题描述了在 Emios_Mcl_Ip.c 中定义的变量 Emios_Ip_paxBase 存在的问题。Emios_Mcl_Ip_Irq.c 被赋予了不一致的初始化特性。更多详情请参阅软件版本说明。 BR，VaneB Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 能否提供一个能够重现所观察到的现象的简单应用程序？另外，能否确认一下您使用的是定制电路板还是评估电路板？ 另外，能否分享一下测试是如何进行的，以确认该问题是否在 85°C 时出现？ Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB ， 目前我正在使用一块带有 S32K358 的定制板，其中我使用以下 eMIOS_1 通道生成 200 Hz 的 PWM：ch3、ch9、ch11、ch12、ch13、ch19。代码是使用 Simulink 生成的。 我将定制电路板放入 85°C 的气候箱中一段时间后，观察到了卡顿现象。 我在使用 S32DS (3.6.7) 进行调试时我发现它卡在了 ISR(EMIOS1_1_IRQ) 中，所以我在入口/出口函数附近以及 Emios_Pwm_IrqHandler 和 Emios_Pwm_Ip_IrqHandler 函数中都添加了一些自定义计数器，以便检测代码的哪些部分正在执行。 经过一些测试，我发现，当它卡住时，内部…… static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { /* 检查 Emios 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) { /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK)))) { Emios_Pwm_Ip_IrqHandler(实例, 通道); } 别的 { /* 什么也不做 - 如果遇到虚假中断，立即返回 */ } } } if 条件： 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) 始终为 0，因为由于某种原因，Emios_Ip_paxBase[Instance] 指向 0。这意味着没有人清除中断标志，因此它进入了一个无法逃脱的循环。 以下是我用来检测此问题的代码： static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { // uint32_t s; // uint32_t c; // uint32_t s_flag; // uint32_t s_ovr; dbg_pwm_last_instance = 实例; dbg_pwm_last_channel = Channel; dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; dbg_emiosipirq_static_state1++; /* 如果 (实例 == 1) { 切换（通道） { 案例16： dbg_emiosipirq_static_cnt_ch16++; 休息; 案例17： dbg_emiosipirq_static_cnt_ch17++; 休息; 案例18： dbg_emiosipirq_static_cnt_ch18++; 休息; 案例19： dbg_emiosipirq_static_cnt_ch19++; 休息; 默认： dbg_emiosipirq_static_cnt_oth1++; 休息; } } 别的 { dbg_emiosipirq_static_cnt_oth2++; } */ /* Lettura reale dei registri vista dal codice */ /* s = Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; c = Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; s_flag = s & (uint32)eMIOS_S_FLAG_MASK; s_ovr = s & (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s = s; dbg_pwm_last_c = c; dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK; dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s_and_flag = s_flag; dbg_pwm_last_s_and_ovr = s_ovr; 如果 (s_flag != 0U) { dbg_pwm_s_flag_yes++; } 别的 { dbg_pwm_s_flag_no++; } 如果 (s_ovr != 0U) { dbg_pwm_s_ovr_yes++; } 别的 { dbg_pwm_s_ovr_no++; } 如果 ((s_flag == 0U) && (s_ovr != 0U)) { dbg_pwm_flag0_ovr1_count++; } 否则如果 ((s_flag != 0U) && (s_ovr != 0U)) { dbg_pwm_flag1_ovr1_count++; } 否则如果 ((s_flag != 0U) && (s_ovr == 0U)) { dbg_pwm_flag1_ovr0_count++; } 别的 { dbg_pwm_flag0_ovr0_count++; } */ /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) { dbg_emiosipirq_static_state2++; /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK)))) { dbg_emiosipirq_static_state3++; Emios_Pwm_Ip_IrqHandler(实例, 通道); } 别的 { dbg_emiosipirq_static_state4++; /* 什么也不做 - 如果遇到虚假中断，立即返回 */ } } 别的 { dbg_emiosipirq_static_state5++; //Emios_Pwm_Ip_IrqHandler(Instance, Channel); //Emios_Pwm_Ip_IrqHandler(1, 19); } } 以下是我存储 Emios_Ip_paxBase 应指向的地址的全局变量： dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; 我还添加了一些自定义代码，用于在运行时读取 NVIC 寄存器：附件中包含线程、通用寄存器、NVIC 寄存器和变量表达式、EMIOS 寄存器等文件，以及我进行的 6 次测试。 另外，我会在私信中提供我用来测试此行为的 S32DS 项目。 希望这些信息对大家有所帮助。如有任何其他疑问，请随时联系我。 BR， 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 非常感谢您提供这些信息。 由于代码似乎卡在了 EMIOS1_1_IRQ 中，根据您的配置，它对应于 eMIOS 1 通道 19，让我们尝试将分析范围缩小到这一特定部分。 为了简化调试并排除其他模块的任何干扰，请创建一个仅包含此 eMIOS 配置的最小测试项目。这将有助于我们找出问题所在，并更好地了解其根本原因。如需指导，您可以查看S32M27x/S32K3 – eMIOS 使用主题中提供的示例。 同样的行为是否仍然存在？另外，如果您有评估板，最好能在上面测试一下相同的代码。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨，范恩 我本周会尝试给你一个简单的项目来复现这种行为。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 我们的评估板主要设计用于室温环境，尚未经过极低或极高温度的测试或认证。 您仍然可以在室温范围之外使用评估板，但我们无法保证它们在这些条件下的性能。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB ， 我用简化的配置在我的定制板上测试了这个问题，该配置只包括六个 eMIOS1 通道。遗憾的是，在这种配置下我无法重现该错误。应用程序运行正常，不会卡在 EMIOS_1_IRQ 中。 目前，我正在研究将为我们定制板开发的完整项目加载到 EVB 上是否可行。在继续之前，我还想了解一下定制板和 EVB 之间的硬件差异是否可能导致任何意外行为，甚至损坏 EVB。 BR， 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB ， 经过多次尝试，我终于创建了一个 EVB 项目，该项目尽可能地重现了在我的定制板上运行的应用程序。具体来说，我将所有引脚的配置方式都与我的自定义项目中的配置方式相同。 然后我在 85°C 的条件下用我的定制板测试了这个项目，eMIOS ISR 问题仍然存在：应用程序继续卡住。 之后，我在相同的温度条件下，甚至在 90°C 以上，对 EVB 进行了完全相同的项目测试，但我无法重现该问题——EVB 继续正常运行，没有出现卡顿。 此时，您会建议采取哪些后续步骤来确定问题的根本原因并找到可能的解决方案？ 如果您需要我提供任何其他信息、测量数据或调试数据，请告诉我。 我附上了一个 ZIP 文件，其中包含完整的 EVB 项目以及我的定制板和 EVB 上的 K358 图片。 感谢您的支持。 BR 西蒙娜 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 由于该问题仅在您的定制板上出现，而未在 EVB 上出现，因此值得调查根本原因是否与硬件有关。 我建议您将您的硬件设计与 EVB 原理图进行比较，并查看 S32K3 硬件设计指南，以验证所有相关建议是否已正确实施。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB ，   我们已对硬件设计进行了审查，未发现明显的硬件问题。此外，由于硬件设计和运行条件不同，该电路板与 NXP EVB 不具有直接可比性。   如果客户发现定制板存在温度相关问题，如何才能从恩智浦半导体获得一对一的支持？   BR， 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB 我想就此话题稍作跟进，因为我们仍在调查此事，希望得到您的反馈。 具体来说，如果根本原因与 RAM 损坏有关（例如，越界写入或堆栈覆盖），您会建议在 S32K358 上检查哪些寄存器或诊断信息？ 是否有任何特定的故障状态寄存器、ECC/错误报告寄存器、MPU相关寄存器、堆栈监控功能或其他调试寄存器可以帮助识别在eMIOS ISR卡住之前是否发生了内存损坏？ 非常感谢您能就调试过程中最需要检查的寄存器提供一些指导。 感谢您的支持。 顺祝商祺！ 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 由于这似乎是您主板特有的硬件相关问题，而且我们无法重现该问题，因此很难通过此支持渠道准确诊断根本原因。我们建议您联系您的代理商或当地的恩智浦代表以获取更多帮助。

Flexioを特殊なSPIとして、同時に20ビットMOSI出力として動作させたい。 20個のチップDACを同時に制御する必要があるため、Flexioを特別なSPIとして使用してDACデバイスを制御したいと考えています。詳細は以下の通りです。 1つのcs、 1クリック、 20 MOSI、20ピンを使って、同時に20台のDACデバイスにDAC値を出力します。MCUEctrossのコードとプロジェクトを教えてもらえますか? ありがとうございます！ 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time この質問は難しいもので、誰も提案できないのでしょうか? 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 1、csプル低レベル 2、フレキシオは20チャネルを常に送信し、各チャネルは1ビットを送信し、1回送信は1シフトレジスタを使用します。 3、送信8回 8つのシフトレジスタすべてを使い、各チャンネルは8ビットを送信します。 4、ステップ2、3は1回のDMA送信です。DACのchipiは24ビットなので、各チャネルで24ビットデータを3回送信します。 5．CSを高く引く。 これでうまくいくのでしょうか? 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time 誰かいますか？ Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time 私が使用しているチップはmcxn947です。 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは、 @justdomyself 同様の実装としては、FlexIO QSPIのアプリケーションノートAN14175とMCUXpresso SDK内のFlexIO SPI DMA例を確認することをお勧めします。 AN14175例はFlexIOタイマーとシフターを使ってカスタムシリアルインターフェースを作成する方法を示しており、1クロックと複数のデータ出力で20のDACチャネルを同時に駆動するというあなたのニーズにより近いものです。 FlexIO SPI DMAのサンプルは、FlexIOの基本的なタイマー、シフター、およびDMA構成を理解する上でも役立ちます。 BR ハリー 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time AN14175のプロジェクトコードはどこにありますか？どこからダウンロードできますか？ 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time インポート中にエラーが発生しました。 justdomyself_0-1785394860116.png コンパイル中にエラーが発生しました。 justdomyself_1-1785394889652.png デバッグ中にエラーが発生しました。 justdomyself_2-1785394917545.png BOARD_PowerMode_ODを実行すると、デバッグ関数が上記の画像に示すエラーで即座にクラッシュします。 より新しい、動作するプロジェクトを提供していただけますか？ 私のソフトウェアバージョン：MCUXpresso IDE v25.6 [ビルド 136] [2025-06-27] 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは、 @justdomyself 検索 |NXP Semiconductors NXP公式ウェブサイトでAN14175を検索してください。 そして、関連ファイル:AN14175SWをクリックするとソフトウェアをダウンロードできます。 Harry_Zhang_0-1785384066285.png BR ハリー 回复： I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは、 @justdomyself AN14175対応のSDKバージョンをダウンロードできます。 BR ハリー