KW47（オートモーティブ）またはMCX W72（IoT/インダストリアル）を使用してPCBを初めて正しく構築するための最適な方法 /*** 2025年4月の最新免責事項： - KW47、MCX W72は、KW45とMCX W71からの直接的なデリバティブです。今後の更新に備えて、このページをブックマークしてください。 - この記事は、KW45、K32W148、MCX W71に基づく早期イネーブルメントを目的としていますが、2025年にKW47とMCX W72の範囲を広げた新しいリリースが予定されているため、更新は保留になっています。 --データシート、リファレンスマニュアル、ハードウェア製造ファイルを含め、ほとんどの設計ドキュメントはリクエストに応じて共有--***/ KW47またはMCX W72を使用してPCBを構築するための重要なリンクと、無線性能、低消費電力、無線認証（CE/FCC/IC）に関することすべてについて、把握しておいてください。 KW47製品のNXPウェブページ：https://www.nxp.com/products/KW47 MCXW72製品のNXPウェブページ：https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/mcx-arm-cortex-m/mcx-w-series-microcontrollers/mcx-w72x-secure-and-ultra-low-power-mcus-for-matter-thread-zigbee-and-bluetooth-le:MCX-W72X KW-MCXW-EVKスタートガイドのNXPウェブページKW47/MCXW72のリリースは保留中 KW47-LOCスタートガイドのNXPウェブページKW47/MCXW72のリリースは保留中 MCXW72-LOCスタートガイドのNXPウェブページKW47/MCXW72のリリースは保留中 ハードウェア KW47 MCX W72 EVKボード：暫定版を添付 KW47 LOCチャネルサウンディングボード - 図：暫定版を添付 KW47-MCXW72-EVKハードウェアガイドライン：リクエストに応じて提供 HVQFN48パッケージ仕様：SOT619-17(D) SOT619-17(DD)のリリースは保留中   KW47-MCXW72-EVKユーザーマニュアルKW47/MCXW72のリリースは保留中 最小BoM（添付ファイル） > > KW45 - MCX W71 - KW47 - MCX W72 Minimum BoM Presentation Customers July25.pdf DCDC管理ガイド（AN13831）：KW45/K32W148 - パワーマネジメントハードウェア（nxp.com）KW45はKW47に適用可能KW47/MCXW72はリリース待ち デザインインチェックリスト：本記事末尾の添付ファイルを参照 RFマッチング：Sパラメータ（添付ファイル）KW47/MCXW72のリリースは保留中 PCBでのコインセルアプリケーションの処理方法:  AN14664_Coincell_Hardware_recommendation_Rev1.0.pdf  情報: 「RFの動作はPCBレイアウトおよび製造に依存するため、最終製品化されたプラットフォームのRFで期待どおりの認定を確保するには、PCBプロトタイプ（NXPの推奨事項に基づく）を微調整する必要があります。」 EVKで、RF試験のM10モジュールを接続するには、µFLからSMAへのケーブルが推奨されます。 CSH-SGFB-200-UFFR TE Connectivity / Linx Technologies | Mouser France KW47-LOCまたはMCXW72-LOCにSMAを接続するには、専用コネクタTE Connectivity Ltd CONSMA021.062-Gを取り付けるする必要があります。 KW47ハードウェア移植によるKW45： KW47はKW45とのピン間互換性があります。ただし、ハードウェアの観点からは、一部のコンポーネントの値（RFマッチングコンポーネントの値など）を調整する必要があります。 KW4x周辺の他のコンポーネントについては、現在のシリコン検証に基づいた変更は想定されていません。 また、KW47のピンが新機能に対応するよう、新しい多重化が導入されていることにもご注意ください。たとえば、KW47では2番目のFlex CANが対応します。添付ファイルを参照してください 無線 RFレポート： Bluetooth LEアプリケーションK32W148 foとr 802.15.4アプリケーションのKW45/K32W148 RFシステム評価レポート...KW47/MCXW72のリリースは保留中 - オンデマンドで提供     無線共存： Kinetisワイヤレスファミリ製品Bluetooth Low EnergyとWi-Fiアプリケーション（nxp.com）の共存 KW47/MCXW72のリリースは保留中  距離性能：添付ファイルを参照KW47/MCXW72のリリースは保留中 アンテナ： NXP EVKボード内2.4GHz通信デザイン/アプリケーション用小型平面アンテナ チャンネルサウンディングアプリケーション用アンテナ BLEコネクティビティテスト用バイナリファイル：オンデマンドでSDKにて提供 リターンロス（S11）測定： RFマッチング（S11）のリターンロスを測定する方法RFレポート（AN13728）の一部 ロードプル：KW47/MCXW72のリリースは保留中 RF試験用ソフトウェアツール： IoTツールボックス（モバイルアプリケーション） コネクティビティ製品のコネクティビティテストツール (IoT ツールボックスの一部) DTM： HCI_bbをKinetisファミリ製品で使用する方法 - NXPコミュニティ https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/BLE-HCI-Application-to-set-transmitter-... クリスタル 記事 : KW45/K32W1 32MHz & 32kHz Oscilllation margins - NXP CommunityKW47/MCXW72のリリースは保留中 推奨クリスタル付属 低消費電力 Bluetooth LE電力プロファイル推定ツール KW45_WK47_BLE_power_profile_calculator_v1.32.xlsm 低消費電力              AN14554 Kinetis KW47 & MCX W72 Bluetooth LE Power profile analysis release.pdf 802.15.4 Matter & Zigbee 電力プロファイル推定ツール               MCX W7x 802.15.4 Matter ICD SIT LIT & ZED Power profile v0.2.xlsx                 AN MCX W72 802.15.4 Matter and Zigbee Power profile analysis - proposal.pdf CCC チャネルサウンディング BLE パワープロファイル推定ツール               KW47 Digital Key CCC CS Power Estimator tool v0.8.xlsx               AN14628_AN14628_KW47_CCC_CS_Power_Profile_estimator tool_release.pdf Bluetooth ® チャネルサウンディング技術概要 認証 RF事前認証完了 - 完全認証についてははKW47/MCXW72のリリースは保留中  KW47とMCXW72はBluetooth 6.0チャネルサウンディング認定です。

linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx linux6.12+imx8mp内核启动时报告： [ 0.057737] /soc@0: Fixed dependency cycle(s) with /soc@0/bus@30000000/efuse@30350000/unique-id@8 [ 0.058809] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.058972] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 [ 0.059239] /soc@0/interrupt-controller@38800000: Fixed dependency cycle(s) with /soc@0/interrupt-controller@38800000 [ 0.061960] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /soc@0/bus@30000000/pinctrl@30330000/miscgrp [ 0.061986] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /soc@0/bus@30000000/pinctrl@30330000/hoggrp [ 0.062566] imx8mp-pinctrl 30330000.pinctrl: initialized IMX pinctrl driver [ 0.063301] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000 [ 0.064431] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000 [ 0.065497] /soc@0/bus@30000000/clock-controller@30380000: Fixed dependency cycle(s) with /soc@0/interrupt-controller@38800000 [ 0.074336] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.074446] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 [ 0.076363] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.076855] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.076990] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 原因是什么？需要处理吗 Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx Hi @machangbao This is normal, no need to deal with it. Best Regards, Zhiming Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx Hi @machangbao This is the patch that was introduced upstream of the kernel, the commit message is: driver core: fw_devlink: Stop trying to optimize cycle detection logic commit bac3b10b78e54b7da3cede397258f75a2180609b upstream. In attempting to optimize fw_devlink runtime, I introduced numerous cycle detection bugs by foregoing cycle detection logic under specific conditions. Each fix has further narrowed the conditions for optimization. It's time to give up on these optimization attempts and just run the cycle detection logic every time fw_devlink tries to create a device link. The specific bug report that triggered this fix involved a supplier fwnode that never gets a device created for it. Instead, the supplier fwnode is represented by the device that corresponds to an ancestor fwnode. In this case, fw_devlink didn't do any cycle detection because the cycle detection logic is only run when a device link is created between the devices that correspond to the actual consumer and supplier fwnodes. With this change, fw_devlink will run cycle detection logic even when creating SYNC_STATE_ONLY proxy device links from a device that is an ancestor of a consumer fwnode. The fw_devlink framework on top of 6.12 is more robust than before, and Fixed dependency cycle(s) with indicates that fw_devlink detected the ring and solved the problem by adjusting the linking policy (e.g., downgrading certain link types or not creating certain links). This is not an error, but an informational note that the system handles potential deadlock risks at boot time. driver core: fw_devlink: Make cycle detection more robust fw_devlink could only detect a single and simple cycle because it relied mainly on device link cycle detection code that only checked for cycles between devices. The expectation was that the firmware wouldn't have complicated cycles and multiple cycles between devices. That expectation has been proven to be wrong. For example, fw_devlink could handle: +-+ +-+ |A+------> |B+ +-+ +++ ^ | | | +----------+ But it couldn't handle even something as "simple" as: +---------------------+ | | v | +-+ +-+ +++ |A+------> |B+------> |C| +-+ +++ +-+ ^ | | | +----------+ But firmware has even more complicated cycles like: +---------------------+ | | v | +-+ +---+ +++ +--+A+------>| B +-----> |C|<--+ | +-+ ++--+ +++ | | ^ | ^ | | | | | | | | | +---------+ +---------+ | | | +------------------------------+ And this is without including parent child dependencies or nodes in the cycle that are just firmware nodes that'll never have a struct device created for them. The proper way to treat these devices it to not force any probe ordering between them, while still enforce dependencies between node in the cycles (A, B and C) and their consumers. So this patch goes all out and just deals with all types of cycles. It does this by: 1. Following dependencies across device links, parent-child and fwnode links. 2. When it find cycles, it mark the device links and fwnode links as such instead of just deleting them or making the indistinguishable from proxy SYNC_STATE_ONLY device links. This way, when new nodes get added, we can immediately find and mark any new cycles whether the new node is a device or firmware node. Best Regards, Zhiming

S32K3XXドライバ構成 S32K3XXシリーズチップの新規構築プロジェクトについてお伺いします。ドライバを使用する際に、各ドライバ（各ドライバタイプはポジション1に対応）の設定インターフェースにある各設定項目（ポジション3に表示）について解説したドキュメントやチュートリアルはありますか？実際のエンジニアリングアプリケーションでは、どのような情報を参考に設定すればよいでしょうか？設定するたびに設定項目名を見て機能を推測し、設定内容を決めています。公式の根拠が不足しているように感じ、それぞれの設定が非常に不確実で根拠がないと感じています。 Re: S32K3XX的drivers配置 こんにちは@Aaron_LL AN13435 の次のセクションでは、さまざまなコンポーネントについて説明します。 さらに、公式 Web サイトには周辺機器の設定トレーニング チュートリアルが多数用意されており、そこから見つけることができます。 https://www.nxp.com/products/S32K3

i.MX93: J-Link と SYSRESETREQ を使用した Cortex-M33 リセットが機能しない こんにちは、 Segger J-Link と gdb を使用して、i.MX93 上の Cortex-M33 のファームウェアをデバッグしようとしています。NXP の J-Link ソフトウェアのパッチを使用して SWD 接続を確立し、プロセッサを停止したり、レジスタやメモリを読み取ったりできるようになりました。 問題は、プロセッサをリセットしても機能しないことです。レジスタの内容は変更されないので、リセットは無視されるものと想定します。 (gdb) レジスタを監視する R0 = 40D000C0、R1 = 2001EFE3、R2 = 40D000C0、R3 = 00000000 R4 = 00000000、R5 = 00000000、R6 = FFFFFFFF、R7 = 2001EEE8 R8 = FFFFFFFF、R9 = FFFFFFFF、R10 = 2000F000、R11 = 00000000 R12= FFFFFFFF、R13= 2001EEE8、MSP= 2001EEE8、PSP= 00000000 R14(LR) = 0FFE219D、R15(PC) = 0FFE2248 XPSR 49000003、APSR 48000000、EPSR 01000000、IPSR 00000003 CFBP 00000000、コントロール 00、フォールトマスク 00、ベースプライ 00、プライマスク 00 セキュリティ拡張規則: MSP_S = 2001EEE8、MSPLIM_S = 00000000 PSP_S = 00000000、PSPLIM_S = 00000000 MSP_NS = 00000000、MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC、PSPLIM_NS = 00000000 CONTROL_S 00、FAULTMASK_S 00、BASEPRI_S 00、PRIMASK_S 00 CONTROL_NS 00、FAULTMASK_NS 00、BASEPRI_NS 00、PRIMASK_NS 00 (gdb) モニターのリセット ターゲットをリセットする (gdb) レジスタを監視する R0 = 40D000C0、R1 = 2001EFE3、R2 = 40D000C0、R3 = 00000000 R4 = 00000000、R5 = 00000000、R6 = FFFFFFFF、R7 = 2001EEE8 R8 = FFFFFFFF、R9 = FFFFFFFF、R10 = 2000F000、R11 = 00000000 R12= FFFFFFFF、R13= 2001EEE8、MSP= 2001EEE8、PSP= 00000000 R14(LR) = 0FFE219D、R15(PC) = 0FFE2248 XPSR 49000003、APSR 48000000、EPSR 01000000、IPSR 00000003 CFBP 00000000、コントロール 00、フォールトマスク 00、ベースプライ 00、プライマスク 00 セキュリティ拡張規則: MSP_S = 2001EEE8、MSPLIM_S = 00000000 PSP_S = 00000000、PSPLIM_S = 00000000 MSP_NS = 00000000、MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC、PSPLIM_NS = 00000000 CONTROL_S 00、FAULTMASK_S 00、BASEPRI_S 00、PRIMASK_S 00 CONTROL_NS 00、FAULTMASK_NS 00、BASEPRI_NS 00、PRIMASK_NS 00 J-Link からのリセット戦略では、Cortex-M33 コアのみがリセットされることになっているため、リセット信号ではなく SYSRESETREQ を使用します。デバッグ コントローラに SYSRESETREQ ビットを書き込むために必要なセキュリティ権限がない可能性はありますか? J-Link を使用して Cortex-M33 のリセットを実行する正しい方法は何ですか? よろしくお願いいたします。 マルテ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、 vlpasha84@gmail.com でも詳細を共有していただけますか? このトピックからすでに 1 年以上経過していますが、まだ同じ問題が残っています。 ありがとう。 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working プロセッサが再び失われることはなかったという意味ではうまくいきましたが、実行時間には大きな影響がありました。その理由はわかりません。 それぞれの操作には10倍の時間がかかりました。 コールド リセットを実行しますが、デフォルトで ROM にいくつかのコード (NXP が SD カードがないことを示唆していることとは反対) を残し、実行中のものにデバッガーを接続して RAM を上書きすることは意味がありますか? Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、 この JLink スクリプトを使用することは可能ですか? https://kb.segger.com/images/8/86/Example_Reset_CortexM_Normal.JLinkScript これはCortexMの標準的な戦略です。 敬具 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、 解決策を共有していただけますか?私も現在同じ状況に直面しています。 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、クリストフさん。 上で述べたように、私は J-Link を使用して i.MX93 の Cortex-M33 をリセットする方法を見つけました。もしそれがあなたが探しているものであれば、喜んで詳細をお伝えします。電子メールアドレスまたは直接連絡できる他の方法を教えてください。 よろしくお願いいたします。 マルテ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは。このトピックを見つけたばかりですが、M33 を A55 から分離して操作するための信頼できる解決策を誰かがようやく見つけることができたかどうか知りたいと思いました。最近、今後のプロジェクトのために開発環境の作成を開始しましたが、すぐにソフトウェア リセットのトリガーに関する同じ問題に遭遇しました。Threadが開かれてからしばらく経ちましたが、SEGGERは現在 (v8.10) IMXターゲットを組み込んだソフトウェアを提供していますが、まだシングルコアリセットを実行できないようです。SCB (SYSRESETREQ) と SCR レジスターでいくつか実験してみましたが、安定した結果は得られませんでした。また、VSCode 用の MCUXpresso プラグインも簡単にテストしましたが、カスタムの動作するリセット戦略の実装は見つかりませんでした。 よろしくお願いいたします。 クリストフ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、マルカイさん。私もまったく同じ問題を抱えているので、解決策にとても興味があります。解決策やアドバイスを送っていただくことは可能でしょうか?どうもありがとう。j.zhang3@krohne.com よろしくお願いいたします。 順州 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、マルテ 大変助かります。私のメールアドレスはnim@develcoproducts.comです。 よろしくお願いいたします。 ニールス Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、ニールス。 あまり役に立たない NXP サポートのおかげで、私はこの問題の解決策を見つけました。 メールアドレスまたは直接連絡できる他の方法を教えていただければ、喜んでお手伝いさせていただきます。 敬具、 マルテ・カイザー Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@Sanket_Parekh 私も原作者と全く同じ状況です。NXP が提供する JLink スクリプトは、実際には M33 コアをリセットするのではなく、停止するだけのようです。これにより、レジスタとプロセッサの状態は変更されず、障害が発生した場合、最初に Linux 経由でコアをリセットしないとデバッグを適切に続行できなくなります。 JLink デバッガーを使用して、M33 コアのこのようなリセットをトリガーする方法はありますか? よろしくお願いいたします。 ニールス Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、 Sanket_Parekhさん (1) i.MX93 Cortex-M33用のNXP J-Linkスクリプトパッチはどこで入手できますか？ （2）Segger氏によると、J-Linkでi.MX93をサポートするためのロードマップはまだ存在しない。しかし、それはQ1またはQ2に発生する可能性があります。Cortex-M33 をデバッグする他の方法はありますか? BR Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@malkai 、 お元気でお過ごしでしょうか。 「NXP が i.MX93 の Cortex-M33 コアをリセットするために意図した手順は何ですか?」 -> システム リセット コントローラ (SRC) は、すべてのシステム リセット信号の生成とブート引数のラッチを担当します。 ->主な機能は次のとおりです。 • 他のモジュールからのすべてのグローバル システム リセット ソースを処理し、グローバル システム リセットを生成します。 • MIX (スライス) の電力ゲーティングとメモリの低電力制御を担当します。 ->SRCはPADとヒューズビットからPOR_Bを取得してブートシーケンスを完了し、GPCの低電力要求を 電源のダウン/アップシーケンスを完了します。 第33章「システム リセット コントローラ (SRC)」を参照してください。 https://www.nxp.com/webapp/Download?colCode=IMX93RM ありがとう、よろしく。 サンケト・パレック Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@Sanket_Parekh m、 お返事ありがとうございます。しかし、その情報は問題の解決には役立ちません。ご存知のとおり、i.MX93 の Cortex-M33 コアには Armv8-M アーキテクチャがあり、AIRCR レジスタに VECTRESET ビットがありません ( https://developer.arm.com/documentation/ddi0553/latest/の D1.2.3 を参照)。SO、唯一利用可能なリセット要求は SYSRESETREQ であり、これには Cortex-M33 コアもシステム全体も反応しません。何故ですか？ 私はすでに J-Link で使用されるリセット戦略を調べました。問題は、私が言ったように、NXP からのパッチは、CPU を停止するだけでこれらを置き換えるということです。また、リセット ラインは SoC 全体をリセットするため、ここでは使用できません。 SO、問題はまだ残っています。NXP が i.MX93 の Cortex-M33 コアをリセットするために意図した手順は何でしょうか? ありがとうございます。 マルテ・カイザー Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@malkai 、 お元気でお過ごしでしょうか。 ->リセット選択は、ターゲット デバイスのリセット操作を制御します。すべてのリセット オプションは Cortex-M プロセッサ ベースのデバイスに適用され、JTAG および SWD モードで使用でき、リセット後に CPU を停止します。 ->Core - VECTRESET ビットを設定することによってのみ Cortex-M コアのリセットを実行します。オンチップペリフェラルはリセットされません。一部の Cortex-M デバイスでは、このリセット方法がリセットできる唯一の方法です。ただし、ほとんどの場合、この方法は推奨されません。これは、ほとんどのアプリケーションが一部のペリフェラル（PLL、外部メモリ インターフェイスなど）のリセット状態に依存しており、起動時にペリフェラルがすでに構成されていると混乱が生じる可能性があるためです。 ->ResetPin - J-Link は RESET ピンを低くして、コアとペリフェラルをリセットします。通常、これによりデバイスの CPU RESET ピンも低くなり、CPU とペリフェラルがリセットされます。ターゲット デバイスの RESET ピンがローにプルされていない場合、このリセット方法は失敗します。 以下のリンクのセクションのリセット戦略を参照してください。 https://community.nxp.com/ pwmxy87654/attachments/ pwmxy87654/kinetis/28743/1/ UM08001_JLink.pdf ありがとう、よろしく。 サンケト・パレック Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@Sanket_Parekhさん、 お返事ありがとうございます。残念ながら、その情報は私の問題の解決に役立ちません。その間に、私はいくつかのことを知りました: 1.i.MX93 のパッチで NXP が提供する J-Link スクリプトではリセットが実装されません。CPU をリセットするのではなく、単に停止するだけです。 2. デバッガを介して AICR.SYSRESETREQ に手動で 1 を書き込んでリセットを要求しても、Cortex-M33 コアはリセットされません。 SO、私の最初の質問は残っています: デバッガーを介して Cortex-M33 をリセットする可能性はありますか? 感謝と敬意を込めて、 マルテ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@malkai 、 お元気でお過ごしでしょうか。 こちらのリンクを参考にしてください。役に立つと思います。 https://community.nxp.com/t5/i-MX-プロセッサ-Knowledge-Base/すべてのボード-JTAG/ta-p/1106822 ------------------------------ ------------------------------ ------------------------------ ----------------------------- 注: この投稿で質問が解決した場合は、「正解」ボタンをクリックしてください。 ------------------------------ -------------------------------- -------------------------------- ----------------------------- ありがとう、よろしく。 サンケト・パレック

报告 K5 RTD 引脚配置 嗨，团队 我有一份报告与 K5 引脚配置有关。(0.8.0 CD3) GPIO 258 需要一些限制。 所以我用了下面的方法。 我认为这与下文有关。 顺便说一下，如果我使用 MCAL，它看起来会正常工作... 谢谢。 RTD 来源：恩智浦内部来源：恩智浦内部 Re: Report K5 RTD pin configuration 嗨，@Luke_Chun、 如果使用 Dio_WriteChannel 向 GPIO258 写入数据，则该函数将通过 GPDO 寄存器向 GPIO258 写入数据。 但 Siul2_Dio_Ip_WritePins() 函数将写入 PGPDO 寄存器。GPIO258 相当于 PGPDO16 寄存器，但硬件不包含该寄存器。因此，这可能是硬件问题，用户不能使用 Siul2_Dio_Ip_WritePins() 函数向 GPIO258 写入数据。在 Siul2_Ip 层中，我建议你可以使用 siul2_dio_IP_setGPDO 或 siul2_dio_IP_ClearGPDO 函数在 u8siul2Instance = 3 和 gpdoNum = 258 的情况下设置/清除 GPIO258（取自 RTD_DIO_UM.pdf 文件中的图 3.1 GPIO 分配）。 目前，RTD 驱动程序尚未通过有关此解决方法的验证，但我认为你可以尝试这样做 。 顺祝商祺！ 丹

[乱用] 投稿者: @JohnKlug / ボード: imx-processors / 報告者: thzuyfoc thzuyfoc は、 @JohnKlug が投稿した 「Could not invoke dnf for external kernel module in Yocto kirkstone」という 投稿について、以下の理由で報告しました: 理由:誤解を招く、または虚偽の情報 詳細： 投稿リンク: https://community.nxp.com/t5/i-MX-Processors/Could-not-invoke-dnf-for-external-kernel-module-in-Yocto/mp/1627964#M203740 投稿者: @JohnKlug |メール著者 報告者: thzuyfoc |メールレポーター 報告された投稿には 2 件の返信があります。

EB 客户许可证管理员 我使用的是 Tresos Studio 29.2。此前，在使用 MPC574xB 时，注册是成功的，一切运行正常。但是，既然我们已经切换到 S32K314 平台并尝试使用相应的激活码将其激活，则出现了以下错误： 错误：flxactappActivationSend (50040,41147,10248) 该激活请求不产量获得许可证的权利。 与 FlexNet Operations Server 的连接失败。 请问问题出在哪里，EB 真的只支持一个平台吗？ 电源 Re: EB ClientLicenseAdministrator 你好、 请检查您的账户，获取新的激活代码。此外，还存在可用许可证数量的问题。我已经联系了许可证管理部门来解决这个问题。 Re: EB ClientLicenseAdministrator 我通过下面的网站重新获取了最新的激活代码，但发现还是以前的激活代码，无法成功激活。接下来我该怎么办？ 设计 ：产品下载 ：文件

k344中心对齐pwm中心点触发adc bctu采样 基于https://community.nxp.com/t5/S32K-Knowledge-Base/RTD400-K344-Center-Aligned-PWM-Trigger-ADC-BCTU/ta-p/2034211、我想知道为什么需要三次 BCTU 触发信号中断才能触发 BCTU 水印。我想实现只触发信号一次中断，然后在中断中修改PWM周期，读取ADC值等。在 EB MCAL 开发的基础上，有哪些好的解决方案或示例例程可以实现相同的功能？ Re: K344中心对齐PWM中心点触发ADC BCTU采样 感谢您关注我们的产品并为我们的社区做出贡献。 您可以直接回复帖子，以获得帖子主人的反馈。 另一方面，你可以参考另一种方法，使用单个 BCTU 触发信号： S32M27x/S32K3 - eMIOS/BTCU/ADC/DMA - [RTD600] -> https://community.nxp.com/t5/S32M-Knowledge-Base/S32M27x-S32K3-eMIOS-BTCU-ADC-DMA-RTD600/ta-p/2155542 有关 MCAL 的实现，请参阅 ADC 到 PWM 的硬件抽象层示例： 前往 S32K3 页面 -> 设计资源-> 软件-> S32K3 参考软件-> 汽车软件-S32K3-硬件抽象层-> SW32K3 HAL 集成示例 2025.07 它执行以下 ADC 触发信号： 同时，它根据捕获的 ADC 值更新占空比。 希望这些信息对您有所帮助。 Re: K344中心对齐PWM中心点触发ADC BCTU采样 感谢您的解决方案。我想知道多次触发信号中断的原因以及避免此类中断的方法。或者，我是否有可能通过配置禁用该中断源？ Re: K344中心对齐PWM中心点触发ADC BCTU采样 您好， 如果启用 BCTU 触发信号通知，则在 BCTU 触发信号 ADC 时调用。如示例中的 BCTU CL 包含 3 个项目，每个输入 (EMIO) 触发信号将触发三次 ADC。 只需在“触发信号”选项中输入 NULL 即可禁用此通知。 BR, Petr

TPMS 位定时 大家好， 我正在尝试使用 FXTH87E 传感器匹配 OEM TPMS 传感器的位定时。 我修改了入门项目 FXTH87_E_FW_Periodic_RF_Tx。 我所遇到的问题是，我正试图使发送的数据达到 ~25us 位定时，但有些位是 ~50us 位，有些位是 ~25us 位。 我曾尝试通过 RFCR0 将数据传输速率提高一倍，达到 ~40 kbits，这样就解决了前导码问题，但最终得到的比特数却只有 ~13us。 我使用的也是曼彻斯特编码。 我似乎无法找到正确的设置，让所有比特都以相同的数据速率传输。 我附上了我的 main.c 和两个逻辑分析仪捕获，一个是 OEM TPMS 传感器，另一个是我的。我正在尝试复制 ~5ms 的数据包长度和 ~25us 的位定时。 目前，我得到的数据包长度约为 7ms，可变位定时约为 50us 和 25us。 如有任何建议，我们将不胜感激。 致以最诚挚的问候 Re: TPMS bit timing 你好，克雷格、 从主设备中的代码来看，以 19200 bps 的数据传输速率（RFCR0 配置）传输 136 比特。因此传输时间为 136/19200 = 7 毫秒。因此，从代码来看，完全可以预期帧的持续时间是 7 毫秒，而不是 5 毫秒。 数据传输速率为 19200 bps，一个比特持续约 50 秒。在射频配置中，曼彻斯特编码被选择为 434 MHz。而在曼彻斯特，在位的中间（约 25 秒后）有一个高到低或低到高的转换。这意味着低电平或高电平状态可以持续 25 us 或 50 us。 我将手册（UM11227）中显示曼彻斯特编码的摘录复制如下。 因此，捕获的波形与 main.c 中的配置相匹配，没有什么不正常的。 BRs, Tomas Re: TPMS bit timing 你好，托马斯、 感谢您的详细答复。 同样使用 FXTH87E 的 OEM 传感器一定没有使用标准的数据发送方式？ 下面的逻辑分析器捕获没有像 UM11227 中显示的那样有过渡效果。据我所知，连续的 0 和 1 并没有产生转换，它只是在两个周期内保持相同的值，即 ~50us。 解码后的捕获为： 010101010101010101010010110010101010101 他们是否可能以某种方式修改了发送的数据，以创建上述数据，使连续比特的比特时序加倍，而不发生转换？ 我尝试过使用不同的 CODE[1:0] 设置，还将位定时提高到 40 kbit 以获得 ~25us 位定时，但并没有消除过渡。 对不起，我的问题很简单，这是我第一次尝试复制数据包。 如能提供进一步指导，将不胜感激。 致以最诚挚的问候 克雷格 Re: TPMS bit timing 经过几个小时的实验，我相信我已经取得了进展。 我知道数据是曼彻斯特编码的。 了解到这一点后，我使用了 NRZ，这样就能实现单个比特 25us 和两个连续比特 50us 的一致比特定时。 然后我继续使用曼彻斯特编码对数据字节进行编码。经过反复试验，我终于能够复制 OEM 数据包，并通过接收器成功解码。 在我努力工作的过程中，感谢您的指导。 请将此问题视为已解决。 致以最诚挚的问候 克雷格

CODEWarrior USB TAP 驱动程序问题 你好，我们使用的是 DSP56F803 芯片，我需要用 S-Record 文件闪存它。 我们有：安装了适用于 56800E 数字信号控制器 V8.3 的 CodeWarrior 的 Windows XP，安装了 56800E 闪存编程器，还有 USB TAP 调试器。 我检查了驱动程序是否已正确安装（CCS-> 驱动程序-> USB）。设备管理器显示该设备已正确安装（libusb-Win32 设备-> CodeWarrior USB TAP）。 但是，USB TAP TX/RX 呈红色闪烁，每次我想刷新 S-Record 文件时它都会提示 " CCSProtocolPlugin: CCS: USB 打开失败 "。 我不知道为什么，一切似乎都很正常，驱动程序也显示正常。 Re: CodeWarrior USB TAP driver issue 你好@Chenxuan、 感谢您的来信。我注意到你还有一个一模一样的私人箱子。我将专注于在该案件中解决您的问题。如需任何最新信息，请随时在该私人邮箱中回复我。 感谢您的理解。 BR 西莱斯特

将 SBC FS26 R21-11 5.0.0 整合到 MBDT 上 您好， 我在恩智浦的网站（MBDT上的SBC FS26 R21-11 5.0.0）上找到了这些驱动程序，我想知道是否有可能将它们内置到MBDT中，如果是的话，该怎么做。 我试着将包含这些驱动程序的文件夹复制并粘贴到 RTD 路径中，但当我打开 S32CT 时，它不允许我添加驱动程序，所以我认为方法不对....。 谢谢！ 西蒙 Re: Integration of SBC FS26 R21-11 5.0.0 on MBDT 你找到将 SBC_FS26 与 MBDT 集成的解决方案了吗？我目前正在研究这个问题，如果您能提供任何指导或见解，我将不胜感激。 Re: Integration of SBC FS26 R21-11 5.0.0 on MBDT 嗨，很遗憾完全没有 Re: Integration of SBC FS26 R21-11 5.0.0 on MBDT 请参阅 privete 信息 Re: Integration of SBC FS26 R21-11 5.0.0 on MBDT 您找到解决这个问题的办法了吗？ 是否有办法解决这个问题，或者您有什么办法可以让我试试？ MBDT FS26

咨询S32E板子使用方法 你好， 我有2块板子，型号分别是2023 NXP B.V.S32SE28X-DC和2022 NXP B.V.X-S32X-MB。请问下这2块板子的软硬件使用方法，能否提供相应的一些资料。 谢谢

Wifi SDK を介して Raw パケットを送受信する 読者の皆様   私は NXP RW612 SoC に取り組んでおり、ハンドシェイクなしで 2 つのデバイス間でNXP Wifiドライバを使用して生のWi-Fiパケットを送受信しようとしています。 それをどうやって実装できるか、何かアイデアはありますか? 以下の関数はまだ実装されておらず、 Wifi . h ファイルではそのシグネチャのみが使用可能です。 int wifi_raw_packet_send ( const t_u8 *パケット、 t_u32 長さ); int wifi_raw_packet_recv (t_u8 **データ、t_u32 *pkt_type); レシーバをモニタリングモードに設定し、トランスミッタで次の機能を使用する必要がありますか? int wifi_inject_frame( const enum wlan_bss_type bss_type, const uint8_t *buff, const size_t len) Re: Transmit and receive Raw packet through Wifi SDK wifi_test_mode の例をテストしたところ、固定ペイロード パターンを持つ 802.11 フレームのみが送信されることに気付きました。 私のCASE、カスタム ペイロードを使用して生の 802.11 フレームを送受信する必要があります。 この目的のために次の機能を使用できますか? int wifi_inject_frame(const enum wlan_bss_type bss_type、const uint8_t *buff、const size_t len); もしSOなら、レシーバ側でパケットを受信するにはどうすればよいですか? どうぞよろしくお願いいたします。 よろしくお願いいたします。 Re: Transmit and receive Raw packet through Wifi SDK こんにちは、 wifi_test_mode アプリケーションは、さまざまな RF および規制コンプライアンス テストに対する CLI サポートを示します。 詳細については、セクション4.9.1.7「標準 802.11 パケットの送信( UM11799 )」を参照してください。 よろしくお願いいたします。 ダニエル。 Re: Transmit and receive Raw packet through Wifi SDK 詳細については、こちらをご覧ください。実際には、80.11 MAC 層を介してデータを送受信する必要があります。 Re: Transmit and receive Raw packet through Wifi SDK ダニエル様 ご返信よろしくお願いします。 wifi_test_mode SDK の例を確認しました。ただし、この例では、STA と uAP が作成されます。実際に必要なのは、ハンドシェイクなしでデータを送受信することです。それをどのように実装CANかご存知ですか? また、モニターモードを使用するためにかなりの努力をしましたが、正常に起動できませんでした。モニターモードのサンプルコードを提供してもらえますか? どうぞよろしくお願いいたします。 よろしくお願いします、 モフセン Re: Transmit and receive Raw packet through Wifi SDK こんにちは、 生の Wi-Fi パケットを送信するには、wifi_test_mode SDK の例を試すことができます。 よろしくお願いいたします。 ダニエル。

S32G3：热关机 嗨，团队 硬件：基于 S32G3。 读取 1 区温度（A-core）时。当温度达到 "64 摄氏度 "时，硬件将重新启动。 下面是 Linux 系统的信息。连续读取三个区域的温度值，问题发生时的值如下。 64350（0 区） 64350（1 区） 62850（2 区） kernel[435]：[ 7919.187233] thermalthermal_zone1: a53_cores：达到临界温度，正在关闭 内核[435]：[ 7919.187252] 重新启动：硬件保护关闭（温度过高） 在 Linux DTS 中配置的警戒温度为 80 度，临界温度为 100 度，尽管我们配置了 100 度，但在 64 度时仍可观察到重启。 Re: S32G3: Thermal Shutdown 你好，@yellapu_anishkh 感谢您的回复。 自 BSP39 以来，有几个与 TMU 相关的问题，其中一些已在 BSP40 中修复，而另一些已在以后的版本中修复，如果可能的话，我建议在 BSP42 上对其进行测试 BR 切宁 Re: S32G3: Thermal Shutdown 您好， 我看到了该驱动程序的一个提交 (c5697686c8d19ff1edbce015fa5562ba2a2065e6)。评论中提到了它，但 Jira ID (ALB-10663) 并不匹配。请您确认一次。 Re: S32G3: Thermal Shutdown 你好，@yellapu_anishkh 感谢您的回复。 我检查了源代码，建议尽可能在 BSP42（或更新版本）下对您的情况进行测试，因为从这个版本开始应用了一些错误修复，从现有信息来看，您提到的错误也得到了修复。 BR 切宁 Re: S32G3: Thermal Shutdown 您好， 在 BSP39 上可以观察到这种情况，BSP39 版本说明中提到了以下问题。 我查看了从 BSP39 到 BSP44 的版本说明，发现当前的错误尚未修复。能否请您确认一下，是否已经修复？ Re: S32G3: Thermal Shutdown 你好，@yellapu_anishkh 谢谢您的帖子。 我知道你可以在基于 S32G3 的定制板上对其进行测试，对吗？我能知道你在使用哪个版本的电路板支持包吗？一旦确认，我会首先检查内核代码。 BR 切宁

使用 MCAL 向传输 FIFO 执行 S32K312 LPUART0 DMA 传输。 你好 我确认中断方法正常工作。 但是，DMA 方法不起作用。 在 Mcl_Init(NULL_PRT);中出现硬故障。 uart dma 相关示例使用的是 flexio dma，所以我不确定问题出在哪里。 请检查一下。 Re: Use MCAL to perform S32K312 LPUART0 DMA transfer to the transfer FIFO. 终于解决了 我漏掉了 "dma mux source: enable"。 Re: Use MCAL to perform S32K312 LPUART0 DMA transfer to the transfer FIFO. 你好，Robin Shen。 按照您的指示，激活 DMAMUX_0 不会导致任何错误。 然而，它仍然不起作用。 对于 tx，没有任何操作；对于 rx，当从终端接收到第一 和第二个字节时，会发生 “LPUART_UART_IP_STATUS_RX_OVERRUN”。 这种情况已经持续两周了。 如果您能提供更详细的信息，我将不胜感激。 此外，没有出现 dmarx 和 dmatx 中断。 已使用 DeepL.com 翻译（免费版） Re: Use MCAL to perform S32K312 LPUART0 DMA transfer to the transfer FIFO. 你好 请配置 McuPeripheral -> 外设时钟启用 看来你忘记启用这些外设的时钟门了：EDMA\DMAMUX_0 祝好， Robin ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"ACCEPT AS SOLUTION" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题并参考已关闭的主题。 -------------------------------------------------------------------------------

LPC55S36 I3C 主站在读取长度超过从站数据大小时挂起 我连接了两块用于 I3C 通信的 LPC5536-EVK 板，其中一块配置为 I3C 主板，另一块配置为 I3C 从机。如果主站指定的读取长度超过从站提供的数据量，主站就会卡在读取函数I3C_MasterTransferBlocking 中。根据波形，信号似乎是正确的，因此我认为问题出在主控端。 在我提供的示例中，从属服务器的数据是 [0x01，0x02]，长度仅为 2 字节。但是，主服务器将读取长度指定为 3。因此，在第 2 字节的末尾，Slave 将 T-Bit 作为 0 返回，以表示消息结束。 测试步骤： (1) RESET 从属板 (2) RESET 主板 有关 T 位的定义，请参阅《MIPI I3C 基本规范》v1.1.1。 第 5.1.2.3.4 节、SDR 目标返回（读取）数据的第九位为数据结束位 在 I2C 中，"从目标读取 "有一个问题，即只有控制器才能结束读取，因此目标无法控制其返回的数据量。相比之下，在 I3C SDR 中，目标可控制其返回的数据字数；但它也允许 I3C 控制器在必要时提前终止读取。 ... Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 尽管用户无法确定i3c_masterTransferNonBlocking实际传输了多少字节，但对于我的应用程序来说，这似乎已经足够了。 Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 我尝试改用I3C_MasterTransferNonBlocking。尽管它不会挂起，但用户无法知道Slave实际提供了多少字节。在我分享的示例中，它需要返回传输计数 = 2 这样的信息。 在你使用 lpcxpresso55s36_i3c_interrupt_b2b_transfer_master 示例进行测试时，尽管你将 dataSize 更改为 50，但之后代码仍会打印固定的32字节，这恰好与从属提供的传输数量相匹配。 在实际应用中，例如我在另一篇关于IBI 与待读通知的文章中提到的情况，在发生 IBI 并执行私人读取后，从属设备的传输计数是不可预测的，可能会发生变化。当主站使用大缓冲区调用读取传输函数时，传输函数需要返回实际传输的计数。 Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 你好@黄铃铃 我已经测试过了。 您是对的。 我检查了 I3C_MasterReceive 函数。 /* Check RX data */ if ((0UL != rxSize) && (0UL != (base->MDATACTRL & I3C_MDATACTRL_RXCOUNT_MASK))) { *buf++ = (uint8_t)(base->MRDATAB & I3C_MRDATAB_VALUE_MASK); rxSize--; if ((flags & (uint32_t)kI3C_TransferDisableRxTermFlag) == 0UL) { if ((!isRxAutoTerm) && (rxSize == 1U)) { base->MCTRL |= I3C_MCTRL_RDTERM(1U); } } } 它读取数据的大小取决于数据的大小。 我测试了 i3c 中断演示，它支持这一功能。 我将dataSize设置为 50。 它从来没有挂过。 您可以试试看。 BR 哈利

恩智浦 OTA 示例中的不可缓存区域 亲爱的各位， 我试图使用这里给出的 OTA 机制示例： https://github.com/nxp-mcuxpresso/mcuxsdk-examples/tree/release/25.09.00-pvw1/_boards/evkbmimxrt1170/ota_examples/mcuboot_opensource 链接器脚本中有一节： /* Specify the memory areas */ MEMORY { m_flash_config (RX) : ORIGIN = 0x30000400, LENGTH = 0x00000C00 m_ivt (RX) : ORIGIN = 0x30001000, LENGTH = 0x00001000 m_interrupts (RX) : ORIGIN = 0x30002000, LENGTH = 0x00000400 m_text (RX) : ORIGIN = 0x30002400, LENGTH = TEXT_SIZE m_qacode (RX) : ORIGIN = 0x00000000, LENGTH = 0x00040000 m_data (RW) : ORIGIN = 0x20240000, LENGTH = 0x00040000 m_data2 (RW) : ORIGIN = 0x202C0000 + RPMSG_SHMEM_SIZE, LENGTH = 0x00080000 - RPMSG_SHMEM_SIZE rpmsg_sh_mem (RW) : ORIGIN = 0x202C0000, LENGTH = RPMSG_SHMEM_SIZE m_core1_image (RX) : ORIGIN = CORE1IMAGE_START, LENGTH = 0x00040000 } Then later there is: __NDATA_ROM = __ram_function_flash_start + (__ram_function_end__ - __ram_function_start__); .ncache.init : AT(__NDATA_ROM) { __noncachedata_start__ = .; /* create a global symbol at ncache data start */ *(NonCacheable.init) . = ALIGN(4); __noncachedata_init_end__ = .; /* create a global symbol at initialized ncache data end */ } > m_data2 . = __noncachedata_init_end__; .ncache : { *(NonCacheable) . = ALIGN(4); __noncachedata_end__ = .; /* define a global symbol at ncache data end */ } > m_data2 这将额外的不可缓存部分定义为 OCRAM2 的剩余部分（从 202C_0000 到 2033_FFFF - 512KB）。 不过，Board_ConfigMPU 确实： https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/release/25.09.00-pvw1/_boards/evkbmimxrt1170/board.c #if defined(CACHE_MODE_WRITE_THROUGH) && CACHE_MODE_WRITE_THROUGH /* Region 6 setting: Memory with Normal type, not shareable, write through */ MPU->RBAR = ARM_MPU_RBAR(6, 0x20200000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 0, 0, ARM_MPU_REGION_SIZE_1MB); /* Region 7 setting: Memory with Normal type, not shareable, write trough */ MPU->RBAR = ARM_MPU_RBAR(7, 0x20300000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 0, 0, ARM_MPU_REGION_SIZE_512KB); #else /* Region 6 setting: Memory with Normal type, not shareable, outer/inner write back */ MPU->RBAR = ARM_MPU_RBAR(6, 0x20200000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_1MB); /* Region 7 setting: Memory with Normal type, not shareable, outer/inner write back */ MPU->RBAR = ARM_MPU_RBAR(7, 0x20300000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_512KB); #endif 将此内存扇区标记为可缓存。 有谁能告诉我，示例代码是否真的将 m_data2 的提醒标记为不可缓存？ 或者换句话说--谁能告诉我如何实现这一目标--在我们的应用程序中，我们希望将这一 ram 部分的剩余部分用作非高速缓存。 感谢您的支持 Re: Non-Cachable region in NXP OTA example 你好@jslota13245、 感谢您对 NXP MIMXRT 系列的关注！ OCRAM 是一个可缓存区域。针对您的应用场景，请参考本指南： https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/Using-NonCached-Memory-on-i-MXRT/ta-p/1183369 致以最诚挚的问候， Gavin

#MCUXpresso-IDE 程序 " arm-none-eabi-c++ " 在 PATH 中找不到 你好 我在使用最新版本的MCUXpresso-IDE# 时遇到了一个问题，特此联系您。我最近更换了电脑并安装了 2025 年 6 月 27 日发布的 MCUXpresso-IDE IDE v25.6 [版本 136]。从 Git 导入我的项目后，它无法编译。我收到了以下错误消息：" 在 PATH " 中找不到程序 “arm-none-eabi-c++” 和 " 在 PATH 中找不到程序 “arm-none-eabi-gcc”。 在之前版本的 McuXpresso-IDE（v24.12 [Build 148]）上，这个项目运行良好。有趣的是，我可以在新版本中创建新项目，并顺利编译它们。此外，我还可以导入和编译其他项目，但有一个项目有问题。 经过比较，我发现在这个特定项目的链接资源中缺少了一些路径变量：cmsis_pack_root、$、cmsis-rte 和 $。 您能帮我解决这个问题吗？ 开发板 Re: #MCUXpresso-IDE Program "arm-none-eabi-c++" not found in PATH 嗨，@脑残粉 根据你的描述，这可能是 MCUXpresso IDE 25.03 的问题。 遗憾的是，我无法获得有关该问题的更详细描述，也无法重现该问题，因此无法找到根本原因。 BR 哈利 Re: #MCUXpresso-IDE Program "arm-none-eabi-c++" not found in PATH 你好@Harry_Zhang、 谢谢您的答复。我刚刚进行了检查，工具链的参数完全相同。如果它能帮助你理解问题，我已经在新电脑上安装了版本 mcuxPresso IDE v24.12 [Build 148] [2025-01-10]，这个项目运行良好。因此，这不是操作系统的问题。 不幸的是，我无法将我的 GIT 与项目一起附上。 Re: #MCUXpresso-IDE Program "arm-none-eabi-c++" not found in PATH 嗨，@脑残粉 新项目运行正常 → 工具链已在 v25.6 中正确安装。 因此，我认为您可以检查工具链设置 右键单击有问题的项目 → 属性 如果问题仍未解决，您可以链接您的 git。我可以试试。 BR 哈利

バンドギャップ電圧測定 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> これは、マイクロコントローラに搭載されているバンドギャップ電圧の測定を示すSWの例です。 バンドギャップ電圧は、内部ATDチャネルにルーティングされます。ATDコンバータは入力電圧を測定し、フラッシュメモリにある変数に格納します。 SWサンプルプロジェクトは、MC9S12XEP100デバイス用のCodeWarrior v5.1で作成されています。 全般

ニュー・キッド・オン・ザ・ブロック - 60 GHz Wi-Fi <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ユビキタスなコネクティビティの時代を駆け抜け、データに対する飽くなき需要が求められる中、高速コネクティビティソリューションの必要性はかつてないほど高まっています。60 GHzまたは802.11ad Wi-Fiは、家庭やオフィス、高密度の屋内または屋外スペース、フロントホールまたはバックホールアプリケーションなど、あらゆる場所でブロックを引き継ぐ新しい子供です。さらに、この分野は、このマルチギガビットレートスペクトルを最大限に活用するための革新的なアプローチを持つ多くの新しいティア2プレーヤーによって主に影響を受けています。NXPに参加して、当社のSoCがこのエコシステムを促進するためにどのように不可欠であるかを学びましょう。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ユビキタスなコネクティビティの時代を駆け抜け、データに対する飽くなき需要が求められる中、高速コネクティビティソリューションの必要性はかつてないほど高まっています。60 GHzまたは802.11ad Wi-Fiは、家庭やオフィス、高密度の屋内または屋外スペース、フロントホールまたはバックホールアプリケーションなど、あらゆる場所でブロックを引き継ぐ新しい子供です。さらに、この分野は、このマルチギガビットレートスペクトルを最大限に活用するための革新的なアプローチを持つ多くの新しいティア2プレーヤーによって主に影響を受けています。NXPに参加して、当社のSoCがこのエコシステムを促進するためにどのように不可欠であるかを学びましょう。