Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
RT1064 400kHzでのI2C通信異常 RT1064デバイスのI2C2インターフェースはモジュールAに接続されます。通信異常は400kHzで発生しますが、100kHzでは正常に動作します 1. 同じシリーズ内の異なるモデルのモジュールBを400kHzで接続することは問題ありません 2. 波形の観点からは、ホストクロックが伸縮され、モジュールAに接続された後に復元される異常に相当します 追伸:デバイスのI2Cドライバーポートを別の1064デバイスに実装し、モジュールAをテストしましたが、400kで問題ありません その理由は何でしょうか? 1. 図1 モジュールA ロジックアナライザの400kHzにおける異常波形 foreverwlh2025_0-1782181859478.png 2. 図2:モジュールAの100kHzにおけるロジックアナライザの波形 foreverwlh2025_1-1782181977222.png 3. 図3:モジュールBの400kHzにおける波形 foreverwlh2025_2-1782182029028.png i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 追加のご説明ありがとうございます。これは非常に重要な指摘です。   あなたの観察からすると、問題はモジュールA自体の異常というよりも、2段ADUM1251アイソレーションリンクによる400 kHz I2Cのタイミングマージン不足に関連している可能性が高いようです。 ライズ時間が規格内であっても、RT1064ではLPI2Cマスター側の400kHz構成、特にMCFGR2[FILTSCL/FILTSDA]およびMCCR0/MCCR1の確認を推奨します。なぜなら、RT1064のマスター同期レイテンシはライズ時間だけでなく、デジタルフィルターやタイミングパラメータ設定にも影響を受けるからです。 プロジェクトで実際に使用されている構成を読み、RT1064リファレンスマニュアル第47章の表47-5「LPI2C例タイミング構成」と比較することをお勧めします。 特に、選択したクロック条件における以下の設定が、サンプル値と一致しているかどうかを確認してください。 I2Cモジュールクロックソース 目標ボーレート:400Kbps PRESCALE FILTSCL / FILTSDA セソルド クロックロ CLKHI データビデオ お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 追加情報として、昨日ポジショニングにいくつかの進展がありました: ハードウェア拡張は以下の通りです: マザーボード:RT1064--- ADUM1251 3.3V~5V サブボード:ADUM1251 - モジュールA 5V~3.3V 検証の結果、ハードウェアリンクの2層にADUM1251を追加した後、モジュールAで通信異常が発生したことが判明した。しかし、ADUM1251を取り外すと、400kで通信が正常に戻った。その理由は何でしょうか? 追伸:ハードウェアエンジニアは、ADUM1251は通信レイテンシを増加させるだけで、それ以外には影響がないと考えています Re: RT1064 I2C communication abnormality at 400kHz こんにちは、@mayliu1 当社の製品はまもなくリリースされ、数日間この問題を調査してきました。できるだけ早くご返信いただければ、大変ありがたいです! Re: RT1064 I2C communication abnormality at 400kHz ハイ 補足情報 1.2人のハードウェアエンジニアはオシロスコープで問題の波形を確認し、上昇時間は100+ns以内の要件を満たしました 2. I2Cの初期化および読み書き機能ドライバを別のタイプのRT1064デバイスに移植し、モジュールAを問題なくテストしました 以下の図は、別のデバイスモジュールAの波形を示しています。テスト用ロジックアナライザー foreverwlh2025_0-1782194338022.png 疑い: 1.ストレッチ後に時計が異常に回復するなら、他にどんな理由が考えられますか 2. 前回の返信で言及されたMCFGR2のような設定設定専用機能はありますか?I2C初期化プロセスで設定するインターフェースは見当たりませんでした ----上昇時間が満たされた場合、これらのレジスタ設定を考慮する必要はないのでしょうか? Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 これはモジュールAの問題ではなく、その特定のRT1064 LPI2C2バスの400 kHzのタイミングマージンの問題だと思います。 RT1064では、LPI2Cのタイミングはバスの上昇時間、バス負荷、プルアップ抵抗、グリッチフィルタ レイテンシの影響を受けます。 リファレンス・マニュアルRT1064RMでは、上昇時間が長いと同期レイテンシが増加すると説明されています。(第47.3.1.4章を参照)タイミングパラメータ) マスターグリッチフィルターMCFGR2[FILTSCL/FILTSDA]は、**レイテンシ**がSCLの最低ロー/ハイ期間を下回るように設定されなければならず、RT1064はMCCR0/MCCR1の400 kbpsタイミング設定の例を提供しています。表47-5をご確認ください。LPI2Cのタイミング構成例 mayliu1_0-1782186916949.png したがって、モジュールAがバスエッジをわずかに遅くしたり、実効負荷を変えたりすると、バスは400kHzで故障しても100kHzでは動作し続けることがあります。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 10 MHzのLPI2C機能クロックは、RT1064リファレンスマニュアルの400 kbpsのタイミング設定例には記載されていません。 このクロックを使用すれば400kbpsのボーレートを生成することは可能ですが、自動生成されるタイミングパラメータは、特にtLOW、tHIGH、セットアップ/ホールドタイミング、およびデータ有効タイミングに関して、I2C仕様と照らし合わせて慎重に検証する必要があります。 デザインリスクを減らすために、リファレンス・マニュアルに示されている48 MHzなどの検証済みクロックソースを使用することが推奨されています。 Re: RT1064 I2C communication abnormality at 400kHz 以下は印刷設定です。どのパラメータを調整する必要があるでしょうか? 追伸:どうやら自動インターフェース割り当てによるようです foreverwlh2025_0-1782704741259.png Re: RT1064 I2C communication abnormality at 400kHz 60MHzと8MHzの両方を変更してみましたが、それでもうまくいきませんでした。下図の赤い枠で囲まれた部分は、修正後に印刷された値を示しており、マニュアルに記載されている値とは異なっています。 foreverwlh2025_0-1782813239395.png Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 I2Cクロックを設定する方法はいくつかあります。 提案として、8 MHzと60 MHzを試してみるのも良いでしょう。この2つのクロック設定は比較的簡単に達成できます。 SDKのデモを使っています: 「evkmimxrt1064_lpi2c_edma_b2b_transfer_master」 方法1:LPI2Cクロックソースを60MHzに設定する 時計の分周器を0に設定するだけです。 mayliu1_3-1782806044116.png 方法2:LPI2Cクロックソースを8MHzに設定する MCUXpresso IDEsクロックツールを使い、以下の通りに設定してください。クロックソースとしてOSC_CLKを選択し、分周器を3に設定すると、LPI2C(I2C)モジュール用の8MHzクロックが生成されます。 mayliu1_0-1782804733641.png mayliu1_4-1782806209573.png お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 現在のI2Cクロックは、SDK2_13_0-EVK-MIMXRT1064 \ ボード \ evkmimxrt1064 \ river_deamples \ lpi2cディレクトリ内のサンプル構成に基づいて構成されています。 #define LPI2C_CLOCK_SELECT(0U) #define LPI2C_CLOCK_DIVIDER(5U) CLOCK_SetMux(kCLOCK_Lpi2cMux、LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv、LPI2C_CLOCK_DIVIDER); ---正確な8MHzか48MHzをどうやって修正すればいいですか?(時計の木が見えないようですね) Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 レジスタを直接設定してみるのも良いでしょう。 例えば、60 MHzのI2Cクロックを使用する場合、以下の構成を適用できます。 mayliu1_1-1782813580334.png お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 図に示すように、パラメータに対応するようにレジスタ設定を変更しようとしましたが、60MHzでは改善がありませんでした。良いモジュールでも8MHzでは正常に動作しません foreverwlh2025_0-1782882582056.png Re: RT1064 I2C communication abnormality at 400kHz 原因が特定され、問題のあるモジュールではクロックの伸縮が400kHzで発生することになります。 しかし、私たちが使っているアイソレータチップはSCLの双方向に対応していません。アイソレーターチップを交換した後、 検査結果は正常だった。この注文は閉じていけます
查看全文
board.h missing extern C guard This is a bug report. I am using SDK_2.16.000 for the MCXA153. When I use the "Create a new C/C++ project" wizard in MCUXpresso and create a new C++ project, the generated code fails to build because of  undefined reference to `BOARD_InitDebugConsole()' This is because board.h is missing the extern C guard, which can be fixed as follows: #ifdef __cplusplus extern "C" { #endif void BOARD_InitDebugConsole(void); #ifdef __cplusplus } #endif Development Board MCXA Re: board.h missing extern C guard More that a year after you've made a promise, the bug is still there when creating a C++ project in a fresh installation (december, 2025): undefined reference to `BOARD_InitDebugConsole()' Does anyone at NXP is taking care of its customers? Re: board.h missing extern C guard Dear @aberger , Based on your feedback, we have reproduced the issue and have indeed identified the corresponding problem. Thank you for your contribution to the NXP Community with your answer! We have submitted the bug to the relevant team and hope to update the corresponding patch as soon as possible. Best Regard Liu Re: board.h missing extern C guard Hello @fjrg76  Thank you for reporting this issue. I sincerely apologize for my delayed response. In our internal system, once a case has been closed for more than one month, we no longer receive reminders or notifications when new updates are added to the case. I sincerely apologize for any inconvenience this may have caused. Regarding this issue, I will confirm it with our SDK team and get back to you as soon as possible. As a kind reminder, if you have any further questions or concerns in the future, please create a new support ticket. This will allow us to see your request promptly and provide a timely response. Alternatively, you may contact me directly, and I will get back to you as soon as I see your message. Thank you for your understanding and patience. BR Alice
查看全文
PNEV5180B 2.0 PN5180 Altium 原理图 PNEV5180B 2.0 PN5180 原理图是否有 ALtium 格式? 此外,PCB板也很有用,主要用于NFC天线。 我们想使用PN5180,并希望尽快投入使用。 Re: PNEV5180B 2.0 PN5180 Altium Schematics 你好@David-Lightbug 希望你一切都好。 非常抱歉,PN5180 设计文件暂不可用。或许您可以参考PN5180 评估板快速入门指南,其中包含一些显示相关原理图的图片。另外,请参考PN5180天线设计。 如果可能的话,我建议考虑使用PN5190 | NFC 前端进行支付。以下是与PNEV5190BP相关的设计文件: -模块板 底板 问候, 爱德华多。 Re: PNEV5180B 2.0 PN5180 Altium Schematics 您好, 浏览 Altium 原理图,它们似乎都是 BGA 封装/ 你有 PNEV5190M(BGA 封装电路图)和 PNEV5190BP,也是 BGA。 我找到了评估板手册 PNEV5180B,其中显示了 QFN 封装,但没有显示 Altium 文件。 你能帮忙吗? Re: PNEV5180B 2.0 PN5180 Altium Schematics 您好, 感谢您的快速回复。 我将改用PN5190。 该代码是否与 PN5180 兼容/类似?我这样问是因为我注意到有 PN5180 的 Arduino 库,但没有 PN5180 的。 你们有图书馆吗?我们只想尽快启动并开始使用该产品。板设计很可能在两周内完成并制作完成。 谢谢! Re: PNEV5180B 2.0 PN5180 Altium Schematics 您好, 我们提供适用于 PN5190 的NFC读取器库。该库是为 NXP 产品组合中的一些主机 MCU 设计的,例如 LPC1769 和 Kinetis K82;将功能移植到第三方平台不在我们的支持范围内,必须完全由客户完成。您可以参考以下文章,并将其作为移植工作的参考: -将 NFC 阅读器库与 LPC55S69 结合使用 - NFC读取器库移植 FRDM_K64F -将 NFC 阅读器库移植到 i.MX RT1050 - NXP 社区 PN5190 的可用设计文件基于我们的开发板 ( PNEV5190BP ),该开发板嵌入了 BGA 封装。VFLGA40 封装也有一个参考设计:模块板 PN5190 HVQFN 设计文件;但是,该文件的目的是说明此特定封装所需的连接。 问候, 爱德华多。
查看全文
8M以上のリアルタイム精度について こんにちは。8M Plusのリアルタイムアプリケーションに関する機能について、さらに詳しく知りたいと思います。TSNやリアルタイムパフォーマンス、ジッターに関するテストレポートや関連資料はありますか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy エリア 入手可能な資料 内容物 リアルタイムCPU/RTOSレイテンシ ハープーンユーザーガイド  i.MX 8M Plus / Zephyr でリアルタイムレイテンシを測定し、IRQレイテンシやタスクレイテンシ(ns単位)も含まれます。例としての結果:no-load IRQ レイテンシ min/avg/max/stddev = 625 / 796 / 11,125 / 1,798 ns タスクレイテンシ = 2,583 / 2,671 / 13,041 / 6,045 ns 。Linux CPU + メモリ負荷の場合、IRQレイテンシ= 625 / 798 / 4,250 / 4,674 ns 、タスクレイテンシ= 2,583 / 2,670 / 14,333 / 10,407 ns です。 リアルタイムベンチマーク方法 Harpoon ユーザーガイド — RT レイテンシアプリケーション ベンチマークをハードウェアIRQイベントとソフトウェア動作間の時間差と定義し、ハードウェアタイマーとサブマイクロ秒単位の精度で測定します。 TSNの能力 i.MX 8M Plus製品/リファレンスマテリアル i.MX 8M PlusはデュアルGbイーサネットを搭載し、そのうち1つはTSNに対応し、産業用リアルタイム制御には統合 800 MHzのArm Cortex-M7 を使用します。 TSNハードウェア規格 i.MX 8M プラスリファレンスマニュアル TSNのサポートには 、IEEE 802.1Qbv Time-Aware Shaper 、 802.1Qav Credit-Based Shaper 、 IEEE 1588v2 PTP 、およびイーサネットブロック実装 802.1Qbv-2015が含まれます 、 802.3br 、 そして 802.1Qbu フレームプリエンプション関連のTSN関数。 TSNテスト/検証環境 リアルタイムエッジユーザーガイド トラフィック生成・解析およびレイテンシ、ジッター、同期精度の監視を含む8M Plus TSNの能力を評価するためのTSNテスト環境 i.MX 説明します。 TSNジッター/レイテンシの例 リアルタイムエッジユーザーガイド — TSNエンドポイントサンプルアプリ トラフィックの最小/平均/最大レイテンシやノート レイテンシは約503μs と レイテンシ ジッターは約300 ns を含むTSNエンドポイント統計を提供します。 TSNアプリケーションデモ AN13588 GenAVB/TSNのリアルタイム制御アプリケーションを実証します。これは 2ミリ秒サイクル  、400μsの予約/保証制御トラフィックウィンドウ 、スケジューリング、プロセッシングタイミング、トラフィックの正確性、レイテンシのための統計スレッドを記述しています。 TSN 802.1Qbv デモ AN13995 8M Plus i.MX を用いたTSN 802.1Qbvの実演と、時間認識シェーピングが固定リピーティングサイクルを用いてデターミニスティックなレイテンシを提供する方法を説明しています。また、Linux  tc  /  taprio  configurationの例も含まれています。   Re: Regarding 8M Plus Real time Accuracy @yipingwang 情報を提供していただきありがとうございます。iMX8M Plus EVKについても情報を教えていただけますか? ありがとうございます。 Re: Regarding 8M Plus Real time Accuracy i.MX95 EVKに関する公式な「リアルタイム性能レポート」は公開されていないことを承知しております。しかし、NXPはi.MX95プラットフォーム上でリアルタイムのベンチマークを内部で行っています。内部ベンチマーク文書によると、cyclictestおよびEtherCATのパフォーマンス評価は、Linux上でリアルタイムエッジソフトウェアを実行するi.MX95 LPDDR5 EVK上で実施PREEMPT_RTされています。報告された例としては、6時間のストレスNGテストにおける最大周期テスト**レイテンシ**約38μsや、EtherCATのフィルタによる最大ジッター約12μsが報告されています。リアルタイム性能はBSPバージョン、カーネル構成、CPU分離、ワークロード、ネットワークトラフィックに大きく依存するため、これらの値はアプリケーションレベルの保証された制限ではなく、参照の測定とみなすべきです。   詳細については、 https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdfを参照してください。 サポートされるベンチマークプラットフォームとして、詳細なサイクリックテスト、ストレス、rt_latency手順を提供します。 Re: Regarding 8M Plus Real time Accuracy 代理店からは、NXP i.MX95 EVKのリアルタイムパフォーマンスやジッターに関する公式なパフォーマンスレポートは現在存在しないと伝えられました。 しかし、リアルタイムレイテンシを評価するためのテスト手法(例:cyclictest)についてのドキュメントも提供しました。 これは我々の側で多少の混乱を招いている。標準化されたテスト手法が存在することから、そのようなテストは少なくともリファレンスEVKプラットフォーム上で内部で実施されたと仮定します。 したがって、以下の点を明確にしたいと思います。 NXPはi.MX95 EVKのリアルタイム性能(例:レイテンシ、ジッター)の内部測定を行ったことはありますか? もしそうなら、共有できる参考や基準の結果はありますか? リアルタイムのパフォーマンスは、システム構成やワークロードによって変動する可能性があることを理解しています。しかし、管理された条件下(例えば、デフォルトのBSP、最小負荷)でのベースライン結果であっても、初期評価には非常に役立つだろう。 再開まで今しばらくお待ちください。 hankwang_0-1784018178178.png Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (リアルタイムエッジソフトウェアユーザーガイド)(https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf) .リアルタイムエッジソフトウェア(最も関連性が高い) NXPの Real-Time Edgeソフトウェア は公式にi.MX8M Plus EVKをサポートし、以下を含みます: PREEMPT_RT Linux TSNスタック IEEE 802.1AS (gPTP) 同期 TSNトラフィックシェーピングとスケジューリング EtherCAT、OPC-UA、CAN関連の産業用プロトコル Cortex-A53 + Cortex-M7を用いた異種リアルタイム動作 内部文書 REALTIMEEDGEUG によると、Real-Time Edge Softwareは以下の機能を提供します: リアルタイムネットワーキング(TSN) リアルタイムLinux(PREEMPT_RT) 純粋なRTOS/ベアメタルオプション 刑務所の仕切り インダストリアルプロトコルサポート i.MX 8M Plus LPDDR4 EVKのサポート NXPアプリケーションノート AN13995 – i.MX 8M Plusを用いたTSN 802.1Qbvデモンストレーション リアルタイムエッジのSix Pack資料(PREEMPT_RT+TSNサポートを説明する) Re: Regarding 8M Plus Real time Accuracy @yipingwang情報を提供していただき、本当にありがとうございました。
查看全文
PWM Capture can't work in frdm_mcxw72 board Hi, I tried to practice the pwm capture sample in  frdm_mcxw72 board, but unfortunately, the print message in serial tool only show " capture cycle err -134" . I'm sure there is the 1Khz, 50% duty cycle pwm signal inject into the PTA21 pins in frdm_mcxw72 board. i imported the whole project files from the demo case,  there is no change that i only added the overlay file,   below is the overlay files setting. anliu114036_0-1783501416708.png can you help check the reason why there is no correct print information. thanks in advance! Re: PWM Capture can't work in frdm_mcxw72 board Hello, Hope you are doing well. Could you please clarify what Zephyr repo are you using? Also, are you starting from any of the examples? Did you modify something? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo, The repo version is V4.4.1.0,  below is the my steps  1. Import the capture example application from the repo anliu114036_0-1783644698775.png  2. Add the  DTS overlay file in the board folder, the content of the overlay file  posted in first message. 3. build and flash into the frdm_mcxw72 board in my hand,  the print message is  "capture cycle err" ,  it looks the board state is ok because i didn't inject the pwm signal , but the print message is the same after the pwm signal injected into PTA21 pins.     Re: PWM Capture can't work in frdm_mcxw72 board Hello, Could you please clarify what repository are you using? Are you using Upstream or Downstream? Also, is the example working on your side without modifications? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo here is the repo version  anliu114036_0-1783902527295.png i only update the overlay file,  it will be  can't build successfully if there is no this file. Best regards! Re: PWM Capture can't work in frdm_mcxw72 board Hello, Could you please clarify if you are using Upstream or Downstream? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo, Sorry, i didn't very understand  what's the "Upstream" or "Downstream" here . i guess it should be the downstream. or can you change another description?
查看全文
IMXRT LPUARTの非ブロッキング転送APIはエラー処理を困難にする こんにちは、 私は、割り込みベースのノンブロッキング転送を行うためのLPUARTの「転送」APIについて調べています。LPUART割り込みなどの「ハッピーケース」処理をうまくラップし、準備ができたときにだけデータを受信できる良い高水準APIを提供しているようです。アイドル状態、受信準備完了、送信完了などの処理。しかし、これによってUARTエラーの処理が非常に困難になる。 LPUART_TransferHandleIRQ関数内にはエラー処理がなく、fsl_lpuart.cのその関数の直後には「ユーザーによって実装される」というコメントを含む偽の空LPUART_TransferHandleErrorIRQがあります。これは完全に未完成に見える。 UARTエラーを実際に処理する唯一の方法は、デフォルトのLPUARTx_IRQHandler関数を上書きし、LPUARTx_RX_DriverIRQHandler(またはTX)を呼び出す代わりに、自分でエラーを処理し、「ハッピーCASE」割り込みを元のLPUARTx_RX/TX_DriverIRQHandlerに渡してLPUART_TransferHandleErrorIRQに呼び出すようにすることのようです。 さらに、転送APIの外部でLPUART_EnableInterruptsを呼び出してエラー割り込みを自分で有効にし、エラー処理の中でLPUART_DisableInterruptsを呼び出してそれらをクリアするなどの処理を行う必要があります。 エラー処理にこれだけの手間をかけるのは、かなり面倒な作業のように思える。なぜこの機能が転送API自体に組み込まれていないのでしょうか? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 詳細なフィードバックをありがとうございます。SDKは各ペリフェラル機能の共通ユースケースを提供するためのものなので、少し曖昧な部分もあることは理解しています。このようなご意見も参考にしながら、私たちは常にAPIの改善に取り組んでいます。ご提案ありがとうございます。今後のリリースでもLPUARTのエラー処理が実装されることを願っています。 一方で、どのエラー条件を扱いたいのか、どのデバイスを使っているのか教えていただけますか?その情報をもとに、実装に役立つエラー条件に関するドキュメントを提案できます。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 考えられるすべてのエラー。これは、転送APIはあるがエラー処理がないほぼすべてのペリフェラル(SPI、I2Cなど)に当てはまります。IMXRT1172のLPUARTには、特にフレーミングエラー、パリティエラー、ノイズエラーがあり、これらは適切に処理されていません。残念ながら現状、これらのペリフェラルは転送API使用時のエラー処理にハッキングが必要です。SDKハンドラーを呼び出す前に、エラーを確認するために実際のデフォルトのIRQハンドラをオーバーライドしなければなりませんでした。 ありがとうございます -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 追加の開発期間が必要になる可能性があることは理解していますが、SDKsの改善に引き続き取り組んでいます。参考として、SDK(バージョン26.6)の関数「LPUART_TransferHandleIRQ」の構造を確認し、アプリケーションが必要とする類似の回復フローを実装できます。 Habib_MS_1-1784062752001.png BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 他に質問がありましたら、お気軽にお知らせください。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult はい、既に似たようなものを実装しています。送っていただきありがとうございます。
查看全文
RT1064 I2C 通信异常,频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常,但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看,这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS:将该设备的 I2C 驱动程序移植到另一台 1064 设备上,测试模块 A,在 400k 功耗下未发现问题。 原因可能是什么? 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 foreverwlh2025_0-1782181859478.png 图 2:模块 A 在 100kHz 下的逻辑分析仪波形 foreverwlh2025_1-1782181977222.png 图3:模块B在400kHz时的波形 foreverwlh2025_2-1782182029028.png i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察,该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足,而不是模块 A 本身的异常。 即使上升时间在规格范围内,在 RT1064 上,我们仍然建议检查 LPI2C 主侧 400 kHz 配置,特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1,因为 RT1064 上的主同步延迟不仅受上升时间的影响,还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置,并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符: I2C模块时钟源 目标波特率:400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息:昨天在定位方面取得了一些进展: 我们的硬件扩容计划如下: 主板:RT1064--- ADUM1251 3.3V 至 5 V 子板:ADUM1251-模块A 5V转3.3V 经验证,在硬件链路的两层中添加 ADUM1251 后,模块 A 的通信出现异常。但移除 ADUM1251 后,通信在 400k 处恢复正常。造成这种情况的原因可能是什么? PS:我们的硬件工程师认为 ADUM1251 只会增加通信延迟,不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好,@mayliu1 我们的产品即将发布,我们已经调查这个问题好几天了。如果您能尽快回复,我们将不胜感激! Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形,上升时间符合要求,在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备,并测试了模块 A,没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 foreverwlh2025_0-1782194338022.png 怀疑: 1.如果时钟在拉伸后恢复异常,还有哪些其他原因可能导致这种情况? 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置?我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求,我们是否就不需要考虑这些寄存器设置了? Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 , 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题,而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上,LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出,上升时间越大,同步延迟就越高。(参见第 47.3.1.4 章)时序参数) 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置,使其延迟保持在最小 SCL 低/高周期以下,RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 mayliu1_0-1782186916949.png 因此,如果模块 A 使总线边沿稍微变慢或改变有效负载,则总线可能在 400 kHz 时发生故障,但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率,但应根据 I2C 规范仔细验证自动生成的定时参数,特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险,建议使用经过验证的时钟源,例如 48 MHz,如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数? PS:显然是由于自动接口分配造成的 foreverwlh2025_0-1782704741259.png Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 您可以尝试直接设置寄存器。 例如,当使用 60 MHz I2C 时钟时,可以采用以下配置。 mayliu1_1-1782813580334.png 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 当前的 I2C 时钟是基于 SDK2_13_0-EVK-MIMXRT1064 板 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c 目录中的示例配置进行配置的。 #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); 我该如何修改才能获得精确的 8MHz 或 48MHz 频率?(时钟树似乎看不见) Re: RT1064 I2C communication abnormality at 400kHz 我尝试将频率修改为 60MHz 和 8MHz,但仍然无效。下图中的红色方框显示的是修改后打印的值,这些值与手册中的值不同。 foreverwlh2025_0-1782813239395.png Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 配置 I2C 时钟有多种方法。 建议您尝试 8 MHz 和 60 MHz,因为这两个时钟设置相对容易实现。 我正在使用 SDK 演示版: "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" 方法一:将 LPI2C 时钟源配置为 60 MHz 只需将时钟分频器设置为 0 即可。 mayliu1_3-1782806044116.png 方法二:将 LPI2C 时钟源配置为 8 MHz 使用 MCUXpresso IDE 时钟工具并按如下所示进行配置。选择 OSC_CLK 作为时钟源,并将分频器设置为 3,这将为 LPI2C (I2C) 模块生成 8 MHz 时钟。 mayliu1_0-1782804733641.png mayliu1_4-1782806209573.png 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 如图所示,我尝试修改寄存器设置以匹配参数,但在 60MHz 下性能没有提升;即使是性能良好的模块在 8MHz 下也无法正常工作。 foreverwlh2025_0-1782882582056.png Re: RT1064 I2C communication abnormality at 400kHz 原因已查明,出现问题的模块将在 400k 时出现时钟拉伸现象。 但是我们使用的隔离器芯片不支持 SCL 双向。更换隔离芯片后, 测试结果正常;此订单可以结案。
查看全文
board.h に extern C ガードがありません これはバグレポートです。MCXA153にはSDK_2.16.000を使用しています。MCUXpressoの「新しいC/C++プロジェクトの作成」ウィザードを使用して新しいC++プロジェクトを作成すると、生成されたコードがビルドに失敗します。 `BOARD_InitDebugConsole()' への未定義の参照 これは board.h に extern C ガードが欠落しているためです。これは次のように修正できます。 #ifdef __cplusplus extern "C" { #endif void BOARD_InitDebugConsole(void); #ifdef __cplusplus } #endif 開発ボード MCXA Re: board.h missing extern C guard 約束してから 1 年以上経ちましたが、新規インストールで C++ プロジェクトを作成すると、バグはまだ存在します (2025 年 12 月)。 `BOARD_InitDebugConsole()' への未定義の参照 NXP ではお客様のケアをしている人っているのでしょうか? Re: board.h missing extern C guard 親愛なる@aberger様、 お客様のフィードバックに基づいて問題を再現し、対応する問題を特定しました。 回答を NXP コミュニティにご提供いただき、ありがとうございます。このバグは関連チームに提出済みであり、対応するパッチをできるだけ早く更新したいと考えています。 よろしくお願いいたします LIU Re: board.h missing extern C guard こんにちは、 @fjrg76さん この問題を報告していただきありがとうございます。返信が遅くなり、大変申し訳ございませんでした。 当社の社内システムでは、CASEが1か月以上クローズされると、新たな更新が加わった際にリマインダーや通知を受け取ることはありません。ご迷惑をおかけしましたことを心よりお詫び申し上げます。 この問題については、SDKチームに確認し、できるだけ早くご連絡いたします。 念のためお伝えしますが、今後さらに質問や懸念があれば、新しいサポートチケットを作成してください。これにより、お客様のご要望を迅速に確認し、タイムリーな対応が可能になります。または、直接私にご連絡いただければ、メッセージを受け取り次第すぐにご連絡いたします。 ご理解とご辛抱に感謝いたします。 BR アリス
查看全文
RT1064 I2C communication abnormality at 400kHz The I2C2 interface of the RT1064 device connects to Module A. Communication anomalies occur at 400kHz, but it functions properly at 100kHz 1. Connecting module B of a different model within the same series at 400kHz is no problem 2. In terms of waveform, it is equivalent to an anomaly occurring when the host clock is stretched and then restored after connecting to Module A PS: Implement the I2C driver port of the device to another 1064 device, test module A, no issues at 400k What might be the reason? 1. Figure 1 Module A Abnormal Waveform of Logic Analyzer at 400kHz foreverwlh2025_0-1782181859478.png 2. Figure 2: Waveform of Logic Analyzer for Module A at 100kHz foreverwlh2025_1-1782181977222.png 3. Figure 3: Waveform of Module B at 400kHz foreverwlh2025_2-1782182029028.png i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , Thanks for the additional clarification — this is a very important observation.   From your observations, the issue appears more likely to be related to insufficient 400 kHz I2C timing margin caused by the two-stage ADUM1251 isolation link, rather than an abnormality of Module A itself. Even if the rise time is within spec, on RT1064, we still recommend checking the LPI2C master-side 400 kHz configuration, especially MCFGR2[FILTSCL/FILTSDA] and MCCR0/MCCR1 , because the master synchronization latency on RT1064 is affected not only by rise time, but also by the digital filter and timing parameter settings. We suggest reading out the actual configuration used in your project and comparing it with Table 47-5, “LPI2C Example Timing Configurations,” in Chapter 47 of the RT1064 Reference Manual . In particular, please check whether the following settings match to the example values for your selected clock condition: I2C module clock source Target baud rate: 400Kbps PRESCALE FILTSCL / FILTSDA SETHOLD CLKLO CLKHI DATAVD Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Additional information, there was some progress in positioning yesterday: Our hardware expansion is: Motherboard: RT1064--- ADUM1251    3.3 V to 5 V Subboard: ADUM1251- Module A          5v to 3.3v After verification, it was found that after adding ADUM1251 to the two layers of the hardware link, module A had abnormal communication. However, after removing it, communication returned to normal at 400k. What could be the reason for this? PS: Our hardware engineers believe that ADUM1251 only increases communication latency and has no other impact Re: RT1064 I2C communication abnormality at 400kHz Hi,@mayliu1 Our product is about to be released, and we have been investigating this issue for several days. If we could receive your response as soon as possible, we would greatly appreciate it! Re: RT1064 I2C communication abnormality at 400kHz Hi  Supplementary information 1. Our two hardware engineers checked the waveform of the problem through an oscilloscope, and the rise time met the requirements, within 100+ns 2. I ported I2C initialization and read-write function drivers to another type of RT1064 device,  and tested module A without any issues The following figure shows the waveform of another device module A testing logic analyzer foreverwlh2025_0-1782194338022.png doubt: 1. If the clock recovers abnormally after stretching, what other reasons could be causing it 2. Is there a dedicated function to set settings such as MCFGR2 mentioned in the last reply? I didn't see any interface to be set in the I2C initialization process ----If the rise time is met, do we not need to consider these register settings? Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , Thank you so much for your interest in our products and for using our community. I think that this is most likely not a Module A issue, but a 400 kHz timing-margin issue on that specific RT1064 LPI2C2 bus. On RT1064, LPI2C timing is affected by bus rise time, bus loading, pull-up resistors, and glitch-filter latency.  RT1064RM  reference manual describe  that larger rise time increases synchronization latency.  (refer to chapter 47.3.1.4 Timing Parameters) The master glitch filters MCFGR2[FILTSCL/FILTSDA] must be set so their latency stays below the minimum SCL low/high period, and RT1064 provides example 400 kbps timing settings in MCCR0/MCCR1 .  Please check the Table 47-5. LPI2C Example Timing Configurations mayliu1_0-1782186916949.png So if Module A makes the bus edges slightly slower or changes the effective loading, the bus may fail at 400 kHz but still work at 100 kHz .  Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Below is the configuration for printing. Which parameter may need to be adjusted? PS:apparently due to automatic interface allocation foreverwlh2025_0-1782704741259.png Re: RT1064 I2C communication abnormality at 400kHz A 10 MHz LPI2C functional clock is not listed in the RT1064 Reference Manual example timing configurations for 400 kbps. Although it is possible to generate a 400 kbps baud rate with this clock, the automatically generated timing parameters should be carefully verified against the I2C specification, particularly with respect to tLOW, tHIGH, setup/hold timing, and data valid timing. To reduce design risk, it is recommended to use a validated clock source, such as 48 MHz, as shown in the Reference Manual. Re: RT1064 I2C communication abnormality at 400kHz I tried modifying 60MHz and 8MHz, but it still didn't work. The red box in the figure below shows the values printed after modification, which are different from the manual foreverwlh2025_0-1782813239395.png Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , There are several ways to configure the I2C clock. As a suggestion, you can try 8 MHz and 60 MHz, as these two clock settings are relatively easy to achieve. I am using the SDK demo: "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" Way 1: Configure LPI2C clock source to 60 MHz Simply set the clock divider to 0. mayliu1_3-1782806044116.png Way 2: Configure LPI2C clock source to 8 MHz Use the MCUXpresso IDE Clock Tool and configure it as shown below. Select OSC_CLK as the clock source and set the divider to 3, which will generate an 8 MHz clock for the LPI2C (I2C) module. mayliu1_0-1782804733641.png mayliu1_4-1782806209573.png Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , You may try setting the registers directly. For example, when using a 60 MHz I2C clock, the following configuration can be applied. mayliu1_1-1782813580334.png Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz The current I2C clock is configured based on the sample configuration in the SDK2_13_0-EVK-MIMXRT1064 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c directory, #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); ---How can I modify it to obtain the precise 8MHz or 48MHz? (The clock tree doesn't seem to be visible) Re: RT1064 I2C communication abnormality at 400kHz As shown in the diagram, I tried to modify the register settings to correspond to the parameters, but there was no improvement at 60MHz; Even good modules cannot function properly at 8MHz foreverwlh2025_0-1782882582056.png Re: RT1064 I2C communication abnormality at 400kHz The cause has been identified, and the module with the problem will experience clock stretching at 400k. However, the isolator chip we are using does not support SCL bidirectional. After replacing the isolator chip, the test was normal; This order can be closed
查看全文
Behavior of PMIC using external Watchdog (Wdg_43_VR5510) I have implemented the external watchdog (Wdg_43_VR5510) for PMIC. But it is going into endless loop in Pmic_VR5XX_TimeoutLoops_StateTransistion (refer below). SagarZala_1-1728467272425.png Currently it is in INIT_FS state, as per the state diagram it says we need to have a good watchdog refresh to change the state from INIT_FS to Wait_ABIST2. image (7).png To Satisfy the first good watchdog refresh within 256ms, we have called watchdog trigger API after Wdg_43_VR5510_Init function during EcuM Initialization. image (8).png We need to know, how and where to call the first watchdog refresh. So that the state transition happens from INIT_FS to wait_ABIST2. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello @Jerry_cao , Thank you for contacting us. However, the original post has been closed for nearly two years, so we are unable to continue supporting you under that thread. Please create a new post for your issue on S32G - NXP Community, and our team will be happy to assist you further. BR Celeste Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello NXP team, I'm currently debugging the VR5510 PMIC and have run into a real-time scheduling issue related to the watchdog refresh. The MCAL I2C watchdog refresh (feeding the VR5510 watchdog over I2C) is implemented as a synchronous operation. Because we call it from within an interrupt context, the synchronous wait blocks the CPU and degrades the real-time scheduling of other tasks. I noticed there is an asynchronous option in the driver configuration/code. However, in practice it still performs a synchronous busy-wait (it blocks and polls until the I2C transfer completes), so it does not actually decouple the transfer from the caller. My questions: Is there an officially supported way to make the VR5510 watchdog refresh truly non-blocking (e.g. interrupt-driven or DMA-driven I2C), so that it does not stall other tasks? If the asynchronous option is expected to be non-blocking, is the current synchronous busy-wait behavior a known limitation or a configuration issue on my side? Any guidance, reference configuration, or example code would be greatly appreciated. Thank you. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello SagarZala, I wonder if you have tried the two out-of-the-box examples in S32 Design Studio (S32DS)? Will they have the same problem? May be they are very good references for you. Celeste_Liu_0-1729049570948.png Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hi, Thanks for the reply. I am using RTD version 4.0.2. I have already configured the I2C at high speed and WD_WINDOW is also configured at 1024ms. But still its not working. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Dear @SagarZala , Thank you for your question. VR5510 is commonly paired with the S32G microprocessor. For this, the available drivers for VR5510 should be provided under the S32G RTD packages. Which RTD version are you using and which specific example is it? Taking the RTD 4.0.0 version as an example, you can find the documents "RTD_WDG_43_VR5510_IM" and "RTD_WDG_43_VR5510_UM" under the path C:\NXP\SW32G_RTD_4.4_4.0.0\eclipse\plugins\Wdg_43_VR5510_TS_T40D11M40I0R0\doc. The document "RTD_WDG_43_VR5510_UM" describes more detail. It is worth mentioning that the watchdog is triggered via the I2c command and it depends on the I2c speed. When the I2c speed is low, the watchdog may not be triggered successfully within the watchdog's window open time. To avoid this problem, we recommend that the user configure I2c with high speed and use a large window period when it is enabled. To set the watchdog refresh, you can configure the WD_WINDOW [3:0] to obtain the refresh time. As shown in the following figure: Celeste_Liu_0-1728636341767.png Refer to "Document VR5510 Product data sheet", page 60, Table 45. Watchdog window period configuration, as shown in the screenshot below. And after setting the correct WD period time, you need to correctly feed the WD. Celeste_Liu_4-1728636786838.png Celeste_Liu_5-1728636805408.png Hope the above information is helpful to you. Best Regards, Celeste
查看全文
S32DS 3.6.7 RTD 7.0.1 P02 HSE 代码生成错误 我正在尝试使用S32DS 3.6.7为S32K358生成与 HSE 相关的 RTD 代码,但我遇到了一个问题。 首先,我按以下顺序安装了以下更新站点: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip 安装状态如下图所示。 wodudwo_1-1784020530765.png wodudwo_0-1784020518071.png 接下来,我通过选择下面显示的 SDK 创建了一个新项目。 wodudwo_2-1784020561794.png 然后,我在配置工具中添加了BaseNXP和Hse组件,如下所示。 wodudwo_3-1784020582815.png 但是,出现以下验证错误: Issue: Hse is not found in the toolchain/IDE project. The project will not compile! Level: Error Type: Validation Tool: Toolchain/IDE project Origin: Peripherals Target: Toolchain/IDE project: M7_0_0 Resource: platform.driver.Hse 我该如何解决这个问题并成功生成与 HSE 相关的 RTD 代码? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 你好, 我尝试安装了以下软件包后生成代码,但仍然遇到同样的验证错误。 wodudwo_1-1784074948979.png wodudwo_2-1784074960671.png wodudwo_3-1784074969264.png wodudwo_0-1784074933867.png 按照您的建议,我首先卸载了所有与RTD相关的扩展程序,然后只安装了以下软件包: - SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip 安装状态如下所示。 wodudwo_4-1784075002029.png wodudwo_5-1784075010124.png 但是,这样做之后,我在创建新项目时就无法再选择任何 SDK 了,如下图所示。 wodudwo_6-1784075045680.png 我应该如何解决这个问题? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 嗨@wodudwo 为了验证是否缺少软件包,请将您 IDE 中安装的软件包与下图所示的软件包进行比较? VaneB_0-1784059529950.png 此外,我们来尝试卸载所有与 S32K3 RTD 相关的软件包,然后只重新安装名称中包含“P02”的软件包。 BR,VaneB Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 嗨@wodudwo 我认为安装步骤中可能缺少某个步骤。以下是我成功安装软件包的步骤: 由于您已经安装了一些软件包,我建议您首先卸载所有与 S32K3 设备 RTD 相关的软件包,包括 S32K3 和 S32M 设备的 S32 配置工具 R1.8 NPI 数据包,因为这些软件包依赖于 RTD 软件包。 - 添加以下更新站点: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite_updated_D20260630.zip - 选择并安装名称中包含 P02 的软件包。允许 S32DS 自动选择并安装安装所需的任何其他依赖软件包。 - 等待安装成功完成,并允许 S32DS 重新启动。 - 重启后,选择并安装所有适用于 S32K3 和 S32M 设备的 S32 配置工具 R1.8 NPI 数据包组件。再次允许 S32DS 自动选择任何所需的依赖项。 - 等待安装成功完成,然后让 S32DS 再次重新启动。 按照这些步骤操作后,我的 IDE 中最终安装了六个 RTD 7.0.1 软件包(包括 P02)。通过这种设置,我可以将 HSE 驱动程序添加到我的项目中,而不会出现任何问题。 VaneB_0-1784154210318.png
查看全文
PNEV5180B 2.0 PN5180 Altium Schematics Are the PNEV5180B 2.0 PN5180 schematics available in ALtium format ? ALso PCB would be useful , mainly for the NFC antenna. We want to use the PN5180 and want to get  up and working asap Re: PNEV5180B 2.0 PN5180 Altium Schematics Hello @David-Lightbug Hope you are doing well. Please accept my apologies, PN5180 design files are not available. Perhaps you could refer to the PN5180 Evaluation board quick start guide, which includes some pictures showing the relevant schematics. Also, please refer to the PN5180 Antenna design. If possible, I will recommend considering PN5190 | NFC Frontend for payment. Following design files related to PNEV5190BP are available: - Module board - Base board Regards, Eduardo. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, Going through the altium schematics , they all appear to be the BGA package/  You have the PNEV5190M  (BGA packagein cct diagram) and   PNEV5190BP also BGA. I have found the evaluation board manual, PNEV5180B that shows the QFN package but not the altium files. Can you help. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, We offer a NFC Reader Library for PN5190. This library is designed for some Host MCUs from NXP's portfolio, such as LPC1769 and Kinetis K82; porting the functionality to a third-party platform is out of our support and must be done entirely by the customers. You can refer to the following articles and use them as a reference for the porting: - Using NFC Reader Library with LPC55S69 - NFC Reader Library Porting FRDM_K64F - NFC Reader Library Porting to i.MX RT1050 - NXP Community The available design files for PN5190 are based on our Development Board (PNEV5190BP), which embeds the BGA package. There is also a reference design for the VFLGA40 package: Module board PN5190 HVQFN design files; however, the purpose of this file is to illustrate the required connections for this specific package. Regards, Eduardo. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, Thanks for your quick reply. I will change to use the PN5190. Are the code compatible/ similar to the PN5180 , the reason I am asking is that I have noticed there are Arduino libraries  for the PN5180 but not the PN5180. DO you have libraires - we just want to get up and going quickly with the product.  The board design is likely to be ready and made in less than two weeks. Thanks
查看全文
已安装 HSE 的 S32K311:软件崩溃和 MCU RESET,调试器无法连接 您好,NXP团队, 背景: MCU: S32K311 AUTOSAR RTD MCAL: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 HSE 固件(全内存): s32k3x1_hse_fw_0.12.0_2.55.0_pb250225.bin 完整调查报告以PDF格式附件形式提供。 主要问题 软件在 Clock_Ip_DistributePll() 中崩溃,MCU RESET。此外,调试器有时无法附加。 当我尝试热连接调试器时,复位原因有时会报告为 HSE_CLK_FAIL。 请您主要检查上述流程、IVT 和 DCF 记录,以及有关此问题发生原因及其解决方案的信息。如有任何其他需要的信息,请告知我们。 请您检查 HSE 安装程序、IVT 配置和 DCF 记录,并告知出现此问题的原因以及如何解决? 如有任何其他信息需要提供,请告知我们。 此致, 舒巴姆·帕德西 Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 提到的 70 秒和 20 秒是从 RESET 到 HSE_STATUS_INIT_OK 的时间。所以基本上只包含启动时间,对吗? 在所有设备上的表现都一样吗? Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 你好@davidtosenovjan 我们的软件由 FBL 和 APPL 组成,两者都使用相同的功能复位机制。 当 APPL 发起复位时,不会出现此问题。 当 FBL 发起 RESET 时,软件在 APPL 启动期间于 Clock_Ip_DistributePll() 内部崩溃。 最初,我们在 Mcu_InitClock() 之后、Mcu_DistributePllClock() 之前添加了对 HSE_STATUS_INIT_OK 的检查。这样就避免了车祸。然而,大约 20 秒后 HSE_STATUS_INIT_OK 才被设置,之后 APPL 的实际启动才继续进行。 今天,我们将 HSE_STATUS_INIT_OK 检查移到了 APPL 中的 Mcu_Init() 之前的更早阶段,如附图所示。 Shubham_MQ_0-1784123821324.png 通过此序列,HSE_STATUS_INIT_OK 几乎立即被设置,并且不再观察到崩溃。 请问您能否澄清以下问题? 为什么只有当 FBL 发起 RESET 时才会出现这个问题,即使 FBL 和 APPL 使用的是相同的 RESET 机制? 为什么在 Mcu_InitClock() 之后检查 HSE_STATUS_INIT_OK 时大约需要 20 秒,但在 Mcu_Init() 之前检查时几乎立即可用? 为什么 FBL 中不需要 HSE_STATUS_INIT_OK 检查,而 APPL 启动时似乎需要? 请提供清晰的根本原因解释和推荐的初始化顺序。我们需要确保当前解决方案的稳健性,并且不会在生产环境中造成任何问题。 如有任何其他详情或时钟配置详情需要告知,请与我们联系。 此致, 舒巴姆·帕德西
查看全文
PWMキャプチャはfrdm_mcxw72ボードでは動作しません こんにちは、 frdm_mcxw72 ボードで pwm キャプチャ サンプルを試してみましたが、残念ながらシリアル ツールのプリント メッセージには「 capture cycle err -134 」としか表示されません。frdm_mcxw72ボードのPTA21ピンには、1kHz、デューティサイクル50%のPWM信号が注入されているはずです。 デモケースからプロジェクトファイル全体をインポートしましたが、オーバーレイファイルだけを追加しただけで変更はありません。以下にオーバーレイファイルの設定があります。 anliu114036_0-1783501416708.png なぜ正しい印刷情報がないのか、その理由を調べていただけますか?前もって感謝します! Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 あなたの調子が良いといいのですが。どのZephyrリポジトリを使っているのか、教えていただけますか? また、あなたは提示された例を参考にしていますか?何か変更しましたか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルドさん リポジトリのバージョンはV4.4.1.0です。以下は私の手順です 1. リポジトリからキャプチャ例のアプリケーションをインポートする anliu114036_0-1783644698775.png 2. 最初のメッセージで投稿したオーバーレイファイルの内容であるDTSオーバーレイファイルをボードフォルダに追加します。 3. 手元にある frdm_mcxw72 ボードにビルドしてフラッシュすると、プリントメッセージは次のようになります。 「キャプチャサイクルエラー」、PWM信号を注入していないのでボードの状態は問題ないように見えますが、PTA21ピンにPWM信号を注入した後もプリントメッセージは同じです。     Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 どのリポジトリを使っているのか教えていただけますか? アップストリームとダウンストリームのどちらを使用していますか? また、そのサンプルコードは、修正なしでそちら側でも正常に動作しますか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルド リポジトリのバージョンはこちらです anliu114036_0-1783902527295.png オーバーレイファイルだけを更新しますが、このファイルがなければビルドが成功しません。 よろしくお願いいたします! Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 Upstreamを使っているのか、それともDownstreamを使っているのか、教えていただけますか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルドさん すみません、ここでいう「上流」や「下流」が何なのかよく理解できませんでした。下流側であるべきだと思う。それとも別の説明を変えてもらえますか?
查看全文
IMXRT LPUART 非阻塞传输 API 使得错误处理变得困难。 您好, 我一直在研究 LPUART 的“传输”API,用于基于中断的非阻塞传输。它似乎很好地封装了所有“正常情况”下的 LPUART 中断处理等,并提供了一个良好的高级 API,用于在数据准备就绪时接收数据(即)。处理 IDLE、RX 就绪、TX 完成等状态)。然而,这使得处理 UART 错误变得非常困难。 LPUART_TransferHandleIRQ 函数内部没有错误处理,并且在 fsl_lpuart.c 中紧随其后的是一个虚假的空 LPUART_TransferHandleErrorIRQ 函数,其中包含注释“由用户实现”。这看起来完全是半成品。 处理 UART 错误的唯一方法似乎是覆盖默认的 LPUARTx_IRQHandler 函数,这样就不需要调用 LPUARTx_RX_DriverIRQHandler(或 TX),而是需要调用自己的函数来处理错误,并将“正常情况”中断传递给原始的 LPUARTx_RX/TX_DriverIRQHandler,以便它可以调用 LPUART_TransferHandleErrorIRQ。 此外,您还需要在传输 API 之外通过调用 LPUART_EnableInterrupts 来启用这些错误中断,并在错误处理中调用 LPUART_DisableInterrupts 并处理清除它们等操作。 这样处理错误似乎很麻烦。为什么这项功能没有内置到转账 API 中? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 感谢您提供的详细反馈。我理解 SDK 可能有点含糊不清,因为这些 SDK 的目的是为每个外围设备功能提供常见的用例。我们也一直在努力改进我们的 API,这也要感谢像这样的建议。感谢您的建议,我们希望 LPUART 的错误处理功能能在未来的版本中得到实现。 另一方面,请问您想处理哪些具体的错误状态,以及您使用的是哪款设备?有了这些信息,我可以向您推荐一些与这些错误状态相关的文档,这些文档可能会对您的实施有所帮助。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 所有可能的错误。这几乎适用于所有具有传输 API 但没有错误处理的外围设备(SPI、I2C 等)。IMXRT1172 上的 LPUART 存在帧错误、奇偶校验错误和噪声错误,这些错误无法得到处理。遗憾的是,目前所有这些外围设备都需要一些破解才能处理使用传输 API 时出现的错误。我必须覆盖默认的 IRQ 处理程序,以便在调用 SDK 处理程序之前检查错误。 谢谢! -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 我知道这可能需要额外的开发时间,对此我们深表歉意,我们将继续努力改进我们的SDK。作为参考,您可以查看 SDK(版本 26.6)中名为“LPUART_TransferHandleIRQ”的函数的以下结构,并根据您的应用程序需要实现类似的恢复流程。 Habib_MS_1-1784062752001.png BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 如果您还有其他问题,请告诉我。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 是的,我已经实现了类似的功能。谢谢你发来这个。
查看全文
S32DS 3.4 compilation failed when importing adc_example_s32k118. make: *** [src/main.o] Error 1 make: *** Waiting for unfinished tasks.... In file included from ../Project_Settings/Startup_Code/exceptions.c:30: /home/xysun/NXP/S32DS.3.4/S32DS/software/PlatformSDK_S32K1_2022_02/SW32K1_RTD_4_4_1_0_1_D2202/Base_TS_T40D2M10I1R0/include/Mcal.h:62:10: Fatal error: Soc_Ips.h: No such file or directory. 62 | #include "Soc_Ips.h" | ^~~~~~~~~~~ Compilation failed. Re: S32DS 3.4导入adc_example_s32k118编译失败 1.jpg periherals of ConfigTools is “SoC_Ips.h”,but RTD and generate/include source code use #include "Soc_Ips.h" then linux strictly distinguish between uppercase and lowercase letters,this is a bug of S32 IDE?should manual modification the file name of generate/include/SoC_Ips.h to generate/include/Soc_Ips.h,then compile succeed Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu For your new question:"The window installation is OK, but the Ubuntu installation fails. I can't found reason" Could you please create a new topic , because I know nothing about Ubuntu. Re: S32DS 3.4导入adc_example_s32k118编译失败 The window installation is OK, but the Ubuntu installation fails. I can't found reason Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu I can't think of other possible reasons. I can only suggest that you reinstall the IDE and RTD. Try not to use Chinese and try again. Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi senlent look,version is ok 2024-03-29 14-55-50 的屏幕截图.png     Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu please show me your S32 DS version like picture below, you can see the RTD 1.0.1 require "Update 1" and above version installed. Senlent_1-1711693579879.png Senlent_0-1711693544628.png Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi senlent, have this error 2024-03-29 11-18-54 的屏幕截图.png Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi senlent Maybe the component function does not exist. How to install this function? 2024-03-29 10-32-55 的屏幕截图.png     Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu According to the log file you provided, the Soc_Ips.h file is missing from your current project, but in fact the file will be generated in your project directory after you update the code. So my conclusion is that you probably didn't generate the configuration code correctly Senlent_0-1711674664635.png Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi Senlent Already updated, but still the same problem 2024-03-28 18-22-49 的屏幕截图.png   Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu please click "Update code" to generate config file before building it. Senlent_0-1711618540617.png
查看全文
i.MX95 - Unable to perform the SOC reset from A55 core Hello Experts, I am working on i.MX95 and would like to perform the SOC reset (including M55 and M7 cores) from the A55 core. With reference to section 18.2 in https://www.nxp.com/docs/en/user-guide/UG10163.pdf CRRM also needs a cold reboot (reboot SoC) to trigger the mode switch, for example, from recovery downloading to recovery installation. To meet it, we implement PSCI RESET2 in ATF, and use "reboot" rather than "reset" in U-Boot for this SoC reset. The kernel also adds the imx-sm-reset driver to call PSCI RESET2 to ATF. User application needs to use the following syscall to trigger the board reset. syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, "board_reset"); I have created a test application(In attachments) with this syscall included to trigger SOC reset from A55 core. However upon execution, it only resets A55 core and other M33 and M7 cores remain intact. If someone has tried this before and reset the complete SOC, kindly let me know Thanks in Advance ! BR, Arun Kumar  Re: i.MX95 - Unable to perform the SOC reset from A55 core Hello, When using the SCMI protocol to manage SoC regional resets, SM must handle the associated LP handshakes generated by the regional reset. In addition, some regional resets such as A55 have dependencies on each other. For example, issuing a A55Cx reset can only be issued in conjunction with an overall A55 regional (non-cooperative) reset. Reset from bash using reboot command has the same behavior, if a complete SoC restart is required, including all processing domains, a watchdog-triggered reset or a PMIC-driven power cycle may be required. Best regards.
查看全文
Regarding 8M Plus Real time Accuracy Hi,  We would like to lean more about 8M Plus capabilities regarding its real-time applications. Are there any test reports or related materials available concerning TSN or real-time performance, or jitter? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy Area Available material What it contains Real-time CPU/RTOS latency Harpoon User’s Guide Measured real-time latencies on i.MX 8M Plus / Zephyr , including IRQ latency and task latency in ns. Example results: no-load IRQ latency min/avg/max/stddev = 625 / 796 / 11,125 / 1,798 ns ; task latency = 2,583 / 2,671 / 13,041 / 6,045 ns . Under Linux CPU + memory load, IRQ latency = 625 / 798 / 4,250 / 4,674 ns , and task latency = 2,583 / 2,670 / 14,333 / 10,407 ns . Real-time benchmark method Harpoon User’s Guide — rt latency application Defines the benchmark as the time delta between hardware IRQ events and software actions, measured with a hardware timer and sub-microsecond precision. TSN capability i.MX 8M Plus product / reference material i.MX 8M Plus includes dual Gb Ethernet, with one Ethernet supporting TSN, and uses the integrated 800 MHz Arm Cortex-M7 for industrial real-time control. TSN hardware standards i.MX 8M Plus Reference Manual TSN support includes IEEE 802.1Qbv Time-Aware Shaper , 802.1Qav Credit-Based Shaper , IEEE 1588v2 PTP , and the Ethernet block implements 802.1Qbv-2015 , 802.3br , and 802.1Qbu frame preemption-related TSN functions. TSN test / validation environment Real-Time Edge User Guide Describes a TSN test environment for evaluating i.MX 8M Plus TSN capabilities, including traffic generation/analysis and monitoring of latency, jitter, and synchronization accuracy. TSN jitter / latency example Real-Time Edge User Guide — TSN endpoint sample app Provides TSN endpoint statistics including traffic latency min/mean/max and notes latency around 503 µs with latency jitter around 300 ns in the shown example. TSN application demo AN13588 Demonstrates a GenAVB/TSN real-time control application. It describes a 2 ms cycle , a 400 µs reserved/guaranteed control-traffic window , and a statistics thread for scheduling, processing timing, traffic correctness, and latency. TSN 802.1Qbv demo AN13995 Demonstrates TSN 802.1Qbv using i.MX 8M Plus and explains how time-aware shaping uses fixed repeating cycles to provide deterministic latency; it also includes Linux  tc  /  taprio  configuration examples.   Re: Regarding 8M Plus Real time Accuracy @yipingwang  Thank you for providing the information. Could you also please provide us with information about the iMX8M Plus EVK? Thanks. Re: Regarding 8M Plus Real time Accuracy We understand that no public "real-time performance report" has been officially released for i.MX95 EVK. However, NXP does internally perform real-time benchmarking on i.MX95 platforms. Internal benchmark documents indicate that cyclictest and EtherCAT performance evaluations have been executed on i.MX95 LPDDR5 EVKs running Real-Time Edge software with PREEMPT_RT Linux. Reported examples include a maximum cyclictest latency of approximately 38 µs during a 6-hour stress-ng test and EtherCAT filtered maximum jitter of approximately 12 µs under the documented test conditions. Because real-time performance depends strongly on BSP version, kernel configuration, CPU isolation, workload, and network traffic, these values should be considered reference measurements rather than guaranteed application-level limits.   Please refer to https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf as supported benchmarking platforms and provide detailed cyclictest, stress, and rt_latency procedures. Re: Regarding 8M Plus Real time Accuracy Our distributor informed us that there is currently no official performance report available for the NXP i.MX95 EVK regarding real-time performance or jitter. However, they also provided documentation describing the testing methodology (e.g., cyclictest) for evaluating real-time latency. This leads to some confusion on our side. Since a standardized testing methodology exists, we assume that such tests must have been performed internally—at least on the reference EVK platform. Therefore, we would like to clarify: Has NXP conducted any internal measurements of real-time performance (e.g., latency, jitter) on the i.MX95 EVK? If so, are there any reference or baseline results that could be shared? We understand that real-time performance may vary depending on system configuration and workload. However, even a baseline result under controlled conditions (e.g., default BSP, minimal load) would be very helpful for initial evaluation. Thank you for your support. hankwang_0-1784018178178.png Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (Real-Time Edge Software User Guide) (https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf) . Real-Time Edge Software (most relevant) NXP's Real-Time Edge Software officially supports the i.MX8M Plus EVK and includes: PREEMPT_RT Linux TSN stack IEEE 802.1AS (gPTP) synchronization TSN traffic shaping and scheduling EtherCAT, OPC-UA, CAN-related industrial protocols Heterogeneous real-time operation using Cortex-A53 + Cortex-M7 The internal document REALTIMEEDGEUG states that Real-Time Edge Software provides: Real-time networking (TSN) Real-time Linux (PREEMPT_RT) Pure RTOS/Bare-metal options Jailhouse partitioning Industrial protocol support Support for i.MX 8M Plus LPDDR4 EVK NXP Application Note AN13995 – TSN 802.1Qbv Demonstration using i.MX 8M Plus The Real-Time Edge Six Pack materials describing PREEMPT_RT + TSN support Re: Regarding 8M Plus Real time Accuracy @yipingwangThank you very much for the information you provided.
查看全文
adc_example_s32k118をインポートした際に、S32DS 3.4のコンパイルが失敗しました。 make: *** [src/main.o]エラー1 make: *** 未完了のタスクを待機中... ../Project_Settings/Startup_Code/exceptions.c:30 からインクルードされたファイル内: /home/xysun/NXP/S32DS.3.4/S32DS/software/PlatformSDK_S32K1_2022_02/SW32K1_RTD_4_4_1_0_1_D2202/Base_TS_T40D2M10I1R0/include/Mcal.h:62:10:致命的なエラー: Soc_Ips.h: そのようなファイルまたはディレクトリはありません。 62 | #include "Soc_Ips.h" | ^~~~~~~~~~~ コンパイルに失敗しました。 Re: S32DS 3.4导入adc_example_s32k118编译失败 1.jpg ConfigTools の周辺機器は「SoC_Ips.h」ですが、RTD およびソースコードの生成/組み込み #include "Soc_Ips.h" それからLinuxは大文字と小文字を厳密に区別します。これはS32 IDEのバグです。generate/include/SoC_Ips.hのファイル名を手動で修正してgenerate/include/Soc_Ips.hにしてからコンパイル成功すべきでしょうか? Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、@ yshenu 新しい質問に対して:「Windowsのインストールは問題ないのですが、Ubuntuのインストールは失敗します。理由が見つからない」 Ubuntuについては何も知らないので、新しいトピックを作成してもらえますか? Re: S32DS 3.4导入adc_example_s32k118编译失败 Windowsのインストールは問題なく完了するが、Ubuntuのインストールは失敗する。理由が見つからない Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、@ yshenu 他に考えられる理由が思い浮かびません。IDEとRTDを再インストールすることをおすすめします。中国語を使わずに、もう一度試してみてください。 Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、senlent 見て、バージョンは問題ない 2024-03-29 14-55-50 的屏幕截图.png     Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは@yshenu 下の写真のように、あなたのS32 DS版を見せてください。RTD 1.0.1は「Update 1」以上のバージョンをインストールする必要があります。 Senlent_1-1711693579879.png Senlent_0-1711693544628.png Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、senlentさん、 このエラーが発生しています 2024-03-29 11-18-54 的屏幕截图.png Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、senlent コンポーネント関数が存在しない可能性があります。この機能をインストールするにはどうすればよいですか? 2024-03-29 10-32-55 的屏幕截图.png     Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは@yshenu ご提供いただいたログファイルによると、Soc_Ips.h現在のプロジェクトにファイルが見つかりませんが、実際にはコードを更新するとプロジェクトディレクトリにファイルが生成されます。ですので、おそらく設定コードを正しく生成していないのだと思います Senlent_0-1711674664635.png Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、センレント 既にアップデート済みだが、依然として同じ問題が発生している。 2024-03-28 18-22-49 的屏幕截图.png   Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは@yshenu ビルド前に「コードの更新」をクリックして設定ファイルを生成してください。 Senlent_0-1711618540617.png
查看全文
i.MX95 - A55コアからSOCリセットを実行できません こんにちは、専門家の皆様。 私はi.MX95を扱っており、A55コアからSOCリセット(M55およびM7コアを含む)を実行したいと考えています。 https://www.nxp.com/docs/en/user-guide/UG10163.pdfのセクション 18.2 を参照してください。 CRRM also needs a cold reboot (reboot SoC) to trigger the mode switch, for example, from recovery downloading to recovery installation. To meet it, we implement PSCI RESET2 in ATF, and use "reboot" rather than "reset" in U-Boot for this SoC reset. The kernel also adds the imx-sm-reset driver to call PSCI RESET2 to ATF. User application needs to use the following syscall to trigger the board reset. syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, "board_reset"); このシステムコールを含めたテストアプリケーション(添付ファイル内)を作成し、A55コアからのSOCリセットをトリガーしています。しかし、実行時にはA55コアのみがリセットされ、他のM33およびM7コアはそのまま残ります。 以前にこれを試してSOC全体をリセットした方がいらっしゃいましたら、ぜひ教えてください。 よろしくお願いいたします! BR、 アルン・クマール Re: i.MX95 - Unable to perform the SOC reset from A55 core こんにちは、 SCMIプロトコルを使用してSoCのリージョンリセットを管理する場合、SMはリージョンリセットによって生成される関連するLPハンドシェイクを処理する必要があります。さらに、A55などの一部の地域リセットは、互いに依存関係を持っています。例えば、A55Cxリセットの発行は、全体のA55地域(非協力)リセットと同時に発行される場合のみ可能です。 再起動コマンドによるbashからのリセットも同様の動作をしますが、SoCの完全な再起動(すべてのプロセッシングドメインを含む)が必要な場合は、ウォッチドッグトリガーリセットやPMIC駆動の電源サイクルが必要になることがあります。 よろしくお願いいたします。
查看全文