SDMA読み込みの問題: i.MX8MP プラットフォーム  i.MX8M Plus EVK、カーネル 6.12.49-lts-next-g42fbadd4b2e9-dirty WiFi/BTモジュール:AW-XM729、ドライバbtnxpuart 同じハードウェア/カーネルで、Yoctoイメージが2つ:imx-image-core(BTは動作)vs imx-image-multimedia(BTが失敗) 問題 マルチメディアイメージでは、 imx-sdma@30bd0000 がファームウェア準備完了を報告するのに約60秒かかります: [ 3.11] imx-sdma 30bd0000.dma-controller: sdmaまたはSDMAファームウェアが準備できていません! [ 60.40 ] IMX-SDMA 30bd0000.dma-controller: ファームウェアを発見。 BTNXPUARTは、SDMAが準備される前の~3〜7秒でBT UARTをプローブするため、UARTはDMAチャネルを取得できず、BTのタイムアウトHCI_Resetします。 imx-uart 30860000.serial: RX/TXのスレーブDMAに備えられません! Bluetooth: hci0: Opcode 0x0c03 failed : -110 動作中のコアイメージでは、BTプローブの前に約3.7秒でSDMAの準備が整います。問題はありません。 助けてください！ Re: SDMA Loading issue: i.MX8MP @Sanjiv_Mns様、 ご意見ありがとうございます。 imx-image-multimedia + IW623 をテストするための環境を構築します。 準備に少し時間がかかりますので、テスト結果をお待ちください。 ところで、AW-XM729にはAW-XM729-PURとAW-XM729-SURの2種類があるんですよね？ よろしくお願いします！ よろしくお願いいたします。 維東 Re: SDMA Loading issue: i.MX8MP @Sanjiv_Mns様、 何か進展はありましたか？ 使っているSDIOまたはPCIEインターフェースを教えてもらえますか? よろしくお願いします！ よろしくお願いいたします。 魏東 Re: SDMA Loading issue: i.MX8MP @Sanjiv_Mns様、 私はL6.12.49.2.2.0のYoctoソースをベースにimx-image-multimediaを構築し、i.mx8mp-evkで実行しています。 weidong_sun_0-1787287166486.pngweidong_sun_0-1787287166486.png weidong_sun_1-1787287192914.pngweidong_sun_1-1787287192914.png weidong_sun_2-1787287252963.pngweidong_sun_2-1787287252963.png 私が使っているIW623モジュールはAW-XM729-PURで、PCIEインターフェースを持つM.2モジュールです。 もしWiFiにSDIOインターフェースを使っているなら、dtbファイルはimx8mp-evk-usdhc1-m2.dtbであるべきです そして、以下を実行します。 # modprobe btnxpuart #hciconfig -a HCI0インターフェースがリストに記載されます。 [注] imx-image-multimediaのデフォルトドライバーはIW623をサポートしており、AW693ファームウェアを使用しています。 ありがとう！ よろしくお願いいたします。 維東

S32K328のGMAC RX割り込み 私はS32K328のGMACを使っていて、PCからパッケージを受け取るために割り込み方式を使いたいと思っています。しかし、いくつかの異なる現象が発見された。 1. 割り込みハンドラGMAC0_CH0_RX_IRQHandlerを呼び出し、通常通りパッケージを受信できます。 2. PCがパッケージを送信した後、何秒も通話GMAC0_CH0_RX_IRQHandler。 3. GMAC0_CH0_RX_IRQHandler電話できず、パッケージも届かない? その理由は一体何だろうか？どうすれば解決できるでしょうか？ Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 設定情報を共有していただきありがとうございます。EB tresosが手元にないため、提供いただいたファイルからGMACの設定を手動で確認しました。 あなたのEth_43_GMAC構成を、正常に動作するS32K358 GMAC 1G lwIP FreeRTOSリファレンスプロジェクトと比較しました。大きな違いの一つは、Egress FIFO構成です。あなたのプロジェクトでは、Egress FIFOバッファ長は128バイト、MTL Egressキューサイズは256バイトに設定されています。一方、リファレンスプロジェクトでは、Egress FIFOバッファ長は1536バイト、MTL Egressキューサイズは4096バイトです。   もしアプリケーションがフレームを送信したり、上位層が応答を送る場合、この小さなTX/Egress構成は標準的なイーサネットフレーム、特に1G RGMIIモードでは制限が多すぎる可能性があります。テストとして、以下の値を増やしてみてください。   - EthCtrlConfigEgressFifoBufLenByte を 1536 に変更 - EthCtrlConfigMTLEgressQueueSizeInBytes を 4096 に変更   RXパスの場合、RXバッファの長さ自体は1536バイトで、これは妥当な値に見えます。しかし、あなたのMTLイングレスキューのサイズは1536バイトですが、参照プロジェクトでは4096バイトを使用しています。したがって、別のテストとして、以下の値も増やしてみてください。   - EthCtrlConfigMTLIngressQueueSizeInBytes を 4096 に変更   さらに、デバッグのために、一時的に全受信モードを有効にしてください。現在の設定ではPKT_FILTER_RECV_ALLが無効になっていますが、参照プロジェクトでは有効になっています。これにより、MACフィルタリングを分析から除外することができます。   EthEnableCacheManagementなど、他にも違いがあります。 EthCtrlReleaseResourceAfterReception ですが、これは必ずしも間違っているわけではありません。   よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは： ユニキャストフレームとブロードキャストフレームの両方を試しましたが、各フレーム間の遅延は1秒で、十分遅いと思います。 現象は同じで、最初は RxStatsDropEvents は発生しませんが、数フレーム後に発生します。 私のEB構成は添付ファイルの通りです。ご都合の良い内容かどうかご確認いただけますでしょうか。 ありがとうございます。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 RxStatsDropEventsは、一部のフレームがGMACによって認識されているものの、RXパスのどこかでドロップされていることを示唆しています。これはRXリソースの可用性、RX FIFO/キュー処理、ディスクリプタ/バッファの可用性、パケットフィルタリング、または上位層の受信処理に関連している場合があります。   以下の点を確認してください。   1. PCから同じユニキャストフレームをゆっくりと送信してください。例えば、一度に1フレームずつ送信したり、フレーム間に大きな遅延を設けたりして、テストの前後の受信統計を比較してください。もしRxStatsDropEventsが増加しなくなった場合、その問題はRXバッファのリサイクル、プロセッシング時間、またはPCからのトラフィックのバーストに関連している可能性があります。   2. ブロードキャストフレームでテストを繰り返し、その後GMACドライバで設定されたMACアドレスに正確に割り当てられたユニキャストフレームでテストを繰り返してください。これにより、MACアドレスやフィルタリングの問題を除外することができます。   RGMIIクロックとペリフェラルの設定も必ず確認してください。参考までに、NXPコミュニティでGMACのS32K358例を公開しています: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K358-GMAC-1G-lwIP-FreeRTOS-S32DS-3-6-1-RTD600/ta-p/2355872     この例はS32K358向けでありS32K328用ではないため、S32K328ピン配置とクロック構成を確認せずに直接コピーしないでください。しかし、全体のクロック設定、Eth_43_GMAC設定、DCMRWFレジスタの回避策の参考として利用できます。   可能であれば、あなたのzip化プロジェクトも共有していただけますか?プロジェクトがなければ、ドロップが設定、RXリソース処理、キュールーティング、またはアプリケーションの受信経路によるものかを判断するのは困難です。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは： RTD関数のフレーム情報を読みEth_43_GMAC_GetRxStats、ドロップイベントがあるようです。 zyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.png RXフローはすべて以下のようにRTDによって処理され、私は変更していません。 GMAC0_CH0_RX_IRQHandler -> GMAC_RxIRQHandler -> Eth_43_GMAC_RxIrqCallback -> Eth_43_GMAC_Receive その理由は一体何だろうか？ありがとう。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 詳細を教えていただきありがとうございます。   また、このThreadに従ってピン/クロック/device_init()も確認してください: S32K358 - GMACクロック構成   スクリーンショットから判断すると、GMAC0割り込みベクタは、GMAC0_CH_0_RX_IRQHandlerを含むRTDハンドラに設定され、マッピングされているようです。このハンドラが時々入力され、フレームが受信されるため、基本的な割り込みルーティングは完全に間違っているわけではありません。   ただし、AUTOSAR Eth_43_GMACドライバーを使用する際は、低レベルIRQハンドラ上の受信フローも必ず確認してください。RX割り込みハンドラ自体は通常、完全なアプリケーションレベルの受信処理ではありません。アプリケーションや上位層は、例えばEth_43_GMAC_Receive()のように期待されるEth_43_GMAC受信APIフローを呼び出す必要があります。これにより、受信フレームがドライバから読み込まれ、設定済みのコールバックパスをさらに通過します。   以下の点をご確認ください。   1. Eth_43_GMAC_Receive()がRX割り込みイベント情報の後、またはアプリケーションデザインに応じてメイン/タスクコンテキストから定期的に呼び出されるかを確認してください。割り込みが発生したにもかかわらず、受信したフレームがRXバッファから消費されない場合、後続のフレームが期待どおりに受信されない可能性があります。   2. 受信されたユニキャストフレーム宛先MACアドレスがGMACドライバで設定されたMACアドレスと正確に一致しているか確認してください。デバッグの目的で、MACフィルタリングを理由に除外するために、一時的にReceive-all/promiscuousモードを有効にすることができます。   3. どのRXキュー/FIFOが使用されているか確認してください。スクリーンショットには、CH0、CH1、CH2のRX割り込みハンドラが表示されています。パケットフィルタやキュー構成がフレームを別のRXキューにルーティングする場合、アプリケーションは対応するFIFOインデックス付きの受信関数を呼び出し、そのキューを正しく処理しなければなりません。   4. RXバッファ/ディスクリプタが利用可能であることを確認してください。受信フレームが処理された後、ドライバはRXバッファを再利用または取得できる必要があります。受信バッファが枯渇した場合、最初のフレームは正しく受信される可能性がありますが、それ以降のフレームは遅延したり、失われたりする可能性があります。   5. キャッシュが有効になっている場合は、GMAC ディスクリプタと RX バッファがキャッシュ不可能なメモリ領域に配置されているか、必要なキャッシュメンテナンスが実行されていることを確認してください。そうしないと、CPUは古い記述子ステータスや古い受信データを認識する可能性があります。   6. フレームはPythonスクリプトからユニキャストフレームとして送信されるため、PCが期待される宛先MACアドレスでフレームを継続的に送信していることをWiresharkで確認してください。一部のフレームがアドレス解決を必要としたり、宛先に期待通り到達できない場合、PC側は再試行や遅延を導入し、MCU側での遅延RX割り込み動作のように見えることがあります。   参考までに、まずは改造されたS32K3イーサネット/lwIPの例と比較してみることをおすすめします。これにより、RGMII PHYインターフェース、クロック、MACアドレス、基本的なRXパスが動作しているか確認し、カスタムAUTOSAR Eth_43_GMAC割り込み受信実装に注力する前に確認できます。   それでも問題が解決する場合は、Eth_43_GMAC_Receive()が呼び出された場合、RX FIFO設定、MACアドレス/フィルター設定、失敗後のGMAC DMA/MTL/MACステータスレジスタなどのアプリケーションEth_43_GMAC受信部分を共有してください。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは： 1.私はRGMIIを使用しています 2. 私はRTD 6.0.0を使用しています。 3. 私はEth_43_GMACドライバを使用しています。 4. 中断とは次のようなものです。 zyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.png 5. Pythonスクリプトを使ってユニキャストフレームを送信します。 私が送信するパッケージはすべて同じで、GMAC0_CH0_RX_IRQHandler は RTD からのもので、上の図のように最も下位のハンドラです。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 あなたのセットアップについてもう少し詳しく教えていただけますか?   1. S32K328で使っているMAC/PHYインターフェースは、例えばMII、RMII、RGMIIのいずれかです。 2. 使用しているS32K3 RTDのバージョンは何ですか？ 3. AUTOSAR MCAL Eth_43_GMACドライバーを使っていますか?それとも低レベルのGMAC IPドライバーを使っていますか? 4. 関連する割り込み設定とGMAC0_CH0_RX_IRQHandlerの実装について教えていただけますか? 5. PCから送信されるフレームの種類は、ping/ICMP、UDP、生のイーサネットフレーム、ブロードキャストフレームやユニキャストフレームなどです。   参考テストとして、まずは適応したS32K3イーサネット/lwIPの例を使ってこの挙動を再現してみることもおすすめします。これにより、基本的なGMAC/PHY/クロック/設定の問題と、アプリケーション固有の割り込みやRXバッファの処理問題を区別するのに役立ちます。     症状についてですが、時折RX割り込みが呼び出されフレームが正しく受信できれば、基本的なRXパスは少なくとも部分的に動作している可能性が高いです。しかし、この一貫性のない動作は、以下のいずれかの原因による可能性があります。   - RXバッファまたはディスクリプタ処理:受信フレームが処理された後、RXバッファ/ディスクリプタはドライバ/DMAに戻されなければなりません。これが正しく行われないと、RXバッファが使用できなくなり、その後のRX割り込みが停止したり、不安定になったりする可能性があります。   - 割り込み処理:RX割り込みが正しいGMACチャネルに設定されており、期待されるドライバー割り込みハンドラ/状態クリアリングフローが使用されていることを確認してください。割り込み状態が正しくクリアされていない場合、以下のRXイベント情報が期待通りに報告されないことがあります。   - キャッシュ/メモリの一貫性: キャッシュが有効になっている場合は、GMAC ディスクリプタと RX バッファが適切なキャッシュ不可のメモリ領域に配置されているか、必要なキャッシュメンテナンスが実行されていることを確認してください。そうしないと、CPUは古い記述子ステータスや古い受信データを認識する可能性があります。   - パケットフィルタリング/MACアドレス: デバッグ目的で、一時的に受信全モード/プロミスキャスモードを有効にしてみてください。これは、フレームがMACアドレスフィルタ、VLANフィルタ、またはその他のパケットフィルタ設定によって拒否されたかどうかを確認するのに役立ちます。   - フレームの種類と PC の動作: PC が ping などの IP トラフィックを送信する場合、ICMP トラフィックが送信される前に、最初のフレームは ARP 要求/応答である可能性があります。ARPの解像度が失敗したり、一部のフレームがフィルタリング・ドロップされた場合、PCがARPを再送信したり、アプリケーションが後で再試行したりして割り込みが数秒遅れているように見えることがあります。   - PHYリンクとクロック:PHYリンクが稼働していること、選択したMII/RMII/RGMIIインターフェースに必要な入力クロックが安定していることも確認してください。   上記の構成の詳細と、可能であれば、障害発生後のGMAC DMA/MTL/MACステータスレジスタを共有してください。これにより、問題が割り込み設定、RXディスクリプタ/バッファ処理、パケットフィルタリング、外部PHY/インターフェース設定に関連しているかどうかを特定するのに役立ちます。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは： 以下のように、ご指示いただいたとおりに設定しました。 zyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.png zyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.png zyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.png zyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.png EthCtrlReleaseResourceAfterReceptionは外部データバッファを使用した場合にのみ適用されるため、変更できません。 zyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.png これらを変更した後も結果は同じで、RxStatsDropEvents が表示されました。 zyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.png 変更された設定ファイルは添付ファイルのようなものです。 もう少しアドバイスをいただけますか?ありがとう。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 最新情報のご提供ありがとうございます。あなたのファイルを再度確認しましたが、不審な点は何も見つかりませんでした。FIFO/キューのリソースを増やしても動作が変わらない場合は、設定パラメータをむやみに変更し続けるべきではありません。次のステップは、実際にRxStatsDropEventsとしてカウントされるフレームを特定することです。ドロップカウンターが増加するのは、Pythonのユニキャストフレームが送信された時だけなのか、それともPythonのトラフィックが実行されていない時にも増加するのかを確認してください。PC側のバックグラウンドトラフィックやフィルタリングされたフレームも受信統計に影響を与える可能性があるためです。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 すみません、あなたがEBに加入していないことを忘れていました。 添付ファイルは、修正後に生成されたファイルです。 Re: GMAC RX interrupt of S32K328 こんにちは： 私のテストでは、ブロードキャストフレームもユニキャストフレームもドロップでき、pヘノメノンは同じで、PCは私のコントロール外のフレームを送りません。 フレームを送信すると、RTD 関数 Gmac_Ip_ReadFrame が以下の分岐に入るという特別な現象が時々発生します。 zyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.png それは、(((Bd->Des3 & GMAC_RDES3_OWN_MASK) != 0U) だからです。 zyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.png 関数コールフローは以下の通りで、すべてRTDドライバーに属します: zyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.png 現時点では、Eth_43_GMAC_Receive は GMAC バッファのデータを読み取りません。 しばらくするとGMACのFIFOが満タンになると、後から来たフレームが落ちます。 私の分析は理にかなっていると思いますか？ もしそうなら、なぜ(((Bd->Des3 & GMAC_RDES3_OWN_MASK) != 0U) が起こったのでしょうか?その理由は一体何だろうか？ ありがとう。 Re: GMAC RX interrupt of S32K328 こんにちは： 問題はキャッシュが原因です。プロジェクトからマクロ D_CACHE_ENABLE を削除すると、すべて正常に戻ります。 それはキャッシュコヒーレンシの問題を意味しますか？ しかし、D_CACHE_ENABLE を追加して下のチェックボックスをオンにすると、問題も発生しました。 zyt_2-1787215536381.pngzyt_2-1787215536381.pngzyt_2-1787215536381.pngzyt_2-1787215536381.png RTDの可変領域設定は一切変更していませんし、 RTDドライバーを確認したところ、GMAC_0_Rx/TXRing_0_Desc/DataBufferはno_cacheリージョンにありますが、Gmac_apxStateのようにキャッシュされているmcal_bssに入っていません。そんなに妥当なのか? zyt_4-1787215940789.pngzyt_4-1787215940789.pngzyt_4-1787215940789.pngzyt_4-1787215940789.png では、D_CACHE_ENABLEを加えた上でこの問題をどう解決すればいいのでしょうか? ありがとうございます。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 詳細なデバッグ情報をありがとうございました。あなたの指摘は参考になりますが、「OWN」の部分については、私は少し違った解釈をします。   RDES3.OWNが設定されている場合、RXディスクリプタはCPUではなくDMAによって所有されます。したがって、Gmac_Ip_ReadFrame()は現在の記述子がまだ完成してソフトウェアに戻されていないため、正しくGMAC_STATUS_RX_QUEUE_EMPTYを報告します。OWN = 1のRXディスクリプタは通常DMAに利用可能であるため、この条件だけでRXリングがブロックされていることやGMACのFIFOが満杯であることを示すわけではありません。   重要な疑問は、RxCurrentDescがまだDMAによって所有されているディスクリプタを指しているにもかかわらず、なぜRX割り込みコールバックが実行されるのかということである。割り込みは別のRX/DMAステータス条件によって引き起こされた場合や、完了した記述子が現在のソフトウェア記述子ポインタと一致しない可能性があります。   生成されたコードは、GMAC RX ディスクリプタと RX データバッファをキャッシュ不可能な MemMap セクションに配置します。しかし、共有プロジェクトにはリンカーマップファイルが見当たらないため、このセクションが最終実行ファイル内のキャッシュできないメモリ領域に実際にマッピングされているかどうか確認できません。   ビルドで生成されたリンカーマップファイルを共有してもらえますか?特に、以下の最終住所とセクションを確認したいと思います。   - GMAC_0_RxRing_0_DescBuffer - GMAC_0_RxRing_0_DataBuffer - GMAC_0_TxRing_0_DescBuffer - GMAC_0_TxRing_0_DataBuffer   また、GMAC_STATUS_RX_QUEUE_EMPTY が、RX 割り込み後の最初の Gmac_Ip_ReadFrame() 呼び出し時に発生するのか、それとも 1 つ以上のフレームが正常に読み取られた後にのみ発生するのかを確認してください。OWNビットが1に設定されている場合、それは単に受信ループの通常の終了を示している可能性があり、次のディスクリプタは既にDMAによって所有されており、別のフレームを待っている状態です。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 最新情報のご提供ありがとうございます。はい、D_CACHE_ENABLEを削除すると問題が解消されるという事実は、キャッシュの一貫性またはメモリ領域の設定に問題があることを強く示唆しています。   しかし、Gmac_apxState自体は通常、キャッシュ不可能なメモリに配置する必要はありません。CPU側のドライバの状態とポインタを含み、GMAC DMAから直接アクセスされることはありません。CPUとGMAC DMAの間で共有される重要なオブジェクトは、ハードウェア記述子リングとRX/TXデータバッファである。   以前共有された生成ファイルを確認しました。Gmac_Ip_Cfg.h では、生成された設定には以下が含まれていました。   #define GMAC_HAS_CACHE_MANAGEMENT (STD_OFF)   同時に、Gmac_Ip_Cfg.cGMACのRX/TX記述子とデータバッファをNO_CACHEABLE MemMapセクションに配置します。したがって、生成される構成は、これらのオブジェクトが本当にキャッシュできないメモリ領域にマッピングされることに依存しており、GMACドライバーによる明示的なキャッシュ保守に依存していないようです。   EthEnableCacheManagementを有効にした後、RTD構成全体を再生成し、クリーンビルドを実行してください。次に、Gmac_Ip_Cfg.h 内の GMAC_HAS_CACHE_MANAGEMENT の値を確認してください。実際にコンパイルされるファイル。STD_OFFのままの場合、生成されたビルドでは低レベルのGMACキャッシュメンテナンスが有効になっていません。   リンカーマップファイルと、関連するリンカー/MPUメモリ領域の設定も共有してください。以下の最終セクションとメモリ属性を検証する必要があります。   - GMAC_0_RxRing_0_DescBuffer - GMAC_0_RxRing_0_DataBuffer - GMAC_0_TxRing_0_DescBuffer - GMAC_0_TxRing_0_DataBuffer   生成されたソースコードはこれらのオブジェクトをキャッシュ不可能なセクションに配置しますが、リンカースクリプトとMPU構成もそのセクションを真にキャッシュ不可能な領域にマッピングする必要があります。そうしないと、DMAがRAM内の記述子を更新した後でも、CPUは古いキャッシュされた記述子値（例えばOWN = 1）を読み取ってしまう可能性があります。   現時点では、Gmac_apxStateをキャッシュ不可能なメモリに移動することはお勧めしません。最初のステップは、すべてのDMA共有ディスクリプタとバッファが正しい非キャッシュ可能なMPU領域に配置されているか、あるいはコンパイル済みドライバ構成でGMACキャッシュ管理が本当に有効であるかを確認することです。 よろしくお願いいたします。 パベル

S32K358:アプリケーションを直接フラッシュした際、電源オンリセット後にCore 0およびCore 2が実行されません  S32K358デュアルコアアプリケーション(Core 0およびCore 2)に問題が発生しています 電源オン時のリセット時に。  Core 0およびCore 2のアプリケーションコードを直接フラッシュすると、アプリケーションは正常に実行され、すべての機能が期待通りに動作します。 しかし、 電源オンリセット(POR) を実行した後、制御は コア0に到達しますが、アプリケーションは期待通りに実行できず、コア2は実行されていません。 この問題は、ブートローダーなしでアプリケーションを直接起動した場合、POR後に一貫して再現可能です。 対照的に、 アプリケーションがブートローダー経由で起動 されると、Core 0とCore 2の両方が正しく実行され続け、その後のPOR後も同様に動作します。 したがって、この問題は POR後の直接アプリケーション起動 特定のものであり、ブートローダーを通じてアプリケーションを入力する際には観察されません。 Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire こんにちは、@ Julián_AragónM さん、 現在、s32k358カスタムボードを使用していますが、POR後に制御がcore0に渡るものの、そこで停止してしまいます。これはアプリケーションを直接フラッシュしたときに起こります。 コア0からコア2を有効化します。 直接フラッシュ書き込みを行う際、CM7_0_VTOR_ADDRとCM7_2_VTOR_ADDRの両方が正しく設定されていますか？- はい、初めてアプリケーションをフラッシュしたときは両方のコアは動作しますが、問題はPORの後だけです。 あなたのリファレンスプロジェクトと比較したところ、System.cで唯一の違いが見られますファイル /* サイズ:リンカーシンボルからの情報インポート、タイプ:ノーマル、インナーキャッシュポリシー:インナーライトバック、書き込み・読み込み割り当て、アウトドアキャッシュポリシー:アウトライトバック、書き込み・読み込み割り当て、共有可能:いいえ、特権アクセス:RW、非特権アクセス:RW */  #if (defined(S32K396) || defined(S32K394)) & defined(MULTIPLE_IMAGE) rasr[6]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1); #else /* サブリージョン7と8*を無効にしてください rasr[6]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1)|(1<<15)|(1<<14); #endif Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire こんにちは、 @Indhumathi さん。 これはNXPのEVB S32K358ですか?それともカスタムデザインですか? この問題についてもう少し情報を教えていただけますか?「期待通りにアプリケーションを実行しない」とはどういう意味ですか?MCUがリセットされているのか、それともSWのどこかで閉じ込められているのでしょうか? 直接フラッシュ書き込みを行う際、CM7_0_VTOR_ADDRとCM7_2_VTOR_ADDRの両方が正しく設定されていますか？ 起動時のIVTマーカー(CM7_2_ENABLE=1)でCM7_2を有効にしていますか?それともSW(MCU/電源ドライバー)で有効化していますか? コア0からコア2を始めるシンプルなマルチコアプロジェクトがあります。リファレンスとして使って設定を点検・比較できるかもしれません。S32K358マルチコアはCM7_0からCM7_2を開始します。 よろしくお願いします、 ジュリアン Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire こんにちは、 @Julián_AragónM さん、 POR後もコア0は動作していますが、コア2に切り替わりません。 問題解決のためにサポートしていただけませんか? Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire こんにちは、 @Indhumathi さん。 あなたが共有してくれたsystem.cのセクションはS32K358には関係ありませんが、S32K396には関係があります。おそらく、S32K358のMPU構成を共有したかったのだと思います。 POR後もコア0は動作していますが、コア2に切り替わりません。 プロジェクトのプリプロセッサ記号を調べてもらえますか?マルチコアプロジェクトでは、 MULTIPLE_COREマクロを定義する必要があります。単一のELFプロジェクトでない場合は、 MULTIPLE_IMAGEマクロも必要です。単一のELFプロジェクトの場合は不要です。 MULTIPLE_IMAGEが設定されていない場合、デバッガーが接続されている状態ではプロジェクトは正常に動作しますが、デバッガーが接続されていない状態ではハードフォルトが発生します。これは、起動コードがCore 2のRAM上でECC初期化を実行しないためです。 Julin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.png Core 2を有効にするためにMCU/Powerドライバーを使っていると推測します。HLD(MCAL)を使っていますか、それともLLD(IP)を使っていますか? Core 2にデバッガーを接続しようとした場合、Coreが初期化段階で停止しているのか、それともデバッガーが接続できないのかを確認できますか？ 最後に、問題が再現できるような簡単なテストプロジェクト、または設定ファイルとルーチンを提供していただけますか？ よろしくお願いします、 ジュリアン Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire こんにちは、 @Julián_AragónM さん、 最後に、問題が再現できる簡単なテストプロジェクト、または設定ファイルとルーチンを提供していただけますか？ ---参考までに、デュアルコアテストプロジェクトを添付しました。 Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire 当初、コア0とコア2はどちらも正常に機能していました。しかし、POR（術後回復）後は、その挙動は一貫性を欠くようになる。場合によってはコア2がフリーズし、また別の場合にはコア0がフリーズする。両方のコアが同時に動作している場合もある。 この問題は2つのコア間の共有メモリアクセスに関連しているようです。

SDMA Loading issue: i.MX8MP Platform  i.MX8M Plus EVK, kernel 6.12.49-lts-next-g42fbadd4b2e9-dirty WiFi/BT module: AW-XM729, driver btnxpuart Same hardware/kernel, two Yocto images: imx-image-core (BT works) vs imx-image-multimedia (BT fails) Issue On the multimedia image, imx-sdma@30bd0000 takes ~60s to report firmware ready: [ 3.11] imx-sdma 30bd0000.dma-controller: sdma or sdma firmware not ready! [ 60.40] imx-sdma 30bd0000.dma-controller: firmware found. btnxpuart probes the BT UART at ~3–7s — before SDMA is ready — so the UART can't get DMA channels, and BT's HCI_Reset times out: imx-uart 30860000.serial: We cannot prepare for the RX/TX slave dma! Bluetooth: hci0: Opcode 0x0c03 failed: -110 On the working core image, SDMA is ready by ~3.7s, before BT probes — no issue. Please Help here! Re: SDMA Loading issue: i.MX8MP Dear @Sanjiv_Mns , Thanks for your feedback. I will setup environment to test imx-image-multimeadia + IW623. I need some time to prepare it, please wait for my test result. By the way, AW-XM729 has 2 kinds of types, AW-XM729-PUR or AW-XM729-SUR? Thanks! Regards, Weidong Re: SDMA Loading issue: i.MX8MP Dear @Sanjiv_Mns , Any update ? Could you tell me SDIO or PCIE interface you are using? Thanks! Regards, weidong Re: SDMA Loading issue: i.MX8MP Dear @Sanjiv_Mns , I built imx-image-multimedia based on L6.12.49.2.2.0 yocto source, run it on i.mx8mp-evk. weidong_sun_0-1787287166486.pngweidong_sun_0-1787287166486.png weidong_sun_1-1787287192914.pngweidong_sun_1-1787287192914.png weidong_sun_2-1787287252963.pngweidong_sun_2-1787287252963.png The IW623 module I am using is AW-XM729-PUR, which is M.2 module with PCIE interface. If you are using SDIO interface for WIFI, the dtb file should be imx8mp-evk-usdhc1-m2.dtb then run: # modprobe btnxpuart #hciconfig -a hci0 interface will be listed. [Note] Default driver in imx-image-multimedia supports IW623, It uses AW693 firmware. Thanks! Regards, Weidong

S32K358：直接刷写应用程序后，上电复位后核心 0 和核心 2 无法执行 我们发现了一个问题…… S32K358 双核应用（Core 0 和 Core 2） 上电复位期间。 当 Core 0 和 Core 2 应用程序代码直接刷入，应用程序成功执行，所有功能均按预期运行。 然而，在执行 上电复位 (POR) 后，控制权转移到核心 0，但未能按预期执行应用程序，核心 2 甚至没有执行。 在 POR 之后，当应用程序直接启动而没有引导加载程序时，该问题始终可以重现。 相反，当 应用程序通过引导加载程序启动，Core 0 和 Core 2 都能继续正确执行，包括在后续的 POR 之后。 因此，这个问题是特定于……的。 POR后直接启动应用程序 当通过引导加载程序进入应用程序时，则不会观察到此现象。 Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire 你好 @ Julián_AragónM ， 目前我正在使用 s32k358 定制板，POR 后控制流向 core0，但卡住了。这种情况发生在我们直接刷写应用程序时。 从核心 0 启用核心 2。 直接刷写固件时，CM7_0_VTOR_ADDR 和 CM7_2_VTOR_ADDR 是否都配置正确？- 是的，因为第一次刷入应用程序时两个核心都能正常工作，但问题只在 POR 之后出现。 我对比了你的参考项目，唯一不同之处在于 system.c 文件。文件 /* 大小：从链接器符号导入信息，类型：普通，内部缓存策略：内部写回，读写分配，外部缓存策略：外部写回，读写分配，可共享：否，特权访问：读写，非特权访问：读写 */ #if (defined(S32K396) || defined(S32K394)) && defined(MULTIPLE_IMAGE) rasr[6]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1); ＃别的 /* 禁用子区域 7 和 8 */ rasr[6]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1)|(1<<15)|(1<<14); #endif Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire 你好@Indhumathi ， 这是S32K358 NXP EVB芯片，还是定制设计？ 您能否提供更多关于此问题的信息？“未能按预期执行应用程序”是什么意思？MCU是在RESET，还是卡在软件的某个地方了？ 直接刷写固件时，CM7_0_VTOR_ADDR 和 CM7_2_VTOR_ADDR 是否都配置正确？ 您是通过启动 IVT 标记 (CM7_2_ENABLE = 1) 启用 CM7_2，还是通过软件 (MCU/电源驱动程序) 启用 CM7_2？ 有一个简单的多核项目，它从核心 0 开始启动核心 2，或许你可以把它作为参考，检查/比较一下配置？S32K358 多核从 CM7_0 启动 CM7_2 。 此致， 朱利安 Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire 你好@Julián_AragónM ， 即使在 POR 之后，核心 0 仍然可以工作，但它不会跳转到核心 2。 请您协助我们解决这个问题。 Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire 你好@Indhumathi ， 你分享的 system.c 部分与 S32K358 无关，但与 S32K396 有关，我假设你原本想分享的是 S32K358 的 MPU 配置。 即使在 POR 之后，核心 0 仍然可以工作，但它不会跳转到核心 2。 你能检查一下项目的预处理器符号吗？多核项目需要定义MULTIPLE_CORE宏。如果不是单个 ELF 项目，则还需要MULTIPLE_IMAGE宏；如果是单个 ELF 项目则不需要。 如果未设置MULTIPLE_IMAGE ，则附加调试器时项目运行正常，但未附加调试器时项目会进入 Hardfault 状态。这是因为启动代码不会对 Core 2 的 RAM 执行 ECC 初始化： Julin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.png 我假设您使用的是 MCU/Power 驱动程序来启用 Core 2。您使用的是 HLD(MCAL) 还是 LLD(IP)？ 如果尝试将调试器连接到 Core 2，您能否看到 Core 是否卡在初始化阶段，还是调试器根本无法连接？ 最后，您能否提供一个简单的测试项目或配置文件以及相应的测试流程，以便重现该问题？ 此致， 朱利安 Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire 你好@Julián_AragónM ， 最后，您能否提供一个简单的测试项目或配置文件以及相应的程序，以便重现该问题？---请查看附件中的双核测试项目以供参考。 Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire 最初，Core 0 和 Core 2 都运行正常。然而，在 POR 之后，这种行为变得不稳定。在某些情况下，核心 2 会卡住；而在另一些情况下，核心 0 会卡住。有时两个核心都在工作。 这个问题似乎与两个核心之间的共享内存访问有关。

S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Directly We are observing an issue with the S32K358 dual-core application (Core 0 and Core 2) during power-on reset. When the Core 0 and Core 2 application code is flashed directly, the application executes successfully, and all functionalities operate as expected. However, after performing a Power-On Reset (POR), control comes to Core 0 but fail to execute the application as expected and core 2 not even executed. The issue is consistently reproducible following a POR when the application is started directly without the bootloader. In contrast, when the application is launched through the bootloader, both Core 0 and Core 2 continue to execute correctly, including after subsequent PORs. The issue is therefore specific to the direct application startup after POR and is not observed when the application is entered through the bootloader. Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire Hello @Julián_AragónM, Currently i am working with s32k358 custom board, After POR control is coming to core0 but it got stuck. This is happening when we flash application directly.   Enabling the core 2 from core 0. Are both CM7_0_VTOR_ADDR & CM7_2_VTOR_ADDR correctly configured when flashing directly?    -  Yes, because first time flashing the application both core works but the issue is only after POR. I compared with your reference project only difference i can see in system.c file /* Size: import information from linker symbol, Type: Normal, Inner Cache Policy: Inner write-back, write and read allocate, Outer Cache Policy: Outer write-back, write and read allocate, Shareable: No, Privileged Access:RW, Unprivileged Access:RW */  #if (defined(S32K396) || defined(S32K394)) && defined(MULTIPLE_IMAGE)  rasr[6]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1);  #else /* Disable subregion 7 & 8*/ rasr[6]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1)|(1<<15)|(1<<14);  #endif Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire Hello @Indhumathi, Is this S32K358 NXP EVB, or is this a custom design? Could you share a bit more information regarding this issue? What does "fail to execute the application as expected" mean? Is the MCU resetting, or maybe stuck in SW somewhere?  Are both CM7_0_VTOR_ADDR & CM7_2_VTOR_ADDR correctly configured when flashing directly?  Are you enabling CM7_2 through startup IVT marker (CM7_2_ENABLE = 1) or through SW (Mcu/Power driver)? There is a simple multicore project, which starts core 2 from core 0, maybe you can use it as reference and inspect/compare configuration? S32K358 Multicore Start CM7_2 from CM7_0. Best regards, Julián Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire Hello @Julián_AragónM, Core 0 is working even after POR, but it's not jumping to core 2. Could you please support us to fix the issue. Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire Hello @Indhumathi, The section from system.c you've shared is not relevant for S32K358, but for S32K396, I assume you meant to share S32K358's MPU configuration instead. Core 0 is working even after POR, but it's not jumping to core 2. Can you check project's preprocessor symbols? multi-core projects require MULTIPLE_CORE macro defined. If not a single ELF project, MULTIPLE_IMAGE macro is also required; If single-ELF it is not necessary. If MULTIPLE_IMAGE is not set, project runs fine with a debugger attached but enters Hardfault without the debugger. This is because the startup code will not perform ECC initialization on Core 2's RAM: Julin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.pngJulin_AragnM_0-1787172984643.png I assume you are using Mcu/Power driver to enable Core 2. Are you using HLD(MCAL) or LLD(IP)?   If you try to attach a debugger to Core 2, are you able to see if core is stuck at initialization, or is the debugger unable to connect?  Lastly, are you able to provide a simple test project or configuration files + routine, where the issue is reproducible?  Best regards, Julián Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire Hello @Julián_AragónM, Lastly, are you able to provide a simple test project or configuration files + routine, where the issue is reproducible?   ---   Kindly find the attached test dual core project for reference. Re: S32K358: Core 0 and Core 2 Fail to Execute After Power-On Reset When Application Is Flashed Dire Initially, both Core 0 and Core 2 were functioning successfully. However, after POR, the behavior becomes inconsistent. In some instances, Core 2 gets stuck, while in others, Core 0 gets stuck.  sometimes both cores are working. This issue appears to be related to the shared memory access between the two cores.

16MHz 外置晶振在 S32K314HMS 定制板上无法工作 您好， 我遇到一个问题，16MHz 的外部晶振无法与 S32K314HMS 定制板配合使用。我使用的是S32 Design Studio 为 S32 平台版本 3.6.9创建的版本，版本 ID 为 260624。我使用原始代码来测试板功能，如下所示（main.c）： #include /* Corrected Raw Hardware Register Addresses for S32K314 */ #define SIUL2_MSCR_PTB5 (*(volatile uint32_t*)(0x40290294U)) #define MC_CGM_CLKOUT_CNTRL (*(volatile uint32_t*)(0x402D4000U)) /* --- CORRECTED FXOSC REAL ADDRESSES --- */ #define FXOSC_CTRL_REG (*(volatile uint32_t*)(0x40288000U)) /* Corrected from 402D4000 */ #define FXOSC_STAT_REG (*(volatile uint32_t*)(0x40288004U)) /* Corrected from 402D4004 */ volatile uint32_t rawTimeoutCounter = 0; volatile uint32_t crystalStableResult = 0; int main(void) { /* 1. RAW PIN SETUP: Configure PTB5 as a High-Drive Output mapped to CLKOUT */ SIUL2_MSCR_PTB5 = (5U << 0) | (1U << 21) | (1U << 19); /* 2. RAW CLOCK ROUTING: Route the Raw FXOSC clock directly to the CLKOUT hardware block */ MC_CGM_CLKOUT_CNTRL = (1U << 24) | (0U << 16); /* Source = FXOSC_CLK, Divider = 1, Enable = 1 */ /* 3. RAW HARDWARE KICKSTART: Power on the External Crystal (FXOSC) analog circuitry */ FXOSC_CTRL_REG |= 0x01U; /* 4. NON-BLOCKING SOFTWARE POLL We read the raw hardware status register. If a crystal is physically oscillating, the status register will flip a hardware bit or report a non-zero value. */ for (rawTimeoutCounter = 0; rawTimeoutCounter < 800000U; rawTimeoutCounter++) { /* Check if the FXOSC status register reports it is locked and stable (Bit 31) */ if ((FXOSC_STAT_REG & 0x80000000U) != 0U) { crystalStableResult = 1; /* HW SUCCESS: Crystal is alive and shaking! */ break; } } /* 5. PASS / FAIL EVALUATION PADS */ if (crystalStableResult == 1) { /* --- CRYSTAL HARDWARE PASSED --- */ for (;;) { __asm("NOP"); /* Put a breakpoint here for success */ } } else { /* --- CRYSTAL HARDWARE FAILED --- */ for (;;) { __asm("NOP"); /* Put a breakpoint here for a safe failure catch */ } } return 0; } 我附上电路板原理图供您参考。 board_schematic.pngboard_schematic.pngboard_schematic.pngboard_schematic.pngboard_schematic.pngboard_schematic.png   同时附上 .mex 文件供您参考的配置信息。 Re: 16MHz external crystal not working on the S32K314HMS custom board 你好@sksingh4476 ， 16 MHz 晶体在 S32K3 系列支持的 FXOSC 晶体频率范围内，因此晶体频率本身应该不是问题。然而，从原始代码片段来看，尚不清楚是否应用了完整的 FXOSC 配置。请特别检查 FXOSC 增益/跨导设置 (GM_SEL)。在晶体模式下，不应使用 GM_SEL = 0000b，因为这对应于零跨导，振荡器可能无法启动或稳定。 关于 mex 文件：生成的时钟初始化代码必须由应用程序调用。如果测试代码绕过生成的 RTD 初始化，并且仅手动写入几个寄存器，则所有必需的 FXOSC 设置（包括 GM_SEL）也必须手动配置。 我建议首先创建一个标准的 S32DS/RTD 示例项目，并通过时钟配置工具配置 FXOSC。请验证外部晶振是否能根据生成的RTD时钟初始化代码正确启动。这比直接从最小的原始寄存器测试开始要好，因为生成的配置应该包含所有必需的 FXOSC 设置，包括振荡器模式和增益配置。 如果标准示例有效，则可以将生成的 FXOSC 寄存器值与最小代码进行比较，并逐步将代码减少到所需的最小序列。如果标准示例也不奏效，那么下一步应该检查硬件方面，特别是晶体参数、ESR、负载电容（包括PCB杂散电容）、EXTAL/XTAL周围的布局以及增益裕度计算。数据手册规定了振荡器建立条件为 gmXOSC > 5 * gm_crit，因此应根据此要求验证所选晶体和外部元器件。 顺祝商祺！ 帕维尔 Re: 16MHz external crystal not working on the S32K314HMS custom board 嗨，PavelL， 非常感谢您的快速回复。 我尝试从RTD网站查找示例代码，但没有找到适用于S32K314单片机的示例代码。 我尝试在主函数中调用时钟初始化函数，但晶振（晶体振荡器）仍然无法工作。 #include "Clock_Ip.h" #include "FreeRTOS.h" #include "task.h" #include "semphr.h" #include "Siul2_Port_Ip.h" #define LED_TASK_PRIORITY ( tskIDLE_PRIORITY + 1 ) #define WELCOME_MSG_1 "hello world uart dma\r\n" int counter, accumulator = 0, limit_value = 1000000; void Led_Task( void *pvParameters ) { (void)pvParameters; for( ;; ) { vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { Clock_Ip_StatusType Status_Init_Clock = CLOCK_IP_ERROR; Status_Init_Clock = Clock_Ip_Init(Clock_Ip_aClockConfig); if (Status_Init_Clock != CLOCK_IP_SUCCESS) { while(1); /* Error during initialization. */ } xTaskCreate( Led_Task , ( const char * const ) "Led_Task", configMINIMAL_STACK_SIZE, (void*)0, LED_TASK_PRIORITY, NULL ); vTaskStartScheduler(); for( ;; ); return 0; } uint8_t Sys_GetCoreID(void) { return 0U; /* Force return Core 0 (Primary ARM Cortex-M7 Core) */ } FXOSC_CTRL 中，GM_SEL 的值为默认值 1100。请参考附件中的时钟配置图。 clock_config.pngclock_config.pngclock_config.pngclock_config.pngclock_config.png 附件中还包含时钟配置文件 clockYaml，供您参考。 我们观察到，另一个开源项目可以让晶体在同一块电路板上工作。以下是 main.c 中使用的代码。文件。我们观察到，他们的时钟配置几乎和我们的一样。我已附上时钟配置供您参考。 /* Including necessary configuration files. */ #include "Clock_Ip.h" #include "FreeRTOS.h" #include "task.h" #include "semphr.h" #include "Siul2_Port_Ip.h" #include "Siul2_Dio_Ip.h" //including uart+dma+interrupt files #include "Lpuart_Uart_Ip.h" #include "Lpuart_Uart_Ip_Irq.h" #include "string.h" #include "IntCtrl_Ip.h" #include "lpuart0.h" #include "Dma_Ip.h" #include "Dma_Ip_Irq.h" #include "CDD_Rm.h" #define LED_TASK_PRIORITY ( tskIDLE_PRIORITY + 1 ) #define WELCOME_MSG_1 "hello world uart dma\r\n" void Led_Task( void *pvParameters ) { (void)pvParameters; for( ;; ) { Lpuart_Uart_Ip_SyncSend(LPUART_UART_IP_INSTANCE_USING_0, (const uint8 *)WELCOME_MSG_1, 20, 0XFFFF); Siul2_Dio_Ip_TogglePins(USER_LED0_PORT, (1 << USER_LED0_PIN)); vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { /* Initialize Clock */ Clock_Ip_StatusType Status_Init_Clock = CLOCK_IP_ERROR; Status_Init_Clock = Clock_Ip_Init(Clock_Ip_aClockConfig); if (Status_Init_Clock != CLOCK_IP_SUCCESS) { while(1); /* Error during initialization. */ } /* Initialize all pins using the Port driver */ Siul2_Port_Ip_PortStatusType Status_Init_Port = SIUL2_PORT_ERROR; Status_Init_Port = Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals); if(Status_Init_Port != SIUL2_PORT_SUCCESS) { while(1); /* Error during initialization. */ } //Init Interrupt Control IntCtrl_Ip_Init(&IntCtrlConfig_0); //Init lpuart0 Lpuart_Uart_Ip_Init(LPUART_UART_IP_INSTANCE_USING_0, &Lpuart_Uart_Ip_xHwConfigPB_0); //DMA init Dma_Ip_Init(&Dma_Ip_Sa_xDmaInitPB); /* Initialize Rm driver for using DmaMux*/ Rm_Init(&Rm_Config); //turn of AsyncReceive of uart dma, this code must behind Rm_Init(&Rm_Config); Lpuart_Uart_Ip_AsyncReceive(LPUART_UART_IP_INSTANCE_USING_0, Lpuart0_Receive_Buffer, LPUART0_RECV_BUF_LEN); xTaskCreate( Led_Task , ( const char * const ) "Led_Task", configMINIMAL_STACK_SIZE, (void*)0, LED_TASK_PRIORITY, NULL ); vTaskStartScheduler(); for( ;; ); return 0; } 我想知道什么样的时钟配置会造成这种差异。 谢谢！ 苏尼尔 Re: 16MHz external crystal not working on the S32K314HMS custom board 你好@sksingh4476 ， 感谢您提供更新信息并分享两种配置方案。 我注意到这两个代码示例之间存在一个重要的区别。在最小测试中，只调用了 Clock_Ip_Init()，而工作项目随后立即调用了 Siul2_Port_Ip_Init()。如果通过观察外部引脚上的 CLKOUT 信号来确定 FXOSC 是否正在运行，则相应的 SIUL2 引脚也必须配置为 CLKOUT 备用功能。Clock_Ip_Init() 配置时钟树，但它本身并不配置物理输出引脚。 请问您目前是如何判断 FXOSC 无法正常工作的？   顺祝商祺！ 帕维尔 Re: 16MHz external crystal not working on the S32K314HMS custom board 嗨，PavelL， 感谢您的反馈， 您的观察启发我尝试将Siul_port_dio模块添加到项目中。似乎添加并初始化这个端口可以让时钟正常工作。但我仍然不明白为什么这会有区别。 我们使用示波器直接测量晶体频率。此外，我们还观察到调试器在初始化时钟时会卡住。 谢谢！ 苏尼尔 Re: 16MHz external crystal not working on the S32K314HMS custom board 你好@sksingh4476 ， 需要进行 SIUL2 端口初始化，才能将选定的 CLKOUT 信号从 MCU 时钟输出路由到物理引脚。Clock_Ip_Init() 配置时钟源、多路复用器和分频器，但不配置引脚复用。因此，在评估引脚上的 CLKOUT 信号之前，必须调用 Siul2_Port_Ip_Init()。 关于调试器问题，请在初始测试中避免单步执行 Clock_Ip_Init()。在函数之前和之后分别设置一个断点，然后在这两个断点之间运行程序。如果未到达第二个断点，请暂停调试器并检查当前程序计数器和调用堆栈，以确定代码是否在时钟超时循环中等待、是否已进入 HardFault 处理程序或设备是否已复位。同时检查在不使用断点的情况下运行应用程序是否会出现相同的行为。 顺祝商祺！ 帕维尔

MapleStory Classic World Review: Is This the Old Fans Have Been Waiting For? After spending years watching MapleStory evolve through countless updates, balance changes, new classes, and modern systems, seeing MapleStory Classic World arrive feels like opening an old memory box. The game brings back the slower progression, charming atmosphere, and classic MMO experience that many veteran players still remember. This MapleStory Classic World review takes a closer look at what makes this version special, including gameplay, classes, leveling speed, economy, and whether it truly captures the feeling of old-school MapleStory. For players who want to enjoy the nostalgic journey without spending endless hours farming basic resources, some players may choose to buy MS Classic World Mesos from trusted services like SSEGold to prepare for equipment upgrades, consumables, and smoother progression. As someone who played MapleStory during its earlier years, I can say that the appeal of MapleStory Classic World is not just about bringing back old maps or familiar monsters. It is about recreating the feeling of exploration, teamwork, and achievement that made the original game so memorable. What Is MapleStory Classic World? MapleStory Classic World is designed around the idea of returning to the roots of the original MapleStory experience. Instead of focusing on modern fast-paced progression, powerful systems, and endless content additions, the classic version focuses on the core elements that made MapleStory popular. The biggest difference between MapleStory Classic World and modern MapleStory is the overall pacing. Modern MapleStory allows players to level extremely quickly, unlock powerful skills early, and jump into endgame content almost immediately. While that approach works for many players, some veterans miss the slower journey where every level felt meaningful. In MapleStory Classic World, progression is more deliberate. A new equipment upgrade feels exciting. A new skill feels rewarding. Reaching a new area feels like an accomplishment. That slower gameplay loop is exactly what many longtime fans have been asking for. The Nostalgia Factor Is the Biggest Strength The strongest part of MapleStory Classic World is easily the nostalgia. For many players, MapleStory was one of their first MMORPG experiences. Walking through familiar locations, fighting classic monsters, and interacting with other players brings back memories that modern games often struggle to recreate. The world design is simple but charming. Areas feel unique. Monsters have personality. The music creates a relaxing atmosphere. These small details are what made MapleStory special. A lot of modern games focus heavily on efficiency and optimization. Players rush through content, follow guides, and focus only on reaching the strongest possible build. MapleStory Classic World encourages players to slow down. You explore. You grind. You meet other players. You enjoy the journey. That is something many veteran MMO players have been missing. MapleStory Classic World Gameplay Review When it comes to gameplay, MapleStory Classic World keeps the traditional side-scrolling MMORPG formula that made the franchise famous. The combat system is simple compared to modern action RPGs, but that simplicity is part of the charm. You are not managing dozens of complicated systems. You are not constantly checking multiple upgrade menus. Instead, the focus is on character progression. Leveling takes time, and every improvement matters. Early game monsters can actually feel dangerous, especially when your character is under-geared. Unlike modern versions where players often destroy enemies instantly, classic gameplay requires more preparation. You need better equipment. You need enough potions. You need to understand your class. You need patience. For veteran players, this slower pace feels refreshing. For newer players, it may require some adjustment. Class Experience in MapleStory Classic World One of the biggest reasons players enjoy MapleStory is the class system. The classic class structure creates a stronger identity between characters. Every class has strengths and weaknesses. Every job advancement feels important. Every skill point decision matters. Popular classic classes include: Warrior Magician Bowman Thief Pirate Each class provides a different leveling experience. Warriors are known for their durability and straightforward combat style. Magicians provide strong damage options but require careful resource management. Bowmen offer ranged attacks and consistent damage. Thieves provide mobility and fast-paced gameplay. Pirates bring unique mechanics and playstyles. Unlike modern games where many classes can handle almost everything, MapleStory Classic World makes class choice feel meaningful. Your decision affects your entire journey. Leveling Progression and Difficulty The leveling experience is probably the biggest difference between MapleStory Classic World and modern MapleStory. Classic MapleStory was never about rushing. It was about the adventure. Grinding the same monsters for experience was normal. Finding a good training spot was valuable information. Party grinding was a major part of the experience. Today, many MMO players are used to reaching high levels quickly. MapleStory Classic World brings back a time when reaching a milestone required commitment. This can be frustrating for some players. However, for players who enjoy traditional MMORPG progression, it is incredibly satisfying. There is a special feeling when you finally reach a new job advancement after hours of effort. The Economy and MapleStory Classic World Gold The economy is another important part of the MapleStory Classic World experience. Gold management matters because equipment, potions, and upgrades can become expensive. Unlike many modern games where currency is easy to obtain, classic-style progression requires more planning. Players need to decide: Should I upgrade my current weapon? Should I save for better equipment? Should I spend money on consumables? Should I invest in my character now or later? These decisions create a more engaging economy. The value of MapleStory Classic World Gold comes from how much it impacts progression. Having enough gold can make your leveling experience smoother and help you prepare for stronger equipment. However, part of the classic experience is also earning your progress naturally through gameplay. Is MapleStory Classic World Friendly for New Players? This is an important question because many returning players will bring friends who never experienced the original MapleStory. The answer is mixed. On one hand, MapleStory Classic World is easier to understand than many modern MMORPGs. The basic gameplay loop is simple. Create a character. Choose a class. Level up. Upgrade equipment. Explore new areas. On the other hand, the game does not always explain everything. New players may need to learn through experience or community guides. The good thing is that the MapleStory community has always been one of the strongest parts of the game. Veteran players often share knowledge, help newcomers, and create a social atmosphere that many modern games lack. MapleStory Classic World Compared to Modern MapleStory The biggest question many players have is whether MapleStory Classic World is better than modern MapleStory. The honest answer depends on what you want. Modern MapleStory offers: Faster progression. More classes. More systems. More endgame content. MapleStory Classic World offers: Nostalgia. Meaningful progression. Social gameplay. A slower MMO experience. Neither version is necessarily better. They are designed for different audiences. Players who enjoy efficiency and endgame optimization may prefer modern MapleStory. Players who miss the old MMO feeling will probably enjoy MapleStory Classic World much more. Final Verdict: Is MapleStory Classic World Worth Playing? After looking at the gameplay, progression, economy, and overall experience, this MapleStory Classic World review comes down to one simple conclusion. MapleStory Classic World succeeds because it understands what made the original game special. It is not trying to compete with modern MMORPGs through speed or complexity. Instead, it focuses on adventure, community, and nostalgia. The slower leveling may not appeal to everyone. The older systems may feel outdated to some players. But for anyone who remembers spending hours exploring Maple Island, grinding familiar monsters, or celebrating every job advancement, MapleStory Classic World delivers something special. It reminds players that MMORPGs are not only about reaching the final level. Sometimes the journey itself is the best part. For veteran MapleStory fans, MapleStory Classic World is a chance to experience that feeling again. For new players, it is a chance to discover why this classic MMO became such an important part of gaming history.

冒险岛经典版世界评测：这是老玩家们一直期待的吗？ 多年来，我一直看着冒险岛经历了无数次的更新、平衡性调整、新职业和现代系统的发展，如今看到冒险岛经典世界的到来，感觉就像打开了一个尘封已久的记忆盒子。这款游戏带回了许多老玩家记忆中较为缓慢的游戏进程、迷人的氛围和经典的MMO体验。 这篇《冒险岛经典世界》评测将深入探讨该版本有何特别之处，包括游戏玩法、职业、升级速度、经济系统，以及它是否真正捕捉到了老式冒险岛的感觉。 对于那些想要享受怀旧之旅但又不想花费无休止的时间去收集基础资源的玩家来说，一些玩家可能会选择从 SSEGold 等值得信赖的服务商那里购买MS Classic 世界金币，以便为装备升级、消耗品和更顺畅的游戏进程做好准备。 作为一名在冒险岛早期就玩过这款游戏的人，我可以说，冒险岛经典世界的吸引力不仅仅在于带回了旧地图或熟悉的怪物。它旨在重现原版游戏中那种令人难忘的探索、团队合作和成就感。 什么是冒险岛经典世界？ MapleStory Classic World 的设计理念是回归 MapleStory 最初的体验。经典版并没有着重于现代快节奏的升级、强大的系统和无尽的内容更新，而是专注于让冒险岛流行起来的核心元素。 冒险岛经典世界和现代冒险岛最大的区别在于整体节奏。 现代冒险岛允许玩家快速升级，早期解锁强大的技能，并几乎立即进入游戏后期内容。虽然这种方法对很多玩家都有效，但一些老玩家怀念那种节奏较慢、每个关卡都意义非凡的旅程。 在冒险岛经典版中，游戏进程更加循序渐进。 设备升级换代令人兴奋。 掌握一项新技能会带来成就感。 到达一个新的区域会让人感到很有成就感。 这种较慢的游戏循环正是许多老玩家一直以来所期待的。 怀旧因素是最大的优势 《冒险岛经典版》最大的亮点无疑是它的怀旧情怀。 对于许多玩家来说，冒险岛是他们最早接触的MMORPG之一。漫步在熟悉的地点，与经典的怪物战斗，并与其他玩家互动，这些都能唤起现代游戏往往难以重现的回忆。 世界的设计简洁却不失魅力。 各个区域都各具特色。 怪物也有个性。 音乐营造出轻松的氛围。 正是这些小细节让冒险岛如此特别。 许多现代游戏都非常注重效率和优化。玩家们快速通关，遵循攻略，只专注于打造最强的版本。 MapleStory Classic World 鼓励玩家放慢节奏。 你去探索。 你努力奋斗。 你会遇到其他玩家。 你享受这段旅程。 这是许多资深MMO玩家一直以来所缺失的。 冒险岛经典版世界游戏玩法评测 在游戏玩法方面，《冒险岛经典世界》保留了使该系列游戏闻名遐迩的传统横版卷轴MMORPG模式。 与现代动作角色扮演游戏相比，战斗系统很简单，但这种简单正是它的魅力所在。 你不需要管理几十个复杂的系统。 你不需要不断查看多个升级菜单。 相反，重点在于角色成长。 升级需要时间，每一次进步都至关重要。 游戏初期遇到的怪物确实会让人感到危险，尤其是在角色装备较差的情况下。与现代版本中玩家经常瞬间消灭敌人不同，经典游戏玩法需要更多准备。 你需要更好的设备。 你需要足够的药水。 你需要了解你的课程。 你需要耐心。 对于老玩家来说，这种慢节奏让人感觉耳目一新。 对于新手玩家来说，可能需要一些适应。 在冒险岛经典版世界中的课堂体验 玩家喜欢冒险岛的最大原因之一就是它的职业系统。 经典的阶级结构能够增强角色之间的认同感。 每个班级都有其优势和劣势。 每一次工作晋升都感觉很重要。 每一个技能点数的选择都至关重要。 热门经典课程包括： 战士 魔术师 鲍曼 贼 海盗 每个班级提供的升级体验都不同。 战士们以其耐力和直截了当的战斗风格而闻名。 魔法师拥有强大的伤害输出手段，但需要谨慎管理资源。 弓箭手提供远程攻击和持续伤害。 盗贼职业提供高机动性和快节奏的游戏体验。 海盗带来了独特的机制和玩法。 与现代游戏中许多职业几乎可以胜任所有事情不同，冒险岛经典世界让职业选择变得有意义。 你的决定会影响你的整个旅程。 等级提升和难度 升级体验可能是冒险岛经典版和现代冒险岛之间最大的区别。 经典冒险岛的精髓就在于快速推进。 关键在于冒险。 反复刷同样的怪物来获取经验值是常态。 找到合适的训练场地是非常有用的信息。 派对狂欢是这次体验的重要组成部分。 如今，许多MMO玩家已经习惯了快速达到高等级。MapleStory Classic World 带你回到那个需要付出努力才能达成里程碑的时代。 这可能会让一些玩家感到沮丧。 然而，对于喜欢传统 MMORPG 角色成长系统的玩家来说，这会带来极大的满足感。 经过数小时的努力，终于获得新的工作晋升，那种感觉非常特别。 经济与冒险岛经典版世界金币 经济是冒险岛经典版世界体验的另一个重要组成部分。 金币管理很重要，因为装备、药水和升级都会变得很贵。 与许多现代游戏中货币容易获取不同，经典风格的游戏进程需要更多的规划。 玩家需要做出决定： 我应该升级我目前的武器吗？ 我应该攒钱买更好的设备吗？ 我应该花钱买消耗品吗？ 我应该现在投资培养我的角色，还是以后再投资？ 这些决策将创造一个更具活力的经济环境。 MapleStory Classic 世界金币的价值在于它对游戏进程的影响程度。 拥有足够的金币可以让你的升级过程更加顺利，并帮助你为更强大的装备做好准备。 然而，经典游戏体验的一部分也在于通过游戏自然而然地取得进步。 冒险岛经典版对新手玩家友好吗？ 这是一个重要的问题，因为很多回归玩家会带一些从未体验过原版冒险岛的朋友一起来玩。 答案不一。 一方面，冒险岛经典版比许多现代大型多人在线角色扮演游戏更容易上手。 基本游戏循环很简单。 创建角色。 选择一门课程。 升级。 升级设备。 探索新领域。 另一方面，游戏并非总是解释一切。 新玩家可能需要通过经验积累或参考社区指南来学习。 好消息是，冒险岛社区一直是这款游戏最强大的组成部分之一。 老玩家经常分享知识，帮助新手，并营造出许多现代游戏所缺乏的社交氛围。 冒险岛经典版世界与现代冒险岛的比较 许多玩家最关心的问题是，冒险岛经典版是否比现代冒险岛更好。 诚实的答案取决于你想要什么。 现代冒险岛提供： 进展更快。 更多课程。 更多系统。 更多游戏后期内容。 MapleStory Classic World 提供： 怀旧。 有意义的进步。 社交游戏。 节奏较慢的MMO游戏体验。 两种版本并无优劣之分。 它们的设计面向不同的受众群体。 喜欢追求效率和后期优化的玩家可能会更喜欢现代的冒险岛。 怀念老式MMO游戏体验的玩家可能会更喜欢冒险岛经典世界。 最终结论：冒险岛经典世界值得玩吗？ 在考察了游戏玩法、进度、经济系统和整体体验之后，这篇《冒险岛经典世界》评测可以归结为一个简单的结论。 《冒险岛经典世界》之所以成功，是因为它理解了原版游戏的独特之处。 它并不试图通过速度或复杂性与现代大型多人在线角色扮演游戏（MMORPG）竞争。 相反，它更侧重于冒险、社群和怀旧。 较慢的升级速度可能并不适合所有人。 对于一些玩家来说，旧系统可能会显得过时。 但对于那些还记得在枫之岛花费数小时探索、反复刷熟悉的怪物，或者庆祝每一次职业晋升的人来说，《冒险岛经典世界》带来了一些特别的东西。 它提醒玩家，MMORPG 游戏不仅仅是达到最终等级那么简单。 有时候，旅途本身就是最美好的部分。 对于资深冒险岛玩家来说，冒险岛经典世界提供了一个再次体验那种感觉的机会。 对于新玩家来说，这是一个了解这款经典MMO为何成为游戏史上如此重要组成部分的机会。

メイプルストーリー クラシックワールド レビュー：これは古参ファンが待ち望んでいたものなのか？ 長年にわたり、数々のアップデート、バランス調整、新クラス、そして最新システムを通してメイプルストーリーの進化を見守ってきた私たちにとって、メイプルストーリー クラシックワールドの登場は、まるで昔の思い出の箱を開けるような感覚だ。このゲームは、多くのベテランプレイヤーが今でも覚えている、ゆったりとした進行、魅力的な雰囲気、そして古典的なMMO体験を復活させている。 このメイプルストーリー クラシックワールドのレビューでは、ゲームプレイ、クラス、レベルアップ速度、経済システム、そして昔ながらのメイプルストーリーの雰囲気を本当に再現しているかどうかなど、このバージョンを特別なものにしている要素を詳しく見ていきます。 基本的な資源を延々と集めることに時間を費やすことなく、懐かしい旅を楽しみたいプレイヤーのために、SSEGoldのような信頼できるサービスからMSクラシックワールドのメソを購入し、装備のアップグレード、消耗品、そしてよりスムーズな進行に備えるプレイヤーもいるかもしれません。 メイプルストーリーの初期にプレイした者として言えるのは、『メイプルストーリー クラシックワールド』の魅力は単に古いマップや馴染みのあるモンスターを復活させることだけではないということです。オリジナルのゲームを忘れられないものにした探索、チームワーク、達成感の感覚を再現することに関わっています。 メイプルストーリー クラシックワールドとは何ですか？ 『メイプルストーリー クラシックワールド』は、オリジナルのメイプルストーリー体験の原点に立ち返ることをテーマに設計されています。現代のテンポの速いゲーム展開、強力なシステム、そして際限のないコンテンツ追加に焦点を当てるのではなく、クラシック版はメイプルストーリーを人気にした核となる要素に焦点を当てています。 メイプルストーリークラシックワールドと現代版メイプルストーリーの最大の違いは、全体的なゲームのテンポです。 現代のメイプルストーリーでは、プレイヤーは非常に速いスピードでレベルアップし、強力なスキルを早期に習得し、ほぼ即座にエンドコンテンツに飛び込むことができる。そのやり方は多くのプレイヤーにとって有効だが、ベテランプレイヤーの中には、各レベルが意味のあるものに感じられた、よりゆっくりとした道のりを懐かしむ者もいる。 メイプルストーリークラシックワールドでは、進行はより計画的である。 新しい機器へのアップグレードはワクワクする。 新しいスキルを習得すると、やりがいを感じる。 新しい地域に到達することは、達成感を感じる。 そのゆったりとしたゲームプレイのループこそ、長年のファンがまさに求めていたものだ。 ノスタルジア要素が最大の強み MapleStory Classic Worldの最大の魅力は、間違いなく懐かしさにある。 多くのプレイヤーにとって、メイプルストーリーは初めて体験したMMORPGの一つだった。見慣れた場所を歩き回り、おなじみのモンスターと戦い、他のプレイヤーと交流することで、現代のゲームではなかなか再現できないような思い出が蘇る。 世界のデザインはシンプルながら魅力的です。 それぞれの地域に独特の雰囲気がある。 モンスターにも個性がある。 その音楽はリラックスできる雰囲気を作り出している。 こうした細かな点が、メイプルストーリーを特別なものにしていたのです。 現代のゲームの多くは、効率性と最適化に重点を置いている。プレイヤーはコンテンツを急いで進め、攻略ガイドに従い、最強のビルドを完成させることだけに集中する。 メイプルストーリークラシックワールドは、プレイヤーにゆったりとした時間を過ごすことを推奨しています。 あなたは探検する。 あなたは努力する。 他のプレイヤーと出会うことができます。 あなたは旅そのものを楽しむ。 それは、多くのベテランMMOプレイヤーが待ち望んでいたものだ。 メイプルストーリー クラシックワールド ゲームプレイレビュー ゲームプレイに関しては、『メイプルストーリー クラシックワールド』は、シリーズを有名にした伝統的な横スクロールMMORPGの形式を踏襲している。 戦闘システムは現代のアクションRPGに比べるとシンプルだが、そのシンプルさこそが魅力の一つとなっている。 あなたは数十もの複雑なシステムを管理しているわけではありません。 複数のアップグレードメニューを常に確認する必要はありません。 その代わりに、キャラクターの成長に重点が置かれている。 レベリングには時間がかかり、どんな改善も重要です。 序盤のモンスターは、特に装備不足のキャラクターが危険に感じられることがあります。現代のゲームではプレイヤーが敵を瞬時に倒すことが多いのに対し、古典的なゲームプレイではより多くの準備が必要となる。 もっと良い機材が必要だ。 十分な量のポーションが必要です。 あなたは自分の授業内容を理解する必要があります。 忍耐が必要です。 ベテラン選手にとって、このゆったりとしたペースは新鮮に感じられる。 初心者プレイヤーにとっては、多少の慣れが必要になるかもしれません。 メイプルストーリークラシックワールドでの授業体験 プレイヤーがメイプルストーリーを楽しむ最大の理由の一つは、クラスシステムである。 古典的な階級構造は、登場人物間のより強いアイデンティティを生み出す。 どのクラスにも長所と短所がある。 仕事上の昇進はどれも重要に感じられる。 すべてのスキルポイントの決定が重要です。 人気の定番クラスには以下のようなものがあります。 戦士 マジシャン ボウマン 泥棒 海賊 各クラスによって、レベルアップの過程は異なります。 戦士たちは、その耐久力と率直な戦闘スタイルで知られている。 魔術師は強力なダメージオプションを提供しますが、慎重な資源マネジメントが必要です。 弓兵は遠距離攻撃が可能で、安定したダメージを与えることができる。 泥棒は機動性とテンポの速いゲームプレイを提供する。 海賊は独自のゲームシステムとプレイスタイルをもたらします。 多くのクラスがほぼすべてをこなせる現代のゲームとは異なり、『メイプルストーリー クラシックワールド』はクラス選択に意味のあるものを与えています。 あなたの決断は、あなたの旅全体に影響を与えます。 レベルアップの進行と難易度 レベル上げの体験は、おそらくメイプルストーリークラシックワールドと現代版メイプルストーリーの最大の違いだろう。 クラシック版メイプルストーリーは、決して急ぐこととは無縁だった。 それは冒険だった。 同じモンスターを倒して経験値を稼ぐのは普通のことだった。 良いトレーニング場所を見つけることは貴重な情報だった。 パーティーでひたすらプレイすることは、この体験の大きな部分を占めていた。 今日では、多くのMMOプレイヤーは短時間で高レベルに到達することに慣れている。メイプルストーリー クラシックワールドは、目標を達成するために努力が必要だった時代を蘇らせます。 これは一部のプレイヤーにとってフラストレーションの溜まるかもしれません。 しかし、伝統的なMMORPGの成長システムを楽しむプレイヤーにとっては、非常に満足のいくものとなるだろう。 何時間もの努力の末、ついに昇進を果たした時の喜びは格別だ。 経済とメイプルストーリークラシックワールドゴールド 経済システムは、メイプルストーリー クラシックワールドの体験におけるもう一つの重要な要素です。 金のマネジメントは重要です。なぜなら装備、ポーション、アップグレードは高額になることがあるからです。 現代の多くのゲームでは通貨の入手が容易であるのに対し、古典的なスタイルのゲーム進行では、より多くの計画が必要となる。 プレイヤーは決断する必要がある： 今使っている武器をアップグレードするべきでしょうか？ より良い機材のために貯金すべきでしょうか？ 消耗品にお金を使うべきでしょうか？ 自分の人格形成に投資するなら、今投資すべきか、それとも後で投資すべきか？ こうした決定は、より魅力的な経済を生み出す。 メイプルストーリークラシックのワールドゴールドの価値は、それがゲームの進行にどれだけ影響を与えるかという点にある。 十分なゴールドがあれば、レベリングの過程がスムーズになり、より強力な装備の準備に役立ちます。 しかし、クラシックな体験の一部には、ゲームプレイを通して自然に進歩していくことも含まれる。 メイプルストーリークラシックの世界は、新規プレイヤーにとって親しみやすいですか？ これは重要な問題です。なぜなら、復帰プレイヤーの多くは、オリジナルのメイプルストーリーをプレイしたことのない友人を連れてくるからです。 答えは一概には言えません。 一方で、『メイプルストーリー クラシックワールド』は、多くの現代のMMORPGよりも理解しやすい。 基本的なゲームプレイの流れはシンプルだ。 キャラクターを作成する。 クラスを選択してください。 レベルアップする。 機器をアップグレードする。 新しい地域を探検しよう。 一方で、ゲームは必ずしも全てを説明してくれるわけではない。 新規プレイヤーは、経験やコミュニティガイドを通して学ぶ必要があるかもしれません。 良い点は、メイプルストーリーのコミュニティが常にこのゲームの最も強力な要素の一つであったということです。 ベテランプレイヤーは知識を共有したり、初心者を助けたりすることで、現代の多くのゲームに欠けている社交的な雰囲気を作り出している。 メイプルストーリー クラシックワールドと現代版メイプルストーリーの比較 多くのプレイヤーが抱える最大の疑問は、メイプルストーリークラシックワールドが現代版メイプルストーリーよりも優れているかどうかだ。 正直な答えは、あなたが何を求めているかによります。 現代のメイプルストーリーでは以下のものを提供しています。 より速い進歩。 もっと授業を。 より多くのシステム。 エンドコンテンツをさらに追加。 メイプルストーリークラシックワールドでは以下のサービスが提供されています。 懐かしさ。 意義のある進歩。 ソーシャルゲームプレイ。 よりゆったりとしたMMO体験。 どちらのバージョンも必ずしも優れているとは言えない。 それらは異なる対象者向けに設計されている。 効率性やエンドゲームの最適化を重視するプレイヤーは、現代のメイプルストーリーを好むかもしれない。 昔のMMOの感覚が恋しいプレイヤーは、おそらくメイプルストーリークラシックワールドをより楽しめるだろう。 最終結論：メイプルストーリー クラシックワールドはプレイする価値があるのか？ ゲームプレイ、進行状況、経済システム、そして全体的な体験を検証した結果、このメイプルストーリー クラシックワールドのレビューは、一つのシンプルな結論にたどり着きます。 『メイプルストーリー クラシックワールド』が成功しているのは、オリジナル版の魅力の本質を理解しているからだ。 本作は、スピードや複雑さで現代のMMORPGと競合しようとしているわけではない。 むしろ、冒険、コミュニティ、そしてノスタルジアに焦点を当てている。 レベルアップのペースが遅いのは、万人受けするとは限らない。 古いシステムは、一部のプレイヤーにとっては時代遅れに感じられるかもしれない。 しかし、メイプル島を何時間もかけて探索したり、お馴染みのモンスターを倒したり、仕事の昇進を祝ったりしたことを覚えている人にとって、『メイプルストーリー クラシックワールド』は特別な体験を提供してくれる。 これは、MMORPGは最終レベルに到達することだけが全てではないということをプレイヤーに思い出させる。 時には、旅そのものが最高の部分となることもある。 ベテランのメイプルストーリーファンにとって、メイプルストーリークラシックワールドは、あの感動を再び味わえるチャンスです。 新規プレイヤーにとっては、この古典的なMMOがなぜゲーム史においてこれほど重要な位置を占めるようになったのかを知る絶好の機会となるでしょう。

i.MX93上でEASYEVSE Linuxイメージを構築できません こんにちは、みんな、 私はUG10357 NXP EasyEVSE EV充電ステーション開発プラットフォームのEVerestユーザーガイドを読んで実行しています。しかし、bitbakeコマンド「bitbake imx-image-everest」(ユーザーガイドの12ページ)を実行したときにエラーが発生しました。問題は添付のスクリーンショットで読み、確認できます。この問題はEdgeLock SE05x Plug and Trust Middlewareのバージョンに関連していると思われます。このガイドはバージョン04.07.01に基づいて作成されていますが、NXPはバージョン04.08.01しか提供していません。この互換性の問題をどう解決すればいいか、何かアイデアはありますか? ありがとうございます。 ロランド 評価ボード Re: Unable to build EASYEVSE Linux image on i.MX93 こんにちは、 @Rolando EdgeLock SE05x プラグアンドトラストミドルウェア バージョン04.08.01に合わせて、このファイルを修正してみてください。 Zhiming_Liu_0-1787040520433.pngZhiming_Liu_0-1787040520433.png よろしくお願いします、 志明

S32K314HMSカスタムボードで16MHz外部水晶発振器が動作しない こんにちは、 S32K314HMSカスタムボードで、16MHzの外部水晶発振器が動作しないという問題に直面しています。S32 Design Studioで作成したビルドを使っています。プラットフォームバージョン:3.6.9 ビルドID:260624。下記のmain.cで基板の機能をテストするために生コードを使っています。 #include /* Corrected Raw Hardware Register Addresses for S32K314 */ #define SIUL2_MSCR_PTB5 (*(volatile uint32_t*)(0x40290294U)) #define MC_CGM_CLKOUT_CNTRL (*(volatile uint32_t*)(0x402D4000U)) /* --- CORRECTED FXOSC REAL ADDRESSES --- */ #define FXOSC_CTRL_REG (*(volatile uint32_t*)(0x40288000U)) /* Corrected from 402D4000 */ #define FXOSC_STAT_REG (*(volatile uint32_t*)(0x40288004U)) /* Corrected from 402D4004 */ volatile uint32_t rawTimeoutCounter = 0; volatile uint32_t crystalStableResult = 0; int main(void) { /* 1. RAW PIN SETUP: Configure PTB5 as a High-Drive Output mapped to CLKOUT */ SIUL2_MSCR_PTB5 = (5U << 0) | (1U << 21) | (1U << 19); /* 2. RAW CLOCK ROUTING: Route the Raw FXOSC clock directly to the CLKOUT hardware block */ MC_CGM_CLKOUT_CNTRL = (1U << 24) | (0U << 16); /* Source = FXOSC_CLK, Divider = 1, Enable = 1 */ /* 3. RAW HARDWARE KICKSTART: Power on the External Crystal (FXOSC) analog circuitry */ FXOSC_CTRL_REG |= 0x01U; /* 4. NON-BLOCKING SOFTWARE POLL We read the raw hardware status register. If a crystal is physically oscillating, the status register will flip a hardware bit or report a non-zero value. */ for (rawTimeoutCounter = 0; rawTimeoutCounter < 800000U; rawTimeoutCounter++) { /* Check if the FXOSC status register reports it is locked and stable (Bit 31) */ if ((FXOSC_STAT_REG & 0x80000000U) != 0U) { crystalStableResult = 1; /* HW SUCCESS: Crystal is alive and shaking! */ break; } } /* 5. PASS / FAIL EVALUATION PADS */ if (crystalStableResult == 1) { /* --- CRYSTAL HARDWARE PASSED --- */ for (;;) { __asm("NOP"); /* Put a breakpoint here for success */ } } else { /* --- CRYSTAL HARDWARE FAILED --- */ for (;;) { __asm("NOP"); /* Put a breakpoint here for a safe failure catch */ } } return 0; } 参考までに基板の回路図を添付いたします。 board_schematic.pngboard_schematic.pngboard_schematic.pngboard_schematic.pngboard_schematic.pngボードの概略図.png   .mexファイルも添付します参考までに設定内容を記載します。 Re: 16MHz external crystal not working on the S32K314HMS custom board こんにちは、 @sksingh4476 さん、 16 MHzのクリスタルはS32K3ファミリーのサポートFXOSCクリスタル周波数範囲内にあるため、クリスタル周波数自体が問題になることはありません。しかし、生のコードスニペットからは、完全なFXOSC構成が適用されているかどうかは明確ではありません。特に、FXOSCゲイン／相互コンダクタンス設定（GM_SEL）を確認してください。水晶発振モードでは、GM_SEL = 0000b を使用しないでください。これは相互コンダクタンスがゼロになることを意味し、発振器が起動しない、または安定しない可能性があります。 mexファイルについて:生成されたクロック初期化コードはアプリケーションによって呼び出されなければなりません。テストコードが生成されたRTD初期化をバイパスし、少数のレジスタのみを手動で書き込む場合、GM_SELを含むすべての必須FXOSC設定も手動で構成する必要があります。 まずは、標準的なS32DS/RTDのサンプルプロジェクトを作成し、クロック設定ツールを使用してFXOSCを設定することをお勧めします。生成されたRTDクロック初期化コードを使用して、外部水晶発振器が正しく起動するかどうかを確認してください。これは、最小限の生レジスタテストから直接始めるよりも優れたベースラインです。なぜなら、生成される構成には、発振器モードやゲイン構成など、必要なすべてのFXOSC設定が含まれるはずだからです。 標準的な例がうまくいけば、生成されたFXOSCレジスタの値と最小コードを比較し、徐々に最小の必要シーケンスにコードを減らすことができます。標準的な例でも動作しない場合は、次のステップはハードウェア側、特に結晶パラメータ、ESR、PCBの静電容量を含む負荷コンデンサ、EXTAL/XTAL周辺のレイアウト、そしてゲインマージン計算を確認することです。データシートでは、gmXOSC > 5 * gm_critを用いて発振器の構築条件を規定しているため、選択された結晶および外部部品はこの要件に照らして検証されるべきです。 よろしくお願いいたします。 パベル Re: 16MHz external crystal not working on the S32K314HMS custom board こんにちは、 @sksingh4476 さん、 アップデート情報と両方の設定を共有していただきありがとうございます。 2つのコード例の間に重要な違いがあることに気づきました。最小限のテストでは Clock_Ip_Init() のみが呼び出されますが、実際のプロジェクトではその直後に Siul2_Port_Ip_Init() も呼び出されます。外部ピンのCLKOUT信号を観測してFXOSCが動作しているかどうかを判断する場合、対応するSIUL2ピンもCLKOUT代替機能用に構成する必要があります。Clock_Ip_Init() はクロックツリーを設定しますが、それ自体では物理的な出力ピンを設定するわけではありません。 FXOSCが機能していないと判断している理由を、具体的に教えていただけますか?   よろしくお願いいたします。 パベル Re: 16MHz external crystal not working on the S32K314HMS custom board こんにちは、PavelLさん。 迅速なご対応、ありがとうございました。 RTDの例コードを探しましたが、S32K314 MCU用のものは見つかりませんでした。 メイン関数内でクロック初期化関数を呼び出してみましたが、水晶発振器がまだ動作しません。 #include "Clock_Ip.h" #include "FreeRTOS.h" #include "task.h" #include "semphr.h" #include "Siul2_Port_Ip.h" #define LED_TASK_PRIORITY ( tskIDLE_PRIORITY + 1 ) #define WELCOME_MSG_1 "hello world uart dma\r\n" int counter, accumulator = 0, limit_value = 1000000; void Led_Task( void *pvParameters ) { (void)pvParameters; for( ;; ) { vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { Clock_Ip_StatusType Status_Init_Clock = CLOCK_IP_ERROR; Status_Init_Clock = Clock_Ip_Init(Clock_Ip_aClockConfig); if (Status_Init_Clock != CLOCK_IP_SUCCESS) { while(1); /* Error during initialization. */ } xTaskCreate( Led_Task , ( const char * const ) "Led_Task", configMINIMAL_STACK_SIZE, (void*)0, LED_TASK_PRIORITY, NULL ); vTaskStartScheduler(); for( ;; ); return 0; } uint8_t Sys_GetCoreID(void) { return 0U; /* Force return Core 0 (Primary ARM Cortex-M7 Core) */ } FXOSC_CTRLの場合、GM_SELの値はデフォルト値の1100です。参考として、添付の時計設定画像をご参照ください。 clock_config.pngclock_config.pngclock_config.pngclock_config.png 参考資料として、時計の設定ファイルclockYamlを添付いたします。 別のオープンソースプロジェクトが同じ基板上で結晶を動作させることが可能であることに気づきました。main.cで使用されているコードは以下のとおりです。ファイル。クロック構成が我々のものとほぼ同じであることを確認した。参考までに、時計の設定ファイルを添付しました。 /* Including necessary configuration files. */ #include "Clock_Ip.h" #include "FreeRTOS.h" #include "task.h" #include "semphr.h" #include "Siul2_Port_Ip.h" #include "Siul2_Dio_Ip.h" //including uart+dma+interrupt files #include "Lpuart_Uart_Ip.h" #include "Lpuart_Uart_Ip_Irq.h" #include "string.h" #include "IntCtrl_Ip.h" #include "lpuart0.h" #include "Dma_Ip.h" #include "Dma_Ip_Irq.h" #include "CDD_Rm.h" #define LED_TASK_PRIORITY ( tskIDLE_PRIORITY + 1 ) #define WELCOME_MSG_1 "hello world uart dma\r\n" void Led_Task( void *pvParameters ) { (void)pvParameters; for( ;; ) { Lpuart_Uart_Ip_SyncSend(LPUART_UART_IP_INSTANCE_USING_0, (const uint8 *)WELCOME_MSG_1, 20, 0XFFFF); Siul2_Dio_Ip_TogglePins(USER_LED0_PORT, (1 << USER_LED0_PIN)); vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { /* Initialize Clock */ Clock_Ip_StatusType Status_Init_Clock = CLOCK_IP_ERROR; Status_Init_Clock = Clock_Ip_Init(Clock_Ip_aClockConfig); if (Status_Init_Clock != CLOCK_IP_SUCCESS) { while(1); /* Error during initialization. */ } /* Initialize all pins using the Port driver */ Siul2_Port_Ip_PortStatusType Status_Init_Port = SIUL2_PORT_ERROR; Status_Init_Port = Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals); if(Status_Init_Port != SIUL2_PORT_SUCCESS) { while(1); /* Error during initialization. */ } //Init Interrupt Control IntCtrl_Ip_Init(&IntCtrlConfig_0); //Init lpuart0 Lpuart_Uart_Ip_Init(LPUART_UART_IP_INSTANCE_USING_0, &Lpuart_Uart_Ip_xHwConfigPB_0); //DMA init Dma_Ip_Init(&Dma_Ip_Sa_xDmaInitPB); /* Initialize Rm driver for using DmaMux*/ Rm_Init(&Rm_Config); //turn of AsyncReceive of uart dma, this code must behind Rm_Init(&Rm_Config); Lpuart_Uart_Ip_AsyncReceive(LPUART_UART_IP_INSTANCE_USING_0, Lpuart0_Receive_Buffer, LPUART0_RECV_BUF_LEN); xTaskCreate( Led_Task , ( const char * const ) "Led_Task", configMINIMAL_STACK_SIZE, (void*)0, LED_TASK_PRIORITY, NULL ); vTaskStartScheduler(); for( ;; ); return 0; } どのクロック構成がこの違いを生むのか気になっています。 ありがとうございます スニル Re: 16MHz external crystal not working on the S32K314HMS custom board こんにちは、PavelLさん。 ご返信ありがとうございます。 あなたの指摘のおかげで、Siul_port_dioモジュールをプロジェクトに追加してみようという方向性が見えてきました。このポートを追加して初期化すると、クロックが動作するようになるようです。しかし、なぜこれが違いを生むのか、私にはまだ理解できません。 私たちはオシロスコープを使って水晶発振器の周波数を直接測定しています。また、クロックの初期化中にデバッガーが停止してしまうことも確認しました。 ありがとうございます スニル Re: 16MHz external crystal not working on the S32K314HMS custom board こんにちは、 @sksingh4476 さん、 SIUL2ポートの初期化は、選択したCLKOUT信号をMCUクロック出力から物理ピンにルーティングするために必要です。Clock_Ip_Init() はクロックソース、マルチプレクサ、分周器を設定しますが、ピンマルチプレクサは設定しません。したがって、ピン上のCLKOUT信号を評価する前に、Siul2_Port_Ip_Init()を呼び出す必要があります。 デバッガーの問題に関してですが、最初のテストでは Clock_Ip_Init() をステップ実行することは避けてください。関数の直前と直後にそれぞれブレークポイントを設定し、その間を走行します。2番目のブレークポイントに到達しない場合は、デバッガーを一時停止し、現在のプログラムカウンタとコールスタックを確認して、コードがクロックタイムアウトループ内で待機しているか、ハードフォルトハンドラに入ったか、またはデバイスがリセットされたかを判断してください。また、ブレークポイントなしでアプリケーションを実行しても同じ動作が起こるかどうかも確認してください。 よろしくお願いいたします。 パベル

无法在 i.MX93 上构建 EASYEVSE Linux 镜像 大家好， 我正在阅读并执行 EVerest 用户指南中的 UG10357 NXP EasyEVSE 电动汽车充电站开发平台。但是，我在运行 bitbake 命令“ bitbake imx-image-everest ”（用户指南第 12 页）时遇到了错误。问题可以在附图的截图中看到。我认为这个问题与 EdgeLock SE05x Plug and Trust 中间件版本有关，该指南基于 04.07.01 版本，但 NXP 只提供 04.08.01 版本。有什么办法解决这个兼容性问题吗？ 谢谢， 罗兰多 评估板 Re: Unable to build EASYEVSE Linux image on i.MX93 嗨@Rolando 请尝试修改此文件，使其与 EdgeLock SE05x 即插即用中间件版本04.08.01相匹配。 Zhiming_Liu_0-1787040520433.png志明_刘_0-1787040520433.png 此致， 志明

i.MX95上でELE APIを使ったハードウェアバックアップ暗号化/復号(AES/RSA)の検証方法 私はVerdin i.MX95上でIMX-secure-enclaveライブラリ(https://github.com/nxp-imx/imx-secure-enclave)を使ってNXP EdgeLock セキュア・エンクレーブ(ELE)を扱っています。ハードウェアの暗号エンジンが以下の操作を正しくサポートしていることを実証・検証する必要があります: generateSymmetricKey injectSymmetricKey generatePublicPrivateKeyPair（公開鍵を共有し、秘密鍵を内部に保存します） encrypt(data, keyId) decrypt(data, keyId) 署名 署名を確認する 少なくとも以下の基本アルゴリズムについては、AES (対称)およびRSA (非対称)について 上記のすべての操作をエンドツーエンドで行う推奨テストスイート、サンプルアプリケーション、または参考文献はありますか? これらのプリミティブのハードウェア検証に関する例コード、テスト手順、ドキュメントの参考になると助かります。

Unable to build EASYEVSE Linux image on i.MX93 Hello everyone, I am reading and executing the UG10357 NXP EasyEVSE EV Charging Station Development Platform on EVerest user guide. However I encountered an error when running the bitbake command "bitbake imx-image-everest" (page 12 on the user guide). The problem can be read and seen on the attached screenshot. I believe the issue is related to the EdgeLock SE05x Plug and Trust Middleware version, which the guide is built on version 04.07.01, but NXP only supplies the version 04.08.01. Any idea on how to fix this compatibility problem? Thanks, Rolando Evaluation Board Re: Unable to build EASYEVSE Linux image on i.MX93 Hi @Rolando  Please try to modify this file to match the  EdgeLock SE05x Plug and Trust Middleware version 04.08.01 Zhiming_Liu_0-1787040520433.pngZhiming_Liu_0-1787040520433.png Best Regards, Zhiming

Unprotecting Flash in PB16 Hi, Folks! Please I need to find the way to unsecure the first sector (0xC000 - 0xDFF) of a MC9S08PB16 for to save that are in RAM in this part of the flash using the flash commands described on Chapter 10 of the PB16 Reference Manual. Hope anybody can help me. Regards! Re: Unprotecting Flash in PB16 Hello, Could you help us describe the commands and process you use to protect the memory sector? Are you referring to the commands in Chapter 10.3.5.2 Table 10-4 or the Flash commands in Chapter 10.3.9.1 Table 10-10? Have you set the FPROT register to protect the region in flash memory? Chapter 10.3.8.2 describe the method to unsecure the MCU by erasing the flash memory if that could help you to unsecure the sector. Best Regards, Luis

SEMCのRT1176 チップ（外部DRAM）のクロックピンレベルが正常に動作していません。チップのプログラミングは正常に完了しましたが、クロックピンレベルが変化しないことが判明しました。 コアとメモリ 開発委員会 Re: RT1176 of SEMC こんにちは、@qxy111 さん。 NXPのRTシリーズ製品にご関心をお寄せいただきありがとうございます。喜んでお手伝いさせていただきます。 RT1176のSEMC外部ピンは、NVCC_EMC I/O電源ドメインから給電されます。そのため、SEMC_CLKの出力レベルはNVCC_EMCの電源電圧によって決まります。通常、そのハイレベルは、コア電圧である1.1Vではなく、設計で使用されているNVCC_EMC電圧（例えば1.8Vまたは3.3V）と一致させる必要があります。 まず、以下のハードウェアおよびソフトウェア構成をご確認ください。 1. カスタム開発ボードが正常に電源オンになるかどうか、特にNVCC_EMC1 / NVCC_EMC2電源が正しく機能しているかどうかを確認してください。 2：外部SDRAMのVDD電圧はRT1176のNVCC_EMC電圧と一致していますか？ 3：SEMC関連のピンマルチプレクサとSEMCクロックは正しく初期化されていますか？ 4：SDRAMの初期化パラメータは、実際に使用されているSDRAMデバイスと一致していますか？ さらに、SEMC_CLKは高速クロック信号です。この信号が正常かどうかを判断するためにマルチメーターを使用するのではなく、チップのピン付近でオシロスコープを使用して測定することをお勧めします。 MIMXRT1170-EVKB開発ボードの設計図もご参照いただくことをお勧めします。このボードのSDRAMインターフェースは検証済みであり、回路図やソフトウェア構成の比較検証にご利用いただけます。   よろしくお願いします 5月 Re: RT1176 of SEMC コア1.1V信号をNVCC_EMC電圧まで昇圧することはできません。 Re: RT1176 of SEMC コア1.1V信号をNVCC_EMC電圧まで昇圧することはできません。

RVT70HSTNWC00-B (ILI2132A) 和 MIMXRT1176-evkb 您好， 我目前正在使用MIMXRT1176-EVKB进行一个项目。在这个项目中，我希望在RVT70HSTNWC00-B显示屏上显示一些屏幕，并能够注册触摸坐标。 我已经通过NXP论坛上的另一篇文章获得了一个可以正常工作的屏幕： https://community.nxp.com/t5/i-MX-Processors/Creating-a-driver-for-a-MIPI-LCD/mp/1772322 我唯一的问题是，此显示器的触摸驱动程序（ ILI2132A ）与其他驱动程序（例如 GT911）的工作方式略有不同，但仍然使用 I²C 作为协议，而 SDK 中没有使用此驱动程序的示例。 有没有人有基于 MIMXRT1170 系列芯片的解决方案？ 欢迎提供任何帮助和信息。 提前感谢！ 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） Re: RVT70HSTNWC00-B (ILI2132A) with MIMXRT1176-evkb 嗨@KobeV ， 我们目前没有为 ILI2132A 提供合适的驱动程序，但 RT1170-EVKB 支持 Zephyr，Zephyr 有一个名为“input_ili2132a.c”的触摸 IC 驱动程序（文档， GitHub ）。 考虑到 ILI2132A 触摸 IC 的具体功能已经在该驱动程序中实现，迁移到裸机驱动程序的过程是完全可以实现的。该驱动程序中使用的所有 GPIO 和 I2C 功能在我们的 SDK 中都应该已经有了对应的底层硬件版本，所以我建议迁移或基于该 SDK 创建您自己的驱动程序。 此外，由于 Zephyr 已经支持 RT1170-EVKB，因此您可以使用基于 Zephyr 的项目进行测试场景，以确保驱动程序的功能，并在任何迁移过程之前调试其功能。 BR， 埃德温。

请求提供使用 CodeWarrior Studio 的 LX2080A 裸机参考代码和示例 尊敬的恩智浦技术支持团队： 我目前正在使用NXP Layerscape LX2080A 处理器，并在裸机环境下使用 CodeWarrior Development Studio开发应用程序。 我想请求提供以下内容的任何可用资源、参考项目或示例代码： LX2080A 的裸机启动代码 DDR、时钟和外设的初始化 核心启动和多核示例 用于控制台输出的 UART 驱动程序示例 GPIO 和定时器编程示例 中断处理示例 链接器脚本和内存映射配置 任何与LX2080A裸机开发相关的SDK、应用笔记或文档 CodeWarrior 项目示例专门针对 LX2080A 我的目标是开发和调试没有操作系统的裸机应用程序，任何参考资料或示例项目都将不胜感激。 董事会信息： 处理器：NXP LX2080A 开发环境：CodeWarrior 开发工作室 应用类型：裸机开发 请问是否有针对此用例的推荐文档、存储库、培训材料或社区资源？ 感谢您的支持 赛昌杜 Re: Request for Bare-Metal Reference Code and Examples for LX2080A Using CodeWarrior Studio 你好， CodeWarrior 内置示例项目 安装适用于 QorIQ LS 系列 ARMv8 的 CodeWarrior 后，以下静态/示例项目可直接在 IDE 中使用： 创建裸机项目（新建项目向导） 打开 CodeWarrior IDE →文件 > 新建 > ARMv8 工作站 选择： ARMv8 > 裸板 > Hello World C 项目 构建并调试裸机项目 AMP 多核示例（HelloWorld_C_AMP_Bare） 位于： \CW_ARMv8\ARMv8\CodeWarrior_Examples\HelloWorld_C_AMP_Bare\ 此示例包括： 裸机启动代码（ start.S ） 异常处理程序（ exceptions.c ， exceptions.S ） 链接器脚本可配置 ___DDR_ADDRESS 、 ___MEMORY_SIZE 和 ___CORE_NUMBER SMP/AMP 多核支持 多核提示（LX2160A/LX2080A）：要在 Core 0 和 Core 1 之外的内核上运行，请复制 LX2160A_RDB 目标连接，并为每个附加内核修改目标初始化文件，使用正确的 CORE_CONTEXT 和 SAP_CORE_CONTEXT 。禁用辅助核心的 DDR/PHY 重新初始化。 库项目（源代码可供重新编译） 位于： {CW_ARMv8}\ARMv8\CodeWarrior_Examples\ UART_C_Static_Lib_Bare — 通过 UART 端口提供 printf 支持（注意：此库针对 LS 系列 UART；LX2160A/LX2080A 使用不同的 UART 控制器 — 请参阅下面的注释） 通过在链接器标志中将 simrdimon.specs 替换为 uart.specs ，将半主机 I/O 切换到 UART。 DDR初始化 对于 LX2080A，裸机环境下的 DDR 初始化流程与 LX2160A 相同： QCVS DDRv 工具（与 CodeWarrior 捆绑在一起）用于验证 DDR 并生成 ddr_init.c 生成的代码可用于裸机启动，也可作为基于 ATF 的初始化的参考。 DDR PHY 固件（ fip_ddr.bin ）必须部署在 XSPI 闪存的 0x00800000 处 GPP 动态随机存取存储器(DRAM) 区域 #1 起始地址为 0x0000_8000_0000 ；必须包含区域 #1（依赖于 DPAA/QMAN） 链接器脚本 DDR 配置示例： PROVIDE (___DDR_ADDRESS = 0x80000000); PROVIDE (___MEMORY_SIZE = 0x1effffff); PROVIDE (___CORE_NUMBER = 0); PROVIDE (___START_RAM_ADDRESS = ___DDR_ADDRESS + ___CORE_NUMBER * ___MEMORY_SIZE); LX2080A 上的 UART — 重要提示 LX2080A UART 控制器与 LS 系列处理器中使用的 PrimeCell UART 不向下兼容。内置的 UART_C_Static_Lib_Bare 库仅支持 LS 系列 UART。对于 LX2080A UART 输出，您需要根据 LX2160A 参考手册 UART 寄存器映射或参考 SDK UART 驱动程序示例来实现您自己的驱动程序。 LX2160A/LX2080A UART 相关社区资源： 在裸机项目中通过 UART 使用 printf 比较 CodeWarrior 和 Realtime Edge 构建的裸机环境。 实时边缘软件（裸机框架） NXP 的实时边缘软件包含一个适用于 LX2160ARDB-REV2 的裸机框架（与 LX2080A 设计兼容）： 面向低延迟场景的基于 U-Boot 的裸机框架 包含 GPIO、IPI 和内核间通信示例 可在以下平台获取：实时边缘软件 社区知识库文章：基于裸机框架的实时边缘软件应用开发   此致

CodeWarrior Studioを使用したLX2080Aのベアメタルリファレンスコードとサンプルに関するリクエスト 親愛なるNXPサポートチームへ、 現在は NXP Layerscape LX2080Aプロセッサ を使い、 CodeWarrior Development Studioを使ってベアメタル環境でアプリケーションを開発しています。 以下の内容について、入手可能な資料、参考プロジェクト、またはサンプルコードがあればご提供いただきたいです。 LX2080A用のベアメタル起動コード DDRの初期化、クロック、ペリフェラル コアの起動とマルチコアの例 コンソール出力用のUARTドライバの例 GPIOとタイマーのプログラミング例 割り込み処理の例 リンカースクリプトとメモリマップ構成 LX2080A上でのベアメタル開発に関するSDKsやアプリケーションノート、ドキュメントなど LX080A向けに特化して開発されたCodeWarriorプロジェクトの例 私の目的は、オペレーティングシステムなしでベアメタルアプリケーションを開発・デバッグすることです。参考資料やサンプルプロジェクトがあればぜひ教えてください。 役員情報： プロセッサー:NXP LX2080A 開発環境：CodeWarrior開発スタジオ アプリケーションタイプ:ベアメタル開発 このユースケースにおすすめのドキュメント、リポジトリ、トレーニング・マテリアル、コミュニティリソースがあれば教えてください。 サポートありがとうございます サイ・チャンドゥ Re: Request for Bare-Metal Reference Code and Examples for LX2080A Using CodeWarrior Studio こんにちは、 CodeWarriorに組み込まれているサンプルプロジェクト QorIQ LSシリーズARMv8用のCodeWarriorをインストールすると、以下の 文房具や例プロジェクト がIDE上で直接利用可能です。 ベアメタルプロジェクトの作成（新規プロジェクトウィザード） 新しい>ARMv8文具> CodeWarrior IDE →ファイルを開く 選択: ARMv8 > ベアボード > Hello World Cプロジェクト ベアメタルプロジェクトをビルドしてデバッグする AMPマルチコアの例（HelloWorld_C_AMP_Bare） 場所: \CW_ARMv8\ARMv8\CodeWarrior_Examples\HelloWorld_C_AMP_Bare\ この例には以下が含まれます。 ベアメタル起動コード ( start.S ) 例外ハンドラ ( exceptions.c 、 exceptions.S ) 設定可能な ___DDR_ADDRESS 、 ___MEMORY_SIZE 、 ___CORE_NUMBER を含むリンカースクリプト SMP/AMPマルチコアサポート マルチコアに関するヒント（LX2160A/LX2080A）：コア0とコア1以外のコアで実行するには、 LX2160A_RDB ターゲット接続を複製し、追加する各コアに対して適切な CORE_CONTEXT と SAP_CORE_CONTEXT を使用してターゲット初期化ファイルを変更します。セカンダリコアのDDR/PHY再初期化を無効にします。 図書館プロジェクト（再コンパイル用のソースコードあり） 場所: {CW_ARMv8}\ARMv8\CodeWarrior_Examples\ UART_C_Static_Lib_Bare — UARTポートを通じたprintfサポート(注:このライブラリはLSシリーズUARTを対象としており、LX2160A/LX2080Aは異なるUARTコントローラを使用しています — 下記の注釈参照) セミホストI/OからUARTへの切り替えには、リンカーフラグで simrdimon.specs を uart.specs に置き換える DDR初期化 LX2080Aの場合、ベアメタル環境でのDDR初期化はLX2160Aと同じ手順で行われます。 QCVS DDRvツール（CodeWarriorに同梱）は、DDRの検証と ddr_init.c 生成に使用されます。 生成されたコードは、ベアメタルのスタートアップやATFベースの初期化の参考として利用できます DDR PHYファームウェア（ fip_ddr.bin ）XSPIフラッシュの 0x00800000 番地に配置する必要があります。 GPP DRAM領域#1は 0x0000_8000_0000 から始まります。領域#1を含める必要があります（DPAA/QMANの依存関係）。 リンカースクリプトのDDR設定例： PROVIDE (___DDR_ADDRESS = 0x80000000); PROVIDE (___MEMORY_SIZE = 0x1effffff); PROVIDE (___CORE_NUMBER = 0); PROVIDE (___START_RAM_ADDRESS = ___DDR_ADDRESS + ___CORE_NUMBER * ___MEMORY_SIZE); LX2080AのUARTに関する重要な注意事項 LX2080A UARTコントローラは、LSシリーズプロセッサで使用されているPrimeCell UARTとは後方互換性がありません。内蔵の UART_C_Static_Lib_Bare ライブラリはLSシリーズUARTのみをサポートしています。UART出力LX2080Aには、LX2160A リファレンス・マニュアル UARTレジスタマップやSDK UARTドライバの例を参照して独自のドライバーを実装する必要があります。 LX2160A/LX2080AにおけるUARTに関するコミュニティリソース： ベアメタルプロジェクトでUART経由でprintfを使用する CodeWarriorとRealtime Edgeで構築されたベアメタル環境を比較する リアルタイムエッジソフトウェア(ベアメタルフレームワーク) NXPの Real-Time Edgeソフトウェア には、LX2160ARDB-REV2用のベアメタルフレームワーク(LX2080A設計と互換性があります): 低レイテンシシナリオ向けのU-Bootベースのベアメタルフレームワーク GPIO、IPI、コア間通信の例を含む 入手可能情報: Real-Time Edge Software コミュニティナレッジベース記事: リアルタイムエッジソフトウェアにおけるベアメタルフレームワークに基づくアプリケーション開発   よろしくお願いします。