Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
Access request for IW612 Zigbee DualPAN Host packages (ZBOSS / zb_mux) on FRDM-i.MX95 Hello NXP Community & Support Team, We are developing a commercial gateway product based on the NXP FRDM-i.MX95 evaluation board featuring the on-board IW612 tri-radio transceiver. Our host environment is Linux ARM64. Our architecture requires simultaneous Thread (Matter) and Zigbee Coordinator operation via the IW612 802.15.4 radio over SPI (/dev/spidev0.0) using the DualPAN architecture. While the OpenThread / OTBR side is well documented and accessible, the Zigbee Coordinator host components and multiplexer required for the IW612 DualPAN setup are restricted deliverables on nxp.com / Secure Files. Our company (Roth Elektronik GmbH) is a direct NXP customer, an active NDA is in place, and our NXP user account profile already shows "Granted" status for Zigbee entitlements. However, the download packages are not visible/accessible in our Secure Files dashboard. We opened support Case No: 01004667, but were redirected to local distributors. Since we procure our silicon and boards directly from NXP and already have the NDA and Zigbee access granted on our corporate account, this needs to be provisioned directly by the NXP software entitlement / product line team. Could an NXP representative or moderator please assist in escalating Case No: 01004667 internally so that the following deliverables are enabled for our account? 1. NXP-ZBOSS-HOST-RELEASE-*.zip (ZBOSS host stack binaries/headers for Linux ARM64, coordinator examples like dualpan_zc / simple_gw) 2. zigbee-rcp-sdk-IW612-*.tar 3. zb_mux host daemon / multiplexer binaries and documentation for IW612 SPI Thank you in advance for your support. Best regards, Mike Teschke Roth Elektronik GmbH Product: WiFi IW6XX Protocol: Zigbee Re: Access request for IW612 Zigbee DualPAN Host packages (ZBOSS / zb_mux) on FRDM-i.MX95 Hello, Hope you are doing well. For files that are under Secure Files: Secure Access Rights | NXP Semiconductors Could you please follow the process?  I would recommend checking the Secure Access Rights FAQs | NXP Semiconductors If you still have issues, I would recommend contacting one of our distributors available in the Distributor Network|NXP to help you with your request. Also, if you are working with any Module Maker, they could help you getting specific support for their module. Best Regards, Ricardo
記事全体を表示
Oscillator transconductance question of S32K144 Hello: In my application design, a 8MHz crystal is used and the SCG_SOSCCFG[RANGE] is set to 2b11, therefore the gmXOSC shall be 16mA/V minimum and 47mA/V maximum Stanley_Xu_0-1790056309153.png And I followed the equation gm_crit = 4 * (ESR + RS) * (2πF)^2 * (C0 + CL)^2 to calculate and compare 5*gm_crit to the datasheet value. Should I use 16mA/V or use 47mA/V ? I don't know if 16 ~47mA/V means part to part variation. If so, from WCCA perspective, I think I shall guarantee the 5*gm_crit < 16mA/V. However, what confused me is in the document AN5426 page 11. The given calculation example uses 47mA/V as criteria. Stanley_Xu_1-1790056639984.png Can some one help me to clarify? Thank you! Re: Oscillator transconductance question of S32K144 Hello @Stanley_Xu, Strictly for WCCA, use the minimum gmXOSC = 16 mA/V. The 16–47 mA/V range reflects combined process (part-to-part), voltage, and temperature variation — any given part will deliver a gmXOSC somewhere in that range. The datasheet criterion gmXOSC > 5 × gm_crit guarantees proper oscillation startup and 5x gm_crit can be considered as very safe, while 3x gm_crit is still safe. Regarding AN5426: the example uses 47 mA/V (max) for illustration, not as a WCCA. On the other hand, the datasheet also notes: "RS should be selected carefully to have appropriate oscillation amplitude for both protecting crystal or resonator device and satisfying proper oscillation startup condition." Regards, Daniel
記事全体を表示
FRDM-i.MX95上のIW612 Zigbee DualPANホストパッケージ(ZBOSS / zb_mux)へのアクセスリクエスト NXPコミュニティ&サポートチームの皆様、こんにちは。 私たちは、オンボードのIW612トライラジオトランシーバーを搭載したNXP FRDM-i.MX95評価ボードをベースにした商用ゲートウェイ製品を開発しています。ホスト環境はLinux ARM64です。 私たちのアーキテクチャでは、DualPANアーキテクチャを用いたIW612 802.15.4無線を介して、SPI(/dev/spidev0.0)を介してThread(Matter)とZigbeeコーディネーターの同時運用が必要です。 OpenThread / OTBR側はよくドキュメント化されアクセス可能ですが、IW612 DualPANセットアップに必要なZigbee Coordinatorのホストコンポーネントやマルチプレクサは、nxp.com/Secure Files上の限定的な納品物です。 私たちの会社(Roth Elektronik GmbH)はNXPの直接顧客であり、有効なNDAが成立しており、NXPのユーザーアカウントプロファイルにはすでにZigbeeの権利が「Granted」ステータスと表示されています。しかし、ダウンロードパッケージは当社のSecure Filesダッシュボードでは表示・アクセスできません。 私たちはサポートケース番号01004667を開設しましたが、地元の代理店にリダイレクトされました。シリコンと基板はNXPから直接調達しており、すでにNDAとZigBeeのアクセスが当社の企業情報アカウントで付与されているため、これらはNXPのソフトウェア権限付与/製品ラインチームが直接プロビジョニングする必要があります。 NXPの担当者またはモデレーターの方が、ケース番号:01004667を社内でエスカレーションし、以下の成果物が当アカウントで有効になるよう支援していただけませんか? 1. NXP-ZBOSS-HOST-RELEASE-*.zip(Linux ARM64用のZBOSSホストスタックバイナリ/ヘッダー、dualpan_zc/simple_gwなどのコーディネーター例) 2. zigbee-rcp-sdk-IW612-*.tar 3. zb_mux IW612 SPIのホストデーモン/多重化バイナリおよびドキュメント サポートにあらかじめ感謝いたします。 よろしくお願いします、 マイク・テシュケ Roth Elektronik GmbH 製品: WiFi IW6XX プロトコル:Zigbee Re: Access request for IW612 Zigbee DualPAN Host packages (ZBOSS / zb_mux) on FRDM-i.MX95 こんにちは、 あなたの調子が良いといいのですが。Secure Filesの項目にあるファイル: Secure Access Rights |NXPセミコンダクターズ その手順に従っていただけますか? Secure Access Rights FAQs(セキュリティアクセス権FAQ)をご確認することをおすすめします |NXPセミコンダクターズ それでも問題がある場合は、代理店ネットワーク 内の当社の代理店のいずれかにご連絡いただくことをお勧めします。NXPのお願いにご協力いただけると助かります。 また、モジュールメーカーを使っているなら、そのモジュールの具体的なサポートを手助けしてくれるかもしれません。 よろしくお願いいたします。 リカルド
記事全体を表示
Adapting MCSPTR2AK396 reference firmware (AMMCLIB/FreeMASTER) for custom hardware with high-side sen Hello NXP Community, I am currently developing a motor control application using the S32K396 MCU and testing it via FreeMASTER / AMMCLIB. As a starting point, I am using the reference firmware provided for the MCSPTR2AK396 evaluation kit. However, my custom hardware design differs significantly from the reference EVK board in three main areas: Current Sensing Topology: EVK Board: Low-side current sensing. Custom Design: High-side current sensing. Gate Driver Configuration: EVK Board: Single pre-driver (GD3000 / MC33937 type). Custom Design: Three separate, independent gate drivers (one dedicated driver per phase) with direct active-high control inputs. PWM Polarity: EVK Board: High-side PWM inputs are active-low (inverted). Custom Design: High-side PWM inputs are active-high (non-inverted). Because of these hardware discrepancies, running the original MCSPTR2AK396 firmware out-of-the-box results in faults and incorrect phase behavior. Could you please advise on the best approach or provide a checklist for modifying the S32K396 initialization, PWM/eMIOS configuration, ADC trigger timings, and AMMCLIB software layers to successfully migrate from the EVK design to my custom architecture? Any guidance, code snippets, or configuration pointers would be greatly appreciated. Thank you! Regards, Esakki Re: Adapting MCSPTR2AK396 reference firmware (AMMCLIB/FreeMASTER) for custom hardware with high-side Hi, The changes you described (high-side current sensing, different gate driver architecture, PWM polarity changes, and the associated motor-control software adaptations) represent a significant shift from the MCSPTR2AK396 reference design and require substantial modifications to the reference solution. Due to the project-specific nature and complexity of this work, we are unable to provide a complete migration guide through the standard support channel. For dedicated assistance with adapting the reference software to your custom hardware, please consider engaging NXP Professional Engineering Services: NXP Engineering Services Best regards, Petr
記事全体を表示
MIMXRT700-EVK フラッシュエラー こんにちは、 NXP LinkServerを使って MIMXRT700-EVK にアプリケーションをフラッシュできません。 ハードウェア/ソフトウェア: ボード: MIMXRT700-EVK MCU:MIMXRT798S デバッガ:搭載MCU-Link MCU-Linkファームウェア:V3.172 リンクサーバー: 26.6.137 OS:Ubuntu Linux 電源はJ54から供給されます。 フラッシュ処理中、LinkServerは以下を報告します。 Error: Wire Ack Fault - target connected? Error: Wire not connected Failed on connect: Ee(42). Could not connect to core. No connection to chip's debug port Flash operation exited with code 1 MCU-LinkはPCによって正しく検出され、LinkServerはプローブを検出できます。 重要なハードウェアの観察点は、D4の赤いLEDが点灯していないことです。MIMXRT700-EVKのドキュメントによると、D4はMCU/リセットの状態を示し、ONは通常のプロセッサ活動、OFFはプロセッサがリセット中であることを示します。 RT700のプリコネクトスクリプトも実行しましたが、SWD接続は依然として以下のエラーで失敗します。 Error: Wire Ack Fault - target connected? Error: Wire not connected サポートリクエスト 何かアドバイスをいただけますか: 基板がJ54から電源供給されているのに、 D4 LEDが消灯しているのはなぜですか? RT700プロセッサをリセット状態からどうやって解除 できますか? リセット、起動、またはハードウェア構成の確認が必要な項目はありますか? アプリケーションをフラッシュするためにLinkServerのコネクティビティを復元するには、どのような復旧手順を使えばよいでしょうか? 評価ボード Re: MIMXRT700-EVK Flashing Error こんにちは、@Aparna1 さん。 おそらく、電力がMCUや基板全体に適切に分配されておらず、搭載デバッガにだけ送られている可能性が高いです。 緑色のD10 LEDも消灯していますか? J2のジャンパー位置がピン7と8をショートさせていることを確認してください。 BR、 エドウィン。 Re: MIMXRT700-EVK Flashing Error これはUSB接続後の状態です Re: MIMXRT700-EVK Flashing Error こんにちは、 はい、以下の点を確認しました。 緑色のD10 LEDが点灯しています。 J2はピン7と8を短絡させている。 私の方で追加の確認が必要な場合はお知らせください。 よろしくお願いいたします。 アパルナ Re: MIMXRT700-EVK Flashing Error こんにちは、 チケットの状況を教えていただけますか?まだ返答を待っています。   よろしくお願いします。    
記事全体を表示
ハイサイドセンシングを備えたカスタムハードウェア向けにMCSPTR2AK396リファレンスファームウェア(AMMCLIB/FreeMASTER)を適応させる こんにちは、NXPコミュニティの皆さん、 現在、 S32K396 MCU を使ってモーター制御アプリケーションを開発し、 FreeMASTER / AMMCLIBを通じてテストしています。まず手始めに、 MCSPTR2AK396評価キットに付属のリファレンスファームウェアを使用します。 しかし、私のカスタムハードウェア設計は、主に3つの点でリファレンスEVKボードと大きく異なります。 電流検出トポロジー: EVKボード:ローサイド電流検出。 カスタムデザイン: ハイサイド電流検出。 ゲートドライバー構成: EVKボード: シングルプリドライバー(GD3000 / MC33937タイプ)。 カスタム設計: 3つの独立したゲートドライバ(各相に1つの専用ドライバ)を持ち、直接のアクティブハイ制御入力を備えています。 PWM極性: EVKボード:ハイサイドPWM入力はアクティブロー(反転)です。 カスタム設計: ハイサイドPWM入力はアクティブハイ(反逆なし)です。 これらのハードウェアの不一致により、オリジナルのMCSPTR2AK396ファームウェアをそのまま実行すると、不具合や位相動作の誤りが発生します。 EVK設計からカスタムアーキテクチャへの移行に成功させるために、S32K396初期化、PWM/eMIOS設定、ADCトリガータイミング、AMMCLIBソフトウェア層の変更に関する最適な方法やチェックリストを教えていただけませんか? 何かアドバイスやコードスニペット、設定のヒントがあれば大変ありがたいです。 ありがとう! よろしくお願いいたします。 エサッキ Re: Adapting MCSPTR2AK396 reference firmware (AMMCLIB/FreeMASTER) for custom hardware with high-side こんにちは、 あなたが述べた変更点(ハイサイド電流検出、異なるゲートドライバアーキテクチャ、PWM極性の変更、そしてそれに伴うモータ制御ソフトウェアの適応)は、MCSPTR2AK396のリファレンス・デザインからの大きな変化を示しており、リファレンスソリューションに大幅な修正が必要です。 本作業はプロジェクト固有の性質と複雑さのため、標準サポートチャネルを通じて完全な移行ガイドを提供することはできません。 カスタムハードウェアにリファレンスソフトウェアを適応させるための専用サポートをご希望の方は、ぜひNXPプロフェッショナルエンジニアリングサービスにご相談ください。 NXPエンジニアリング・サービス よろしくお願いします、 ペトル
記事全体を表示
EtherCAT and 100Base T1 AtomDeng_0-1790068593516.jpeg AtomDeng_1-1790068718278.png It can be seen from this photo that it supports 100BASE-T1, but the actual situation is that the development board does not have this T1 interface. Board Design MCXC Re: EtherCAT and 100Base T1 Hi @AtomDeng , Thanks for your interest in NXP MIMXRT series! The diagram is an application-level system block diagram, not the hardware block diagram of the MIMXRT1180-EVK. It shows that the i.MX RT1180 Ethernet/EtherCAT interfaces can be connected to external TJA1103 PHYs to implement 100BASE-T1. The MIMXRT1180-EVK itself does not populate TJA1103 PHYs or 100BASE-T1 connectors. Its five onboard Ethernet ports use standard 10/100BASE-TX or 10/100/1000BASE-T PHYs with RJ45 connectors. Please check this diagram in <UM12021 MIMXRT1180-EVK Board User Manual >: Gavin_Jia_0-1790127234062.png Best regards, Gavin Re: EtherCAT and 100Base T1 "While the reference photo or documentation indicates support for 100BASE-T1, the physical connector is likely omitted on this specific board variant. This is common in development hardware where the underlying PHY chip or circuit traces may be present on the PCB, but the physical automotive connector is unpopulated to reduce costs, or the signals are routed to standard pin headers instead." 
記事全体を表示
EtherCAT and 100Base T1 AtomDeng_0-1790068593516.jpeg AtomDeng_1-1790068718278.png It can be seen from this photo that it supports 100BASE-T1, but the actual situation is that the development board does not have this T1 interface. Board Design MCXC Re: EtherCAT and 100Base T1 你好@AtomDeng , 感谢您对 NXP MIMXRT 系列产品的关注! 该图是应用级系统框图,而不是 MIMXRT1180-EVK 的硬件框图。它表明 i.MX RT1180 以太网/EtherCAT 接口可以连接到外部 TJA1103 PHY 以实现 100BASE-T1。 MIMXRT1180-EVK 本身不包含 TJA1103 PHY 或 100BASE-T1 连接器。其五个板载以太网端口采用标准的 10/100BASE-TX 或 10/100/1000BASE-T PHY,并带有 RJ45 连接器。 请查看《 UM12021 MIMXRT1180-EVK 开发板用户手册》中的这张图表: Gavin_Jia_0-1790127234062.png 此致, 加文 Re: EtherCAT and 100Base T1 “虽然参考照片或文档表明支持 100BASE-T1,但此特定电路板版本可能省略了物理连接器。”这在开发硬件中很常见,底层PHY芯片或电路走线可能已经位于PCB上,但为了降低成本,物理汽车连接器可能没有安装元件,或者信号被路由到标准针座上。
記事全体を表示
对 FRDM-i.MX95 上的 IW612 Zigbee DualPAN 主机软件包 (ZBOSS / zb_mux) 的访问请求 您好,NXP社区与支持团队, 我们正在开发一款基于 NXP FRDM-i.MX95 评估板的商用网关产品,该评估板配备了板载 IW612 三频收发器。我们的主机环境是Linux ARM64。 我们的架构需要通过 SPI (/dev/spidev0.0) 使用 DualPAN 架构的 IW612 802.15.4 无线电同时进行线程 (Matter) 和 Zigbee 协调器操作。 虽然 OpenThread / OTBR 方面有完善的文档和可访问的说明,但 IW612 DualPAN 设置所需的 Zigbee 协调器主机组件和多路复用器是 nxp.com / Secure Files 上的受限交付物。 我们公司(Roth Elektronik GmbH)是 NXP 的直接客户,我们已签署有效的保密协议,并且我们的 NXP 用户帐户配置文件已显示 Zigbee 授权的“已授予”状态。但是,这些下载包在我们的安全文件控制面板中不可见/无法访问。 我们提交了支持案例编号:01004667,但被转接到了当地代理商。由于我们直接从 NXP 采购芯片和电路板,并且我们的企业帐户已经获得了 NDA 和 Zigbee 访问权限,因此需要由 NXP 软件授权/产品线团队直接进行配置。 恩智浦代表或管理员能否协助将案件编号 01004667 上报至公司内部,以便为我们的账户启用以下交付成果? 1. NXP-ZBOSS-HOST-版本-*.zip(适用于 Linux ARM64 的 ZBOSS 主机堆栈二进制文件/头文件,协调器示例,例如 dualpan_zc / simple_gw) 2. zigbee-rcp-sdk-IW612-*.tar 3. IW612 SPI 的 zb_mux 主机守护进程/多路复用器二进制文件和文档 感谢您提前给予的支持。 此致, 迈克·特施克 罗斯电子有限公司 产品:WiFi IW6XX 协议:Zigbee Re: Access request for IW612 Zigbee DualPAN Host packages (ZBOSS / zb_mux) on FRDM-i.MX95 你好, 希望你一切都好。对于受“安全文件”保护的文件:安全访问权限 | NXP 半导体 请您按照以下步骤操作好吗? 我建议您查看恩智浦半导体 (NXP Semiconductors) 的“安全访问权限常见问题解答”。 如果您仍有疑问,我建议您联系我们代理商网络|NXP中的一位代理商,他们可以帮助您解决您的问题。 此外,如果您与任何模块制作商合作,他们可以帮助您获得针对其模块的特定支持。 顺祝商祺! 里卡多
記事全体を表示
S32K144振荡器跨导问题 你好: 在我的应用设计中,使用了一个 8MHz 晶振,并将 SCG_SOSCCFG[RANGE] 设置为 2b11,因此 gmXOSC 的最小值应为 16mA/V,最大值应为 47mA/V。 Stanley_Xu_0-1790056309153.png 我按照公式 gm_crit = 4 * (ESR + RS) * (2πF)^2 * (C0 + CL)^2 计算并比较了 5*gm_crit 与数据表值。我应该使用 16mA/V 还是 47mA/V? 我不知道 16 ~47mA/V 是否意味着零件间的差异。如果是这样,从 WCCA 的角度来看,我认为我应该保证 5*gm_crit < 16mA/V。然而,让我感到困惑的是文档 AN5426 第 11 页。给出的计算示例使用 47mA/V 作为标准。 Stanley_Xu_1-1790056639984.png 请问有人能帮我解释一下吗?谢谢你! Re: Oscillator transconductance question of S32K144 你好@Stanley_Xu , 严格来说,对于 WCCA,使用最小 gmXOSC = 16 mA/V。16–47 mA/V 的范围反映了工艺(部件之间)、电压和温度的综合变化——任何给定的部件都会在该范围内提供 gmXOSC。数据表标准 gmXOSC > 5 × gm_crit 保证了正确的振荡启动,5x gm_crit 可以被认为是非常安全的,而 3x gm_crit 仍然是安全的。 关于 AN5426:该示例使用 47 mA/V(最大值)进行说明,而不是作为 WCCA。 另一方面,数据手册还指出:“应仔细选择 RS,使其具有合适的振荡幅度,既能保护晶体或谐振器器件,又能满足适当的振荡启动条件。” 此致, 丹尼尔
記事全体を表示
S32K144の発振器相互コンダクタンスに関する質問 こんにちは: 私のアプリケーション設計では8MHzのクリスタルを使用し、SCG_SOSCCFG[範囲]は2b11に設定されているため、gmXOSCは最低16mA/V、最大47mA/Vとしています Stanley_Xu_0-1790056309153.png そして、gm_crit = 4 * (ESR + RS) * (2πF)^2 * (C0 + CL)^2 という式に従って、5*gm_crit を計算し、データシートの値と比較しました。16mA/Vを使うべきか、それとも47mA/Vを使うべきか? 16~47mA/Vというのは、部品ごとのばらつきを意味するのかどうか分かりません。もしそうなら、WCCAの視点からは5星gm_crit <16mA/Vを保証しようと思います。しかし、私を混乱させたのは、文書AN5426の11ページです。提示された計算例では、基準値として47mA/Vを使用しています。 Stanley_Xu_1-1790056639984.png どなたか説明を手伝ってもらえますか?ありがとう! Re: Oscillator transconductance question of S32K144 こんにちは、 @Stanley_Xu さん。 WCCAに限っては、最小gmXOSC = 16 mA/Vを使用してください。16~47 mA/Vの範囲は、製造プロセス(部品間)、電圧、温度の変動を総合的に反映したものであり、どの部品もこの範囲内のgmXOSC値を示す。データシートのクライテリオンGMXOSC > 5× gm_critは適切な発振起動を保証しており、5倍gm_critは非常に安全とみなせますが、3x gm_critも安全です。 AN5426に関して:この例では、WCCAとしてではなく、説明のために47 mA/V(最大)を使用しています。 一方、データシートには「RSは、水晶発振器や共振器デバイスを保護し、適切な発振開始条件を満たすために、適切な発振振幅を持つように慎重に選択する必要がある」とも記載されている。 よろしくお願いいたします。 ダニエル
記事全体を表示
PROMO Coupon Hi, Why is my promo coupon 'ADCWFBXT' not valid for the FRDM-MCXN236. Pramod Joglekar [email protected] Development Board FRDM-Training Re: PROMO Coupon Please note that the coupon ADCWFBXT was valid until December 30th, 2025. As stated at our website: FRDM to Innovate - On us!    Wishing you a nice day. Re: PROMO Coupon Even I am not able to use the promo coupon for FRDM-MCXN236. Re: PROMO Coupon Is their any other coupon available for FRDM-MCXN236 boards ?
記事全体を表示
8MPLUSLPD4-PEVK – 当前 eMMC 和 QSPI 内存配置 你好, 我想确认一下目前出货的 8MPLUSLPD4-PEVK 的内存配置。 NXP 当前的产品页面明确指出: 6 GB LPDDR4 16 GB eMMC 64 MB QSPI 然而,NXP 的 PEVK 快速入门指南明确指出: 6 GB LPDDR4 32 GB eMMC 32 MB QSPI NXP 在线聊天支持建议产品页面可能代表当前的硬件版本,而快速入门指南可能指的是早期版本,但建议与 i.MX 技术团队确认这一点。 NXP 的相关人员能否确认一下当前 8MPLUSLPD4-PEVK 硬件版本的 eMMC 和 QSPI 容量? 谢谢! Re: 8MPLUSLPD4-PEVK – current eMMC and QSPI memory configuration 您好, 感谢您对恩智浦半导体产品的关注, 我已经用我桌上的 8MPLUSLPD4-PEVK 确认过,其配置为 32GB eMMC 和 32MB QSPI。经审查最新原理图修订版,所有版本均未对内存进行重新配置,订购时应收到相同的内存。 我们的团队会审核产品页面,感谢您的分享。 此致
記事全体を表示
MIMXRT700-EVK 刷写错误 你好, 我无法使用 NXP LinkServer 将我的应用程序刷写到MIMXRT700-EVK上。 硬件/软件: 电路板:MIMXRT700-EVK MCU:MIMXRT798S 调试器:板载 MCU-Link MCU-Link固件版本:V3.172 链接服务器:26.6.137 操作系统:Ubuntu Linux 电源通过 J54 提供 刷写过程中,LinkServer 报告: Error: Wire Ack Fault - target connected? Error: Wire not connected Failed on connect: Ee(42). Could not connect to core. No connection to chip's debug port Flash operation exited with code 1 PC 可以正确检测到 MCU-Link,LinkServer 可以检测到探针。 重要的硬件观察结果是D4红色LED指示灯不亮。根据MIMXRT700-EVK文档,D4指示MCU/RESET状态,其中ON表示处理器正常活动,OFF表示处理器处于RESET状态。 我还执行了RT700预连接脚本,但SWD连接仍然失败,并显示以下错误: Error: Wire Ack Fault - target connected? Error: Wire not connected 支持请求 请问您能否提供以下建议: 为什么 当电路板通过 J54 供电时, D4 LED 灯不亮 ? 如何使RT700处理器退出RESET状态? 是否需要检查任何RESET、启动或硬件配置? 我应该使用哪种恢复程序来恢复LinkServer 的连接,以便我可以刷写应用程序? 评估板 Re: MIMXRT700-EVK Flashing Error 嗨@Aparna1 , 电源很可能没有正确分配给 MCU/电路板的其他部分,而是只分配给了板载调试器。 绿色的D10 LED指示灯也熄灭了吗? 请确保 J2 的跳线位置将引脚 7 和 8 短接。 BR, 埃德温。 Re: MIMXRT700-EVK Flashing Error 您好, 是的,我已经核实了以下内容: 绿色D10 LED指示灯亮起。 J2 将引脚 7 和 8 短接。 如果还需要我进行任何额外的检查,请告知。 问候, 阿帕娜 Re: MIMXRT700-EVK Flashing Error 这是连接 USB 后的状态 Re: MIMXRT700-EVK Flashing Error 您好, 请问我的工单有什么最新进展吗?我仍在等待回复。   谢谢!    
記事全体を表示
促销优惠券 您好, 为什么我的促销优惠券“ADCWFBXT”对FRDM-MCXN236无效? 普拉莫德·乔格卡 [email protected] 开发板 FRDM 培训 Re: PROMO Coupon 连我都无法使用FRDM-MCXN236 的促销优惠券。 Re: PROMO Coupon 请注意,优惠券 ADCWFBXT 的有效期至 2025 年 12 月 30 日。正如我们网站上所说: FRDM 创新——由我们负责!   祝您今天愉快。 Re: PROMO Coupon FRDM-MCXN236主板还有其他优惠券吗?
記事全体を表示
8MPLUSLPD4-PEVK – 現在のeMMCおよびQSPIメモリ構成 こんにちは、 現在出荷されている8MPLUSLPD4-PEVKのメモリ構成を確認させていただきたい。 現在のNXP製品ページには次のように記載されています: 6 GB LPDDR4 16GB eMMC 64 MB QSPI しかし、NXPのPEVKクイックスタートガイドには次のように記載されています。 6 GB LPDDR4 32GB eMMC 32 MB QSPI NXPのライブチャットサポートは、製品ページが現在のハードウェアリビジョンを表している可能性が高く、クイックスタートガイドは以前のバージョンを指している可能性があると示唆しましたが、i.MX 技術チームに確認することを勧めました。 NXPの方が現行の8MPLUSLPD4-PEVKハードウェアリビジョンのeMMCおよびQSPI容量を確認できますか? よろしくお願いします。 Re: 8MPLUSLPD4-PEVK – current eMMC and QSPI memory configuration こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 手元にある8MPLUSLPD4-PEVKで確認したところ、構成は32GBのeMMCと32MBのQSPIでした。最新の回路図リビジョンを確認したところ、どのリビジョンでもメモリの再構成は行われておらず、注文時に同じメモリが届くはずです。 私たちのチームが製品ページをレビューします。共有してくださりありがとうございます。 よろしくお願いします。
記事全体を表示
プロモーションクーポン こんにちは、 私のプロモーションクーポン「ADCWFBXT」がFRDM-MCXN236に有効でないのはなぜですか? プラモド・ジョグレカール [email protected] 開発ボード FRDMトレーニング Re: PROMO Coupon 私もFRDM-MCXN236のプロモーションクーポンを使うことができませんでした。 Re: PROMO Coupon クーポンコードADCWFBXTは2025年12月30日まで有効でしたのでご注意ください。当社のウェブサイトに記載されているとおり、 FRDMはイノベーションを推進します。費用は当社が負担します!   良い一日をお過ごしください。 Re: PROMO Coupon FRDM-MCXN236ボード用の他のクーポンはありますか?
記事全体を表示
2-CH CAN HAT with FRDM-IMX93 Enabling a 2-Channel CAN HAT (MCP2515) on the NXP i.MX93 FRDM Board This article documents the process of adding hardware support for a 2-Channel CAN HAT from WaveShare using dual Microchip MCP2515 controllers over SPI on the NXP i.MX93 FRDM evaluation board. By default, the board exposes native FlexCAN interfaces, but utilizing a popular Raspberry Pi-compatible CAN HAT requires customizing the Linux device tree and kernel configuration. Prerequisites Hardware: NXP i.MX93 FRDM board, 2-Channel CAN HAT. Software: NXP Linux BSP (Tested in 6.18.y). Toolchain: Toolchain obtained from Yocto (Refer to the 4.5.12 How to build U-Boot and Kernel in standalone environment from i.MX Linux User's Guide). Step 1: Modify the Device Tree We need to edit the main board device tree file  arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts  to configure the SPI master, add the dual MCP2515 nodes, assign interrupt pins, and disable conflicting native interfaces. The key changes: Power Regulators: Ensured the expansion connectors ( VEXP_3V3 and VEXP_5V ) correctly pull up and preserve state using pinctrl-assert-gpios . Fixed Clock: Defined an external 16MHz clock element required by the MCP2515 crystal oscillators. FlexCAN Deactivation: Disabled conflicting native flexcan2 nodes sharing pins. LPSPI3 Configuration: Replaced the default spidev dummy node with two microchip,mcp2515 nodes, adding two distinct Chip Select (CS) pins ( GPIO2_IO08 and GPIO2_IO07 ) and mapping the respective hardware interrupts ( GPIO2_IO23 and GPIO2_IO25 ). Device Tree Git Diff: diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts index 18afe964e020..7b3af73f144f 100644 --- a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts @@ -134,6 +134,7 @@ reg_vexp_3v3: regulator-vexp-3v3 { compatible = "regulator-fixed"; regulator-name = "VEXP_3V3"; gpio = <&pcal6524 2 GPIO_ACTIVE_HIGH>; + pinctrl-assert-gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; enable-active-high; @@ -144,6 +145,7 @@ reg_vexp_5v: regulator-vexp-5v { compatible = "regulator-fixed"; regulator-name = "VEXP_5V"; gpio = <&pcal6524 8 GPIO_ACTIVE_HIGH>; + pinctrl-assert-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; enable-active-high; @@ -269,6 +271,15 @@ K3: user_btn2 { interrupts = <6 IRQ_TYPE_EDGE_FALLING>; }; }; + + clocks { + clk16m: clk16m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <16000000>; + clock-output-names = "clk16m"; + }; + }; }; &adc1 { @@ -292,7 +303,7 @@ &flexcan2 { pinctrl-0 = <&pinctrl_flexcan2>; pinctrl-1 = <&pinctrl_flexcan2_sleep>; xceiver-supply = <&reg_can2_stby>; - status = "okay"; + status = "disabled"; }; &mu1 { @@ -620,15 +631,29 @@ typec1_dr_sw: endpoint { &lpspi3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpspi3>; - cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; - pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; + cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>, <&gpio2 7 GPIO_ACTIVE_LOW>; + pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_LOW>; status = "okay"; - spidev0: spi@0 { + can0: can@0 { + compatible = "microchip,mcp2515"; reg = <0>; - compatible = "lwn,bk4"; - spi-max-frequency = <1000000>; + clocks = <&clk16m>; + interrupt-parent = <&gpio2>; + interrupts = <23 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <10000000>; }; + + can1: can@1 { + compatible = "microchip,mcp2515"; + reg = <1>; + clocks = <&clk16m>; + interrupt-parent = <&gpio2>; + interrupts = <25 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <10000000>; + }; + + }; &lpuart1 { /* console */ @@ -894,9 +919,12 @@ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e pinctrl_lpspi3: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO08__GPIO2_IO08 0x39e + MX93_PAD_GPIO_IO07__GPIO2_IO07 0x39e MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x39e MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x39e MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x39e + MX93_PAD_GPIO_IO23__GPIO2_IO23 0x39e + MX93_PAD_GPIO_IO25__GPIO2_IO25 0x39e >; }; After modifying the file, compile your device tree blobs (.dtb) and deploy them to your target boot partition. You can refer to the below post to know the process: How to compile Linux Kernel Image and device tree using Yocto SDK. Step 2: Enable Kernel Driver Support The MCP251x driver must be enabled within the Linux kernel configuration framework. Run the configuration tool: user@host:~/linux-imx$ make menuconfig Navigate through the menu to enable the driver either statically ( [*] ) or as a module ( [M] 😞 [*] Networking support <*> CAN bus subsystem support <*> Raw CAN Protocol (raw access with CAN-ID filtering)   <*> Broadcast Manager CAN Protocol (with content filtering) <*> CAN Gateway/Router (with netlink configuration) And: Device Drivers [*] Network device support <*> CAN Device Drivers CAN SPI interfaces <*> Microchip MCP251x and MCP25625 SPI CAN controllers <*> Microchip MCP251xFD SPI CAN controllers Save your configuration and compile your kernel/modules. Step 3: Initialize and Test Interfaces Once the board boots with the new device tree and kernel, you should see two new network interfaces listed under ip link show ( can0 and can1 ). Manuel_Salas_0-1790114307590.png Now, you can setup the CAN interfaces: $ sudo ip link set can0 up type can bitrate 1000000 $ sudo ip link set can1 up type can bitrate 1000000 $ sudo ifconfig can0 txqueuelen 65536 $ sudo ifconfig can1 txqueuelen 65536 Connect the HAT in loopback: Manuel_Salas_5-1790114793732.png From Interface can0: candump can0 From interface can1: cansend can1 000#11.22.33.44 Manuel_Salas_1-1790114548204.png Manuel_Salas_2-1790114560757.png Manuel_Salas_3-1790114583087.png Hope this can be helpful. Best regards, Salas. i.MX93
記事全体を表示
External Boot S32k Does the S32k344 device initially execute an immutable first-stage bootloader from internal ROM? If so, can this ROM bootloader be configured to load a secondary bootloader (or application image) from an external source, such as external flash? If external boot is supported, how would this be configured so the initial bootloader knows where to pull from? Re: External Boot S32k Hi @CTCoder1  Yes, S32K344 contains SBAF code which is executed after reset. However, this should not be considered a configurable bootloader that can directly load an application from an arbitrary external memory. External boot is not supported. The normal S32K3 boot flow expects the boot information/application in the internal code flash only. For example, a user bootloader can be placed at the beginning of internal flash (IVT at 0x00400000) and then execute whatever update/loading mechanism is required.  So, if the intention is to store an application in an external flash, the usual solution is to have user bootloader in internal flash. This bootloader initializes the required peripheral/external memory interface, reads the image from the external device and then either programs it into internal flash or handles it according to the application's requirements. There is no SBAF (or we can say BootROM) configuration where you simply specify an external flash address/device and have the S32K344 SBAF boot the application directly from there. This needs to be managed completely by your software. Regards, Lukas
記事全体を表示
S32K3xxマスターECUキーまたはCUST/OEM認証キーのインポート こんにちは、NXPさん。 いつもサポートしてくださりありがとうございます。 FBL関連のお問い合わせに対する以前のご回答に基づき、ライフサイクルがインフィールド状態にある場合、スーパーユーザー(SU)権限を取得するには、MASTER_ECU_KEYまたはCUST/OEM認証キーのいずれかを事前にプロビジョニングしておく必要があり、デバイスが既にインフィールド状態にある場合は、MASTER_ECU_KEYのプロビジョニングは不可能であると理解いたしました。 私たちの理解が正しいか確認していただけますか? 現在、これら2つのキーはどちらもプロビジョニングされていません。今後同様の問題が起きないように、MASTER_ECU_KEYまたはCUST/OEM認証キーのいずれかを事前にプロビジョニングし、NVM/RAMキーカタログをフォーマットし、デバイスがインフィールド状態に入った後にHMACキーを注入できるようにしたいと考えています。 いくつか質問があります。 1.このプロジェクトでは、FBL認証はSHEに基づいていません。その代わりに、RSA公開鍵署名検証方式を採用している。ただし、CRYPTO_SPT_SHE は STD_ON に設定されています。 この場合、MASTER_ECU_KEYをプロビジョニングすべきか、それともCUST/OEM認証キーをプロビジョニングすべきか? 2. MASTER_ECU_KEYやCUST/OEM認証キーのインポート方法を説明するガイドやドキュメントはありますか? ありがとうございます。 よろしくお願いいたします。 Re: S32K3xx Master_ECU_KEY or CUST/OEM authorization key import こんにちは、 @jeongwoo 認証キーは、現在のライフサイクルと、操作に使用するキーの所有者に応じてプロビジョニングする必要があります。 CUST_DELでは、CUST認証キーをプロビジョニングできます。デバイスをOEM_PRODに進めると、OEM認証キーをプロビジョニングし、それを使ってOEM所有キーのスーパーユーザー権を取得することができます。 CUST_DEL中はOEM所有の鍵をプロビジョニングすることはできません。なぜなら、その時点で操作を承認できるOEM認可キーが持っていないからです。したがって、必要な所有者向けのキーカタログは、デバイスがライフサイクルを進める前に、CUST_DEL状態にある間に既に定義しておく必要があります。 OEM_PRODに移行した後は、キーカタログのフォーマットがCUST_DELに制限されるため、カタログの再フォーマットはできません。このライフサイクルの移行は不可逆的である。 ですので、CUSTとOEMの両方の認可機能を持つつもりなら、まずカタログで必要なCUSTおよびOEMキーグループを定義し、CUST_DELでCUST認証キーをプロビジョニングし、OEM_PRODに進み、最後にOEM認証キーをプロビジョニングしてください。 詳細はこのスレッドをご覧ください: https://community.nxp.com/t5/S32K/Change-is-not-possible-in-LC-OEM-PROD/m-p/2356576 HSEレベルでは、キーインポート手順はHSE-Bファームウェアリファレンスマニュアルの「6.2.3 キーインポート」セクションで説明されています。2.8の後に、HSEファームウェアバージョンのHSE Service APIリファレンスマニュアルにある「struct hseImportKeySrv_t」の説明を参照してください。 On AUTOSAR Crypto ドライバ level, it is given by AUTOSAR specification.Crypto_43_HSE_KeyElementSet()およびCrypto_43_HSE_KeySetValid()APIの説明はRTD_CRYPTO_43_HSE_UM.pdfで読むことができます。 認証キーは他のキーと同様の方法でインポートされますが、コンフィギュレータでそのキーに対してUSAGE_AUTHORIZATIONとUSAGE_VERIFYのキーフラグを設定する必要があります。 よろしくお願いいたします。 ルーカス
記事全体を表示