Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
IMX8M PLUS LPDDR4 2G互換性 ISSI IS43LQ32512A-046BLI 2GB RAM を実装してみます。キャリブレーション後、2000MHz に設定されたmemcpy SSN armv8_x32 テスト中に RAM が失敗します。 RAM を 1500MHz に設定すると、すべてのテストに合格します。 この LPDDR4 RAM を実装した人はいますか?IMX8M PLUSと全般的に互換性がありますか? i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M ミニ | i.MX 8M ナノ Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye DDR 構成ツールを使用してキャリブレーションを実行していますか?はい、そうであれば。設定ページと失敗ログファイルを共有してください。 BR Re: IMX8M PLUS LPDDR4 2G compatibility IS43LQ32512A-046BLI (ISSI 2GB LPDDR4X SDRAM) は、LPDDR4/LPDDR4X メモリの JEDEC 標準に準拠している限り、 NXP i.MX 8M Plus プロセッサと一般的に互換性があります。ただし、memcpy SSN armv8_x32 テストが 2000 MHz で失敗する (ただし 1500 MHz では成功する) という問題は珍しくなく、根本的な非互換性の問題ではなく、構成、ボード設計、またはキャリブレーションの課題から生じている可能性があります。 互換性確認 i.MX 8M Plus は、最大 4266 MT/s (2133MHz クロック) の LPDDR4/LPDDR4X メモリをサポートし、IS43LQ32512A-046BLI は NXP の仕様に準拠した最大 2133MHz (4266 MT/s データ レート) で動作します。 NXP のコミュニティ フォーラムでは、同様の ISSI LPDDR4X 部品 (例: ご使用のモデルのオートモーティブ バリアントである IS46LQ32512A-046BLA2) が、JEDEC 仕様に準拠している限り、i.MX 8M Plus と互換性があることが確認されています。ユーザーは、適切に構成されていれば問題なく実装できました。 2000MHzでのテスト失敗の潜在的な理由 NXP および組み込みフォーラムでの同様のレポートに基づきます。 タイミング/構成の不一致: i.MX 8M Plus DDR コントローラでは、RAM の SPD/データシートからの正確なタイミング パラメータ (CAS レイテンシ、tRCD、tRP など) が必要です。2000MHz では、キャリブレーションによって ISSI 部品の仕様が完全に最適化されない可能性があります (たとえば、高速では CL=32、RL=14)。1500MHz に下げるとストレスが軽減されて合格しますが、これは最適ではないチューニングを示します。 ボードデザインの問題: トレース長の不一致、インピーダンス エラー、不十分な電力デカップリングなどの信号整合性の問題により、高速動作時に障害が発生する可能性があります。オシロスコープを使用して、DQ/DQS ライン上の反射やノイズを確認します。 キャリブレーションの制限: i.MX 8M Plus は、キャリブレーションに NXP の DDR ツールを使用します。スクリプトまたは設定が Micron/Samsung 参照 (EVK で一般的) に基づいている場合、ISSI の特性と一致しない可能性があります。ISSI 固有のパラメータを使用してキャリブレーションを再実行します。 電力/温度: 2000MHz では、電流消費量が多くなると電圧低下や過熱が発生し、memcpy テスト (連続読み取り/書き込みに負荷をかける) に失敗する可能性があります。 この RAM を実装した人はいますか? はい、文書化された実装があります。 NXPコミュニティ スレッドでは、ユーザーが同様の ISSI LPDDR4X (IS46LQ シリーズなど) をインダストリアル アプリケーション用のカスタム i.MX 8M Plus ボードに統合し、微調整後に最大 2133MHz までの安定した動作を実現しています。 組み込み Linux/BSP 開発者は、Yocto ベースのビルドで ISSI パーツを使用した成功を報告していますが、512M x 32 構成 (16Gbit 密度) を処理するためにカスタム DDR init スクリプトを使用することが多いようです。 問題を解決するための推奨事項 データシートの配置を確認する: ISSI データシート (IS43/46LQ32512A シリーズ) をダウンロードし、タイミング パラメータを NXP の i.MX 8M Plus RM (リファレンス マニュアル、セクション 13.5 DDR コントローラ) と比較します。 RAM の主な仕様: 最大クロック 2133MHz、LVSTL インターフェース、1G x 16 構成 (デュアル チャネル合計 x32)。 キャリブレーションの再実行: ISSI 固有のストレス テストでは、NXP のDDR テスト ツールまたはSCFW DDR 構成ツールを使用します。 1600MHz から開始し、アイ ダイアグラムを監視しながら徐々に 2000MHz まで上げます。 U-Boot/Linux を使用している場合は、正しいタイミングでデバイス ツリー (.dtb) を更新します (例: mx8mp-ddrc-devfreq.dtsi)。 取締役会レベルのチェック: VDDQ = 1.1Vであることを確認する。VDD2 = 0.6V、クリーンなデカップリング(コンデンサをピンの近くに配置) 信号整合性シミュレータ (HyperLynx など) を使用してトレースを確認します。 熱スロットリングを排除するために、より低い温度またはより優れた冷却でテストします。 それでも失敗する場合は: コミュニティまたはチケット システムを通じて NXP サポートに連絡し、キャリブレーション ログとボードの回路図を提供してください。 比較のために、Micron MT53E512M32D2NP (NXP EVK デフォルト) などの検証済み RAM に切り替えることを検討してください。 全体的に RAMは互換性がありますが、2000MHz の障害はセットアップの問題である可能性があります。さらに詳しい情報(キャリブレーション ログやボードの回路図スニペットなど)を共有していただければ、さらにトラブルシューティングをお手伝いできます。 メッセージング アプリ経由で +8526583 (7594) に連絡し、彼から EOL ドキュメントを入手してから推奨事項を作成することをお勧めします。彼はあなたを助けることができます Re: IMX8M PLUS LPDDR4 2G compatibility ご対応ありがとうございます。 添付ファイルで設定.xlsを送信しますそしてテストログ。 Re: IMX8M PLUS LPDDR4 2G compatibility 使用済みのボードでは、3GB (MT53E768M32D2ZW-046 WTC) と 4GB (MT53E1G32D2FW-046 AAT:B) を正常に動作させています。 2000MHz の Micron LPDDR4。 Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@pengyong_zhangさん 構成ツール V 13.1 でも同じ結果になります。IS43LQ32512A-046BLIの設定が間違っているのでしょうか?正しい設定ファイル(*.dsファイル)をご提供いただけますか?当社のハードウェア設計は、LPDDR4 インターフェースに関する評価ボードの 1:1 コピーです。 敬具 トビアス Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye 以下のリンクを使用して DDR 構成ツールをダウンロードし、2GB DRAM を構成して DDR テストを実行してください。 https://www.nxp.com/design/design-center/development-boards-and-designs/i-mx-evaluation-and-development-boards/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX BR Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye 以下の設定を使用して DDR テストを実行してください。 BR Re: IMX8M PLUS LPDDR4 2G compatibility 設定例をありがとうございます。すでにこの RAM で試しましたが、まだエラーが発生します。 Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye 不思議ですね。DDR Config Tool v25.12 の失敗ログを共有してください BR Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye DDR Config Tool を使用してストレス テストを実行しましたか?ログ ファイルから見ると、これは Config Tool の出力ではないようです。また、最新のツール バージョン v25.12 を使用してください。 BR Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@pengyong_zhang ストレステストには、Mscale DDR Tool 3.31 を使用します。他の設定ツールでやってみます Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@pengyong_zhangさん ストレステストのログはこちらです。4GB ISSI IS43LQ32K01S2A-046BLI でも同じ問題が発生します。 Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@pengyong_zhangさん 構成ツールでテストを実行すると、合格しました。SO、これは MSCALER ツールのツール問題のようです。多大なるサポートをいただき誠にありがとうございます!
View full article
首次成功设计 KW47(汽车级)或 MCX W72(物联网 / 工业级)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 发布)    最小物料清单(附件)>> KW45 - MCX W71 - KW47 - MCX W72 Minimum BoM Presentation Customers July25.pdf   DC-DC 管理指南 (AN13831):KW45/K32W148 - 电源管理硬件 (nxp.com)(KW45 的内容适用于 KW47,待 KW47/MCXW72 版本发布)   Design-In 检查清单:请参阅本文底部附件   射频匹配:S 参数(附件)(待 KW47/MCXW72 发布)   PCB 上纽扣电池应用处理方法:AN14664_Coincell_Hardware_recommendation_Rev1.0.pdf 说明:“由于射频性能取决于 PCB 布局和制造工艺,基于 NXP 建议制作的 PCB 原型必须进行微调,以确保最终产品平台达到预期的射频合格标准。” 在 EVK 上,为连接 M10 模块进行射频测试,建议使用 μFL 转 SMA 电缆: CSH-SGFB-200-UFFR TE Connectivity / Linx Technologies | Mouser France 在 KW47-LOC 或 MCXW72-LOC 上,需安装特定的 SMA 连接器以实现连接:TE Connectivity Ltd CONSMA021.062-G 从 KW45 到 KW47 的硬件移植: KW47 与 KW45 引脚到引脚兼容。然而,从硬件的角度来看,某些组件的值需要进行调整,例如 RF 匹配组件的值。 根据当前的硅验证,预计KW4x周围的其他组件不会发生变化。 另请注意,为实现 KW47 的新功能,部分引脚采用了新的复用配置。例如,KW47 提供了第二个 Flex CAN。详见附件。 射频   射频报告:KW45 和 K32W148 的蓝牙低功耗射频系统评估报告,以及 K32W148 的 802.15.4 应用评估报告……(待 KW47/MCXW72 发布,可应要求提供)   射频共存:Kinetis 无线系列产品的蓝牙低功耗与 Wi-Fi 共存应用(nxp.com)(待 KW47/MCXW72 发布)   距离性能:参考附件(待 KW47/MCXW72 发布)   天线: 用于NXP EVK板的2.4 GHz通信设计和应用的紧凑型平面天线 用于信道探测应用的天线   BLE 连接性测试二进制文件:可按需在 SDK 中获取   回波损耗 (S11) 测量:如何测量射频匹配的回波损耗 (S11)(射频报告 AN13728 的一部分)   负载牵引:待 KW47/MCXW72 发布 用于 RF 试验的 SW 工具:   IoT 工具箱(移动应用)   连接性产品的连接测试工具(IoT 工具箱的一部分)   DTM:如何在 Kinetis 系列产品上使用 HCI_bb……- NXP 社区 https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/BLE-HCI-Application-to-set-transmitter-... 晶体  文章:KW45/K32W1 的 32MHz 和 32kHz 振荡裕量 - NXP 社区(待 KW47/MCXW72 发布) 推荐的水晶已附上 低功耗 蓝牙 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 已通过蓝牙 6.0 信道探测认证!
View full article
MCXN647との接続問題(Ee(42)エラー) こんにちは、 FRDM-MCXN947に問題があります。プロジェクトをデバッグまたはフラッシュしようとすると、次のエラーが発生します。 関係があるかどうかはわかりませんが、while(1) ループのこの行を変更して頻度を上げたときに発生しました: SDK_DelayAtLeastUs( 30000 , SystemCoreClock); -> SDK_DelayAtLeastUs( 10000 , SystemCoreClock); 問題が発生する前にアップデートしていなかったのですが、その後LinkFlashをアップデートしても何も解決しませんでした。 すでに SPT 消去を試しましたが、機能しませんでした。(多分、やり方が間違っていたのでしょう。) SPT では、ISP モードを有効にした後、「イメージの構築」および「イメージの書き込み」操作を実行できましたが、消去はまだ機能しません。 ご協力をよろしくお願いいたします。 追伸: 英語と専門用語が下手で申し訳ありません。私は工学部でこのプロジェクトを始めたばかりです。 ブートROM|ブート|フラッシュ クロック|タイマー MCX N USB Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D SPT ツール内のフラッシュ プログラマーを使用して、blinky SDK デモを消去およびプログラムし、正常に動作するかどうかを確認してください。詳細は添付の動画をご参照ください。 これらの手順がうまく機能しても、オンボード デバッガーでデバッグできない場合は、外部デバッガーを使用してテストしてください。 まだ問題がある場合は、お気軽にお問い合わせください。 よろしくお願いします。 BR アリス Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Alice_Yang 、 ご返信ありがとうございます。 ビデオの指示に従いましたが、その方法で LED が点滅しました。 ただし、MCUXpresso IDE からデバッガーに戻ると、同じエラーが発生します。 問題がオンボード デバッガーから発生している場合、特に私が使用しているボードは学校で貸与されたものなので、PEMicro や SEGGER J-Link (それが言及されている場合) などの外部デバッガーを購入するつもりはありません。 解決策が見つからない場合は、私のプロジェクトでも機能するフラッシュ プログラマーを引き続き使用し、教授に外部デバッガーがあるかどうかを尋ねます。 よろしくお願いいたします。 ピーター Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D あなたのボード上のデバッガーが実際に壊れているかどうかはわかりません。次の手順に従って、デバッガー ファームウェアを更新してください: https://docs.nxp.com/bundle/UM12018/page/topics/Updating_MCU_Link_firmware.html 更新後、ボードの電源を入れ直し、MCUXpresso IDE で新しいワークスペースを作成し、新しい SDK デモをインポートして、再度デバッグを試みます。 ビデオを撮って私と共有していただけると嬉しいです。確認をお手伝いします。 よろしくお願いします。     BR アリス Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Alice_Yang ご返信よろしくお願いします。 提案されたとおりに LinkServer を更新しましたが、問題が発生した後にすでに更新されていたと思います。とにかくもう一度アップデートを試み、ボードの電源を入れ直し、新しいワークスペースを作成し、デモ プロジェクトをインポートしましたが、デバッグしようとすると同じ Ee(42) エラーが発生します。 プロセスを示す短いビデオを録画したので添付します。 ご協力ありがとうございました。良い新年をお迎えください。 よろしくお願いします、 ピーター Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D ビデオをありがとう。 .launch ファイル (下の画像) を削除して、ボードを再度消去してください。 デバッグを開始するには、下の図に示すデバッグ ボタンを使用します。 それでも動作しない場合は、ボードを交換することをお勧めします。 ちなみに、私は正月休みを頂き、1月5日に復帰します。もしご不明な点がございましたら、当日にお問い合わせください。 ご理解のほどよろしくお願いいたします。新年あけましておめでとうございます。 BR アリス
View full article
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
View full article
使用 PN7160 — P2P 与 Type-4 标签模式在两个 Linux 板之间共享 Wi-Fi DPP 凭证? 您好,NXP团队, 我正在使用 PN7160 NFC控制器和恩智浦 Linux NFC 堆栈在两个 Linux 板(联发科 Genio 510 EVK)之间进行 Wi-Fi 接入 : https://github.com/NXPNFCLinux/linux_libnfc-nci 系统设置 Board-1 (M1) 使用 hostapd 充当 Wi-Fi 接入点 (AP) PN7160 支持 NFC Board-2 (M2) 使用 wpa_supplicant 充当 Wi-Fi 站 (STA) PN7160 支持 NFC 目前是 手动配置凭证时,Wi-Fi 接入点/STA 连接正常工作 nfcDemoApp 中的 NFC 读/写和轮询示例正常工作 目标 我想使用以 NFC 作为引导通道的 Wi-Fi DPP(Easy Connect)自动配置从 M1(AP)到 M2(STA)的 Wi-Fi 凭证 ,这 与 Wi-Fi 联盟的入门操作类似。 问题 1.NFC 模式选择 对于两块板之间的 Wi-Fi DPP 凭证配置: 是否应使用NFC 点对点(P2P / LLCP / SNEP)模式? 还是应该在接入点侧使用Type-4 Tag 仿真(NDEF、application/vnd.wfa.wsc 或 DPP URI),由 STA 充当 NFC 读卡器? 从Wi-Fi联盟的参考资料来看,NFC似乎主要用作引导渠道,但我想确认一下在使用 PN7160 时推荐的NFC模式。 2.使用恩智浦 demoapp 使用现有的linux_libnfc-nci demoapp 示例: 能否将Type-4 标签仿真示例扩展到: 在 M1(接入点)上模拟 Wi-Fi 配置标签 向 M2(STA)提供 Wi-Fi 接入数据 对于 Wi-Fi DPP 上载,推荐还是不推荐使用NFC P2P + SNEP? 3.Wi-Fi DPP 集成 一旦在 M2 上接收到 NFC 数据: 是建议的流量: NFC → DPP 引导信息(URI/公钥) 然后使用 wpa_supplicant通过 Wi-Fi 进行 DPP 验证? 恩智浦是否有集成方面的参考示例或指南: PN7160 NFC 栈 Linux wpa_supplicant DPP 命令 可实现AP-STA 自动连接? 摘要 我正在寻求以下方面的指导: Wi-Fi DPP 的正确 NFC 模式(P2P 与 Type-4 标签 如何重复使用或扩展现有的恩智浦演示应用程序 推荐架构,用于在两个 Linux 板之间实现安全、符合 Wi-Fi 联盟标准的接入 如有任何参考、样本流程或最佳实践,将不胜感激。 感谢您的支持。 致以最崇高的敬意, Niranjan Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 感谢您对我们的产品感兴趣。 建议的解决方案是使用我们的 "连接 "标签之一。在您描述的设置中,我们建议在 M1 (AP) 主板上连接 NTAG 5 Link 板。主机在 Tag 中生成要读取的正确的 NDEF 消息,并为安全访问配置所需的凭据。   如果您想使用 SNEP,则需要在双方都安装 NFC 阅读器。这将增加成本和 P2P 的实施,需要额外的指令交换。这还需要额外的符合规范的软件开发工作。   请记住,在接入点端使用 NTAG 5,您需要根据 NDEF 消息和 Type 5 标签内存配置规范的 NFC 论坛规范构建 NDEF 消息。有必要同时购买两种规格。 在 M2 板上,您将需要像 PN7160 这样的 NFC 读取器,它可以读取 NDEF 并与 AP 建立连接。 希望这些信息对您有所帮助。 Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 你好@Fabian_R 谢谢你的澄清。 我知道使用SNEP 需要在双方都安装 NFC 读卡器,这会增加 BOM 成本,而且由于P2P 命令交换和根据 NFC 规范进行额外的软件开发,也会增加复杂性。 不过,对于我们的使用案例,我们希望进一步评估这种方法。 能否请您就基于 SNEP 的解决方案澄清以下几点: 建筑指导 两个 Linux 板都应该在启用 P2P 读取器/启动器模式下运行吗? 一个板应该充当 SNEP 服务器,另一个板充当 SNEP 客户端,还是两者都需要支持这两个角色? 软件堆栈要求 能否使用linux_libnfc-nci 协议栈和演示应用程序(如 SNEP 或 P2P 示例)来实现? 基于 SNEP 的凭据交换是否需要对 NFC 栈进行任何特定的配置更改? 数据交换流程 是否建议通过 SNEP 有效载荷交换Wi-Fi DPP 引导信息(QR URI / 公钥)? 通过 NFC 接收数据后,应用程序是否应该直接在注册者端触发信号 wpa_supplicant DPP 命令? 合规方面的考虑 在这种情况下,基于 SNEP 的 P2P 通信是否需要遵守NFC 论坛的强制合规要求? 有关使用 SNEP 在两个 Linux 主板之间传输 Wi-Fi DPP 凭证的详细分步流程或参考实施指南将对我们评估可行性非常有帮助。 感谢您的支持。 Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 您好,先生, 我们提供的应用程序接口支持客户端和服务器角色。有关使用和实施的详细信息,请查阅规范(SNEP 和 LLCP)。P2P 的相关函数和实用程序可在 NfcLibrary/NdefLibrary/src/P2P_NDEF.c 中找到。 关于数据交换流问题,可以在Wifi联盟规格文档中找到此信息:连接移交技术规范和Wifi Easy Connect规范(设备配置协议)。 请记住,我们无法提供这些文件的具体内容。请务必购买。
View full article
How to download documents on chip-related resources Example: S32K3xx_interrupt_map.xlsx Re: 如何下载芯片的相关资源的文档 Hi@PQF Download the datasheet and instruction manual from the official website. You can find these documents you are looking for in the attachment to the instruction manual. https://www.nxp.com/products/S32K3
View full article
Kinetis K40DN512 の USB CDC デュアル VCOM および MSC こんにちは、 私は、K40DN512 ボード上で FatFS アプリケーションを使用してデュアル VCOM および MSC を作成しようと取り組んでいます。 デバイス スタック上のデュアル VCOM と SD ディスクを使用した FatFS の動作は確認できましたが、MSC の実装は困難でした。デバイス構成ツールを使用して一部の USB コンポーネントを構成する人がいるのを見たことがありますが、私のプロセッサはこれをサポートしていません。 適切なエンドポイントやその他の記述子情報を構成するために、何らかの形式のウィザードを使用して USB デバイス記述子を構成するより簡単な方法はありますか? そうでない場合、これまでに USB デバイス スタック経由でデュアル CDC VCOM および MSC w/ FatFS システムを動作させることに成功した人はいますか?もしSOなら、どのような構成を使用しましたか? ヒントやガイダンスがあれば歓迎します。 Kinetis KシリーズMCU USB Re: USB CDC Dual VCOM and MSC on Kinetis K40DN512 こんにちは@tbryant 要件に最も近い SDK デモ(例: usb_device_composite_cdc_msc_disk )を選択することをお勧めします。まず、ボード上で正常に動作することを確認し、次を参照して 2 番目の CDC インターフェースを追加します。 Re: 複合USBデュアルCDCデバイス - NXPコミュニティ ありがとう。 BR アリス
View full article
TWR-KV58 硬故障 早上好 我在 TWR 板上犯了一个明显的错误。我以前在同样的状态下使用这个板,它能正常工作,它在那里停了一会儿,现在我直接从硬故障开始。 我使用的是连接了 JTAG 电缆的 Multilink。我以前是这样做的。我直接从硬故障开始。 这是屏幕截图 跳线 J19 和 J20 打开,以便使用 JTAG。应该够了。 请提出建议。我只能假设它坏了 谢谢大家 Pietro Re: TWR-KV58 Hard Fault 早安 请支持我。我已经订购了一个新的作为备用解决方案,但我需要帮助才能继续。 谢谢 Re: TWR-KV58 Hard Fault 你好@pietrodicastri、 谢谢您的帖子。 为帮助确定这是否是软件问题,请检查在运行 SDK 中包含的演示程序(如 "Hello World "演示程序)时是否仍会出现 HardFault? SDK 链接:选择板 | MCUXpresso SDK 生成器 如需了解更多详情,请参阅https://www.keil.com/appnotes/files/apnt209.pdf。 BR 西莱斯特 Re: TWR-KV58 Hard Fault 你好 板现在正在工作...我很感激你的支持。 我现在要发表一些其他内容。 谢谢 Pietro
View full article
启用密码保护后无法移除 NTAG213 上的写保护 (AUTH0/ACCESS) 您好,NXP团队, 我正在使用 PN7160 NFC 控制器和恩智浦 Linux NF CDemoApp 处理 NTAG213 标签。 我的成功经验 我修改了nfcDemoApp (main.c),通过配置在 NTAG213 上启用只写密码保护: 工务司 包装 AUTH0 访问(prot = 0) 写保护正常工作: 移动 NFC 应用程序无法再写入 只有从我的应用程序中发送 PWD_AUTH 后,才能进行写入操作 将 AUTH0 RESET 为 0xFF 清除接入 重写配置页面 我还使用恩智浦 NFC TagInfo / NFC Tools应用程序在另一个 NTAG213 上启用了写保护,结果也达到了预期效果。 我面临的问题 现在,我在这两种情况下都 无法移除写保护: 使用我自己的代码 (nfcDemoApp) 使用恩智浦 NFC 工具/TagWriter移动应用程序 即使使用正确的密码 (PWD_AUTH) 进行了身份验证,但尝试:仍失败。 我的理解是 根据 NTAG213 数据表,我明白了: PWD_AUTH 应允许在 RF 会话期间写入受保护的页面 身份验证后,应该可以修改 AUTH0 和 ACCESS NTAG213 没有用于密码保护的永久锁定位(与锁字节不同) 但在实际操作中,我无法将标签恢复到未受保护的状态。 问题 启用 NTAG213 基于密码的写保护后,官方是否支持移除或禁用该保护? 成功设置 PWD_AUTH 后,AUTH0 和 ACCESS 页面是否可以写入,还是一旦设置后就永久受保护? 是否有将 NTAG213 恢复到可写(未受保护)状态的推荐顺序? 恩智浦 NFC Tools / TagWriter 是否能移除 NTAG213 上的密码保护,还是需要自定义原始命令处理? 身份验证后是否需要完全RESET(RF 会话RESET/电源重启)才能修改配置页面? 如果恩智浦团队能提供任何指导或说明,将非常有帮助。 感谢您的支持。 致以最诚挚的问候, Niranjan Re: Unable to remove write protection on NTAG213 after enabling password protection (AUTH0/ACCESS) 我使用 RFIDDiscover。它可以更改配置页面中的设置,取消保护。
View full article
S32 DS 3.3 许可证过期 你好,我的 S32 Design Studio 3.3 已过期: S32 Design Studio v.3.3 版 订购编号 S32DS-3-3_146477567 订购单编号 许可证总数: 101 激活代码 AF1B-F377-2238-53BB 您能帮我解决这个问题吗?非常感谢! 亚历山大-穆勒 Re: S32 DS 3.3 License expired 你好、 您的 S32DS 许可证已延期。请使用旧代码重新激活 S32DS。
View full article
ヘルプが必要です: RT1189 上の FlexSPI2 QSPI フラッシュからの起動 カスタム ハードウェア上でユーザー アプリケーションを起動しようとしています。このカスタム ハードウェアには、ポート A のプライマリ ピン グループを使用してコネクテッドされた FlexSPI2 QSPI フラッシュのみがあります。フラッシュ デバイスは、Micron MT25QU256ABA です。RT1189 (RT1189CVM8C) に搭載されたブート ROM がメモリを正しく構成せず、ブートに失敗します。ただし、NXP セキュア プロビジョニング ツールは、これに正常に読み取りと書き込みを行うことがCANできます。 フラッシュ構成ブロック (FCB) は、セキュア プロビジョニング ツールを使用して作成されました。 XIP ブート ヘッダーはイメージのコンパイル自体で無効化されました。代わりに、セキュア プロビジョニング ツールは、上記のスクリーンショットに示されている設定とまったく同じ設定を使用して、簡略化された UI から生成された FCB を使用するように構成されました。上記のスクリーンショットには表示されていませんが、「テスト接続」は成功しています。 さらに、セキュア プロビジョニング ツール (以下、「SPT」と呼びます) から外部メモリを構成するように要求された場合、FlexSPI2 メモリはプロセッサとツールによって正常に読み取ることができます。これを以下に図示します。 ユーザーがフラッシュ プログラマ ツールを開き、ポップアップで「はい」をクリックするか、「外部メモリの構成」ボタンをクリックすると、SPT は上記のフラッシュ構成ブロック設定を使用して、FlexSPI2 フラッシュ メモリをプログラミング用に初期化します。 以下のスクリーンショットは、完全なアプリケーション イメージ (FCB はオフセット 0x400、ユーザー アプリケーションはオフセット 0x1000) をフラッシュした後にキャプチャされたものです。 これにより、フラッシュ構成ブロックが正しいと考えられます。 RT1180 で次のヒューズ ビットが焼損しました。その他のヒューズビットはすべてデフォルトです。 BOOT_CFG0[6] (BT_FUSE_SEL) -> 1b、ヒューズからのブートを有効にする BOOT_CFG2[7] (FLEXSPI_INSTANCE) -> 1b、FlexSPI2を選択する(デフォルトはFlexSPI1) BOOT_MODE ピンを 000b (内部ヒューズからのブート) に設定すると、RT1189 は何もアクティビティを行いません。再度通信できるようにするには、「無限ループ」モードで起動し、その後シリアル ダウンローダー モードに戻す必要がありました。 BOOT_MODE ピンを 100b (「FlexSPI からのブート」) に設定すると、RT1189 は「スタック」したままになりますが、JLink デバッグ プローブによって停止できます。 BOOT_MODE 100b を使用して FlexSPI から起動しようとした後に停止すると、FlexSPI2 のメモリ領域を調べるとすべてゼロが表示されます。 ここで興味深いのは、「すべてゼロ」が RT1189 の FlexSPI2 メモリ領域のデフォルト状態と一致しないことです。次のスクリーンショットは、外部メモリを構成せずにシリアル ダウンローダー モードで起動した後にキャプチャされたものです。 最後にもう 1 つ: ユーザー アプリケーションの MCUXpresso サンプルのリンカー スクリプトが、FlexSPI2 から起動するように変更されました。 注意: スクリーンショットのキャプションには「0x14000000」と表示されていますが、コードで実際に使用されている値は「0x04000000」です。これはタイプミスです これは SPT に反映されています。 これらすべてを念頭に置いて、私の現在の理解は次のとおりです。 FCB は正しくなければなりません。そうでないと、SPT は FlexSPI2 バンク A に接続された外部フラッシュと対話できません。 ROM 自体は、起動時に、SPT とは異なる何らかの方法でこの外部メモリを初期化しようとしているはずです。RT1189 ブート ROM のソース コードがなければ、リバース エンジニアリングを行わずにデバッグを続けることはできませんが、NXP のお客様として、リバース エンジニアリングを行うつもりはありません。 私の質問: この動作を引き起こす設定の何が問題なのでしょうか? フラッシュの初期化に失敗する理由を理解するためにブート ROM をデバッグする方法はありますか? ありがとう!! Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 数週間の努力の末、XIP ではなく ITCM (0xFFE00000) にリンクすることでプロセッサを起動することができました。ただし、このThreadはまだ関連性があります - FlexSPI2 上の XIP が正しく動作しないのはなぜですか? Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 @Sam_Gao 、 ご返信ありがとうございます。 元の投稿で述べたように: ブートインスタンスの選択は、コメントとAN14589で指定されているものとまったく同じです。BOOT_CFG2[7]はFlexSPI2を選択するために書き込まれます。 アプリケーション コードは、指定どおりに FlexSPI2 メモリ マップ領域 (0x04000000) にリンクされます (m_start_flash が 0x04000000 に変更されます)。返信ではこれを「0x40000000」としていますが、これは上記のアプリケーション ノートや RT1189 のリファレンス マニュアルに記載されているとおり正しくありません。 FCB は予想されるオフセットに存在します。フラッシュ チップを動作中の MIMXRT1180EVK のものと交換してみましたが、それでもまだ動作しません。 ロジック アナライザを使用して、フラッシュ構成ブロックがブート ROM によって読み取られている可能性が高いことを判断できました。クロック速度はすぐに 30 MHz から 125 MHz に変化し、読み取りデータは SPI データ ラインを介して送信されます。 ブート ROM またはブート シーケンスをさらにデバッグできるメカニズムはありますか? Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 こんにちは、 RT1189 のようなデバイス上の FlexSPI2 QSPI フラッシュからの起動に失敗する原因は、通常、いくつかの一般的な構成領域にあるようです。ここでは、潜在的な問題の詳細と、ブート ROM プロセスをデバッグして根本原因を特定する方法について説明します。 AN14589 を参照: https://www.nxp.com/docs/en/application-note/AN14589.pdf 1. ブートインスタンスの選択を確認する: ブートROMに、デフォルトのFlexSPI1ではなくFlexSPI2を使用するように明示的に指示する必要があります。これは BOOT_CFG2[7] によって制御されます。 ヒューズまたはピン。BOOT_CFG2 BOOT_CFG2[7] が 1 に設定されている FlexSPI2 を選択する ブートインスタンスとして 。プライマリブートモードピン( BOOT_MODE[2:0] )シリアルNORフラッシュからブートするには、正しく設定する必要があります(例: '100') 2. アプリケーション リンカー アドレス: FlexSPI2 のブート可能なイメージをビルディングする場合、アプリケーション コードを FlexSPI2 メモリ マップから実行するようにリンクする必要があります。FlexSPI2 の開始アドレスは 0x40000000 です。プロジェクトのリンカー ファイルを変更して、フラッシュ開始アドレス ( m_flash_start ) を 0x40000000 に設定する必要があります (参照: AN14589 の 7 ページ)。 3. FCB: ブートROMには、外部QSPIデバイスを正しく初期化するために、フラッシュメモリの先頭(通常はオフセット 0x400 )に有効な512バイトの構成ブロックが必要です。このブロックが欠落しているか、破損しているか、使用している特定のフラッシュ チップと一致していない場合、ブート ROM はフラッシュとの通信に失敗します。詳細については、 https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#preparing-source-image-for-rt118x-devicesをご覧ください。 Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 問題はないようです。 ブート ROM とブート シーケンスの詳細については、 https://www.nxp.com/docs/en/application-note/AN14589.pdfを参照してください。 デバイスが「スタック」している場合は、リセットしないでください。JLink/デバッガーを使用して実行中のカーネルに直接アタッチし、次のレジスタの状態を確認します。例: プログラムカウンタ(PC): PC が 0x2xxxxxxx (ROM 領域) にある場合、ROM はまだ実行中であるか、無限ループに陥っています (たとえば、ペリフェラルの応答を待機している)。 PC が 0x002xxxxx (OCRAM) または別の RAM 領域を指している場合、ROM はジャンプを試みたものの、アプリケーションがクラッシュした可能性があります。 PC が 0x4000xxxx (FlexSPI2 AMBA 領域) を指していて、すべてゼロまたはバス エラーとして読み取られた場合、ジャンプは発生しましたが、XIP アクセスは失敗しました。
View full article
EB Tresos 29.0 问题 我使用离线激活功能激活了 EBtresos 29.0,但遇到了以下问题:处理响应时出现错误(50019、41200、10246)。如何解决这个问题?在尝试了很多次都没有成功后,我别无选择,只能使用离线激活。 Re: EB Tresos 29.0 Issue 你好 我不确定您采取了哪些步骤,但以下是 EB 提供的激活指南: 请参阅本章: 5.1.3.离线激活单个用户或评估许可证 如果您能提供更多细节,也许我能帮上忙。 顺祝商祺! Peter Re: EB Tresos 29.0 Issue @petervlna 您好,我使用的激活代码是B25C-AEBB-4319-BAB1(有效期至 06/30/2026),来自恩智浦官方网站。生成脱机激活文件 activation.xml 时显示了一个 失败。多次尝试后,activation.xml 文件仍显示为 失败.如何解决这个问题?非常感谢您的帮助。该软件是 EB Client License Administrator 1.5.1。 我还尝试用我的电脑生成激活请求文件,但用我同事的恩智浦账户生成的 activation.xml 文件仍显示为失败。 你是中国人吗?我们以后能用中文交流吗? Re: EB Tresos 29.0 Issue 你好 我刚刚测试了有效期到年底的新代码,激活成功。 您将在一天左右的时间内在恩智浦 SW 账户中找到它。 顺祝商祺! Peter Re: EB Tresos 29.0 Issue 你好 你是中国人吗?我们以后能用中文交流吗? 否。 点击这里查看。免费许可证库似乎已经枯竭: https://community.nxp.com/t5/S32K/EB-activation-failed/td-p/2252930 顺祝商祺! Peter Re: EB Tresos 29.0 Issue 你好 以下是 flexera 管理员给我的官方答复: 更新正在进行中。它已转交给有权更新它的人。 如果要进行严肃的开发,我建议从 EB 购买永久许可证。否则,您就必须在这种情况下等待评估许可证的更新。 顺祝商祺! Peter Re: EB Tresos 29.0 Issue 您好,感谢您的回复。不过,截至目前,恩智浦官方网站上的许可证尚未更新。新许可证何时启用? Re: EB Tresos 29.0 Issue 你好 这太奇怪了。我已再次通知管理员更新代码。 我会推动它。 我还注意到有新的 EB tresos v 30。 顺祝商祺! Peter Re: EB Tresos 29.0 Issue 您好,我已经等了三天,但激活码今天仍未更新。激活码何时提供? Re: EB Tresos 29.0 Issue 您好, 代码现已在恩智浦 SW 账户中更新。 顺祝商祺! Peter
View full article
Zephyr:Booting DSP from MCU in Zephyr Hello, I am currently working on a project using the RT595 with the Zephyr RTOS, and I want to know how to start the DSP from the MCU. According to section 4.7 of the official documentation (IMXRT595-EVK-UG), by setting DSP_IMAGE_COPY_TO_RAM=1in the IDE, it is possible to achieve "program once, and the ARM core automatically wakes up the DSP". Now that the project has fully transitioned to the Zephyr build system, I would like to know the specific steps to launch the DSP application and how it should be configured. Thank you for your help. Evaluation Board Re: Zephyr:Booting DSP from MCU in Zephyr @jingqi  General Steps: To launch the DSP from the MCU in a Zephyr project, you should first build the DSP binary with Xtensa Xplorer, then integrate that binary into your Zephyr build via CMake, and finally call the  BOARD_DSP_Init()  function from your application to handle the startup sequence. You need to complete the functionality using the official documentation (MCUXpresso + EVK) and you need to have the ability to develop Zephry before you can complete the migration. Refernce: 1. Build the DSP Firmware: Getting Started with Xplorer for EVK- MIMXRT595 Typically, you will get two output files, such as dsp_text_release.bin and dsp_data_release.bin. These are the firmware images that the Cortex-M33 core will load into the DSP's RAM 2. Integrate the DSP Binary into the Zephyr Build:  the Zephyr build system requires you to explicitly include these binary files in your Cortex-M33 application. You can do this by modifying the CMakeLists.txt file for your Zephyr application. You may need to use Zephyr's build system features (like zephyr_file_copy or by defining them as a binary blob) to place the files in a known location in the final firmware image. 3. The MCUXpresso SDK for the i.MX RT595 provides a driver (  fsl_dsp.c  /  .h  ) to manage the DSP lifecycle. Zephyr for NXP devices includes this SDK, so you can call these functions directly from your Zephyr application code. Details can be found from '3.3 DSP Core Initialization' of Getting Started with Xplorer for EVK- MIMXRT595
View full article
操作指南:在 S32G 电路板支持包中配置静态 IP 1. 简介 当使用由电路板支持包(如 BSP43)生成的 Yocto 根文件系统时,默认的网络配置通常设置为使用 DHCP。因此,S32G-VNP-RDB3 板上连接到每个端口的 DHCP 服务器可能会为不同的以太网端口分配不同的 IP 地址。 这种默认行为对大多数客户来说很方便,因为它不需要额外的网络配置。端口在连接以太网电缆后立即可用,这与已包含DHCP服务器的典型开发环境非常吻合。 然而,有些客户可能没有可用的 DHCP 服务器,或者他们需要特定的网络配置,而不是使用 DHCP 自动分配的设置。例如,客户可能希望将某个以太网端口专门用于某个子网,以便通过 SSH 进行访问。在无法使用 UART 调试控制台的情况下,预先设置好静态 IP,便可在开发板启动后立即进行远程访问。 本文档介绍了一种方法,可为某个特定以太网端口配置静态 IP 地址,同时让其余端口继续使用默认的 DHCP 配置。客户还可以进一步定制配置以满足其具体的网络需求。 S32G
View full article
IMX415 相机移植 imx8mplus 您好, 我正在将索尼 IMX415 摄像头传感器移植到恩智浦 i.MX8M Plus (IMX8MP) 平台上。 在移植过程中,一些参考提到了通过 ISP 调整工具生成 XML 文件。 我的问题是 我真的需要生成 XML 文件才能让 IMX415 在 IMX8M Plus 上运行吗? 这些 XML 文件是否必须用于基本的传感器调试(通过 V4L2 / ISI 进行流式传输)? IMX8MPLUS Re: IMX415 camera porting imx8mplus 这是一个好问题。 仍然需要 xml 配置/校准文件,请参见此处: -AN13712: 800 万像素 ISP OS08A20 传感器 -AN13713: 800 万像素 ISP 新相机移植 我不知道为什么恩智浦最近删除了这个文件。 Re: IMX415 camera porting imx8mplus 我认为您需要 xml 文件。您可以先使用分辨率相同的设备,然后再进行微调。 另见: https://community.nxp.com/t5/i-MX-Processors/IMX8M-Plus-ISP/m-p/2220156/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1JN0JJTUJFRVZXMTA2fDIyMjAxNTZ8U1VCU0NSSVBUSU9OU3xoSw#M242307 Re: IMX415 camera porting imx8mplus 你好, ,关于 XML 文件,我还有一个疑问。 目前,我有用于相机传感器 OS08A20 的 XML 文件,能否将相同的 XML 文件用于 imx415 传感器? Re: IMX415 camera porting imx8mplus 感谢您的回复,但您说从最近的 isp-imx 项目中删除 xml 文件是什么意思?在移植新相机传感器时是否不再需要它们? Re: IMX415 camera porting imx8mplus 他们删除了近期 isp-imx 项目中的 xml 文件,但您可以从早期项目中获取这些文件: ,将 xx 替换为以前的版本: isp-imx-4.2.2.xx.0.bin 例如检查: https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/isp-imx-4.2.2.18.0.bin https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/isp-imx-4.2.2.20.0.bin 等... Re: IMX415 camera porting imx8mplus 如何获取 XML 文件?如果你有任何想法,请告诉我。对于 OS08A20,我看到一个文件名为"Sensor0_Entry_os08a20.cfg" 的文件,文件中包含: name="os08a20" drv ="os08a20.drv" mode= 0 [mode.0] xml ="OS08a20_8M_10_1080p_linear.xml" dwe ="dewarp_config/sensor_dwe_bypass_1080P_config.json" [模式.1] xml ="OS08a20_8M_10_1080p_hdr.xml" dwe ="dewarp_config/sensor_dwe_bypass_1080P_config.json" [模式.2] xml ="OS08a20_8M_10_4k_linear.xml" dwe ="dewarp_config/sensor_dwe_bypass_4K_config.json" [模式.3] xml ="OS08a20_8M_10_4k_hdr.xml" dwe ="dewarp_config/sensor_dwe_bypass_4K_config.json 我的疑问是,这些 json 文件有必要吗? Re: IMX415 camera porting imx8mplus PS:还需要相应的 json 文件,因为无论如何都需要配置广角鱼眼畸变校正模块,即使你将其设置为绕过也是如此。
View full article
Problem of the CAN sampling point test value being too small for S32K3 Hi, NXP When developing with S32K311, an external crystal oscillator of 16 MHz is selected. When configuring CANFD, the CAN clock source uses the AIPS_PLAT_CLK at 60 MHz. 80% sampling point is configured for the data field, and TDC is enabled. However, the actual measured sampling point in CANOE can only reach 72%. This issue also occurs in tests on other models such as the S32K312 and S32K342. The following is one of our configurations where we set the sampling points and test data. We configured the sampling point to be 76%, but the actual test result was 67%. Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong Could you please share your project, i will take time to test it. Re: Problem of the CAN sampling point test value being too small for S32K3 Hi, @Senlent  We have modified multiple configurations. Under the condition that S32K3 is configured to 80%, the best result tested by CANoe is 72% Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong For CAN FD data phase the latest possible sample point must be set in CANoe. Then the VH6501 sends frames and lengthens the individual bits by one tick after each interval. This seems to be a configuration issue with your VH6501. You can try modifying the parameters here to 70%, 76.667%, and 80% and then testing again. Re: Problem of the CAN sampling point test value being too small for S32K3 Hi,@Senlent  We consulted several experienced engineers. They described that there are also problems with the small sampling point test in S32K1 and K3, and this problem may not be strongly related to the MCU.However, the test results vary when different testing instruments are used. When using CANoe for testing, the test results are all on the low side. They suggest that the sampling point configured for S32K3 can be appropriately increased under the actual test requirement of 80%. You can use any NXP demo to conduct a test, and this phenomenon should be reproducible. Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong This should still be a testing issue, not caused by the MCU. However, I will spend some time doing some simple tests. I will probably use an oscilloscope to test directly, which should be the most accurate measurement method. Re: Problem of the CAN sampling point test value being too small for S32K3 Hi,@Senlent  If you have more convincing results, please share them with us as well. We used some other instruments for testing, and the obtained sampling points are relatively close to what we expected in the settings. However, for customers, CANoe has a very high level of industry recognition. Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong It's possible that the client's tests are flawed; please trust your own testing. I will take some time to conduct a few tests, but this isn't a priority for me and may take a few days to get back to you. Re: Problem of the CAN sampling point test value being too small for S32K3 ok Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong I'm sorry, I cannot perform this test. I do not have suitable interference equipment to conduct it, and the test results in the FLEXCAN report already prove that the test passed. I can send you the relevant proof privately. Re: Problem of the CAN sampling point test value being too small for S32K3 Thank you very much.
View full article
FRDM-K64F mcuexpresso 在多个目标之间切换 当您通过拔下旧目标/插入新目标来切换目标后进行调试时,它会要求您通过序列号确认目标。我想保留三个目标并能够在它们之间切换,无需拔掉电源即可进入此确认屏幕,但看不到执行此操作的选项。由于 USB 连接器断断续续,我损坏了一台价值 700 美元的逻辑分析仪,并且不想对我的任何评估套件也发生同样的问题! 回复:FRDM-K64F mcuexpresso 在多个目标之间切换 埃里希,您是一位学者,也是一位绅士!非常感谢。幸运的是,昨天由于磁盘错误,我刚刚升级到 24.12,并且运行良好! 干杯 奈杰尔 回复:FRDM-K64F mcuexpresso 在多个目标之间切换 非常感谢您辛勤地帮助我。现在您的评论“进入闪光屏幕”引起了我的兴趣。你的意思是有一个图标可以故意输入吗?如果是的话我还没有找到。重新插入模块后,我唯一可以进入它的时间是当我进入“调试(项目名称)链接服务器调试”时。或者也许存在一个项目设置,当我在重建后尝试调试时,我还没有找到它来输入?我已经浏览了所有设置和图标来寻找这样的快捷方式! 回复:FRDM-K64F mcuexpresso 在多个目标之间切换 感谢您对我的问题的考虑,但我已经了解该屏幕并使用过它。问题是,如果不拔掉模块,我就无法进入该屏幕。如果它找不到最后编程的模块,它就会出现,否则它将始终重新刷新最后一个模块而不会弹出该对话框!我需要的是一种无需拔掉刚刚闪现的目标即可更改目标的方法。 回复:FRDM-K64F mcuexpresso 在多个目标之间切换 谢谢您的回复,但我想您误解了我的困境。我有三个相同的 MCU,当我打开刚刚收到的三个 MCU 时,总共有六个。我正在构建一个将使用所有这六个的网络项目。它们都是相同的 FRDM-K64F,并且都将运行相同的代码。当我更新代码时,我需要立即将其加载到每个模块中,以便它们保持同步。拥有六个不同的项目并且每次代码更改时都更新所有六个项目将非常耗时。现在我正在拔下每个模块并插入下一个模块来刷新它们。这会导致 USB 插座因磨损而出现一些间歇性故障。我想一直保留它们并选择从 MCUexpresso 中刷新和运行哪一个。 谢谢! 奈杰尔
View full article
Kinetis (../45/47/43;MCX W71/72/70) および MCX W23 電源プロファイルツール (ローカライズ機能を含む) このページは、Kinetis (KW35/KW38/KW45/KW47) および MCX Wx (MCX W71/72 および MCX W23) 電力プロファイル ツール専用です。 これにより、あなたのアプリケーション(オートモーティブ、IIoT、トラッカー/タグ、連続血糖モニタリング[CGM])の消費電力を推定し、ソリューションのバッテリー寿命を評価するのに役立ちます。 このページには、単独製品またはフルシステムアプリケーション向けの専用パワープロファイルツールを提供する5つのマーケットセグメントが含まれています:   1. オートモーティブ Kinetis(KW3x/4x)オートモーティブ用パワープロファイルツール - NXPコミュニティ KW35/36製品用のBluetooth LEをスタンドアロンで使用。 Bluetooth LEはKW37/38/39製品用のスタンドアロン対応です。 KW45/KW47製品用のBluetooth LEをスタンドアロンで使用。 スマートフォブアプリケーション(BLE/KW45;UWBレンジャー4位;SE;モーション・センサ) スマートフォブアプリケーション(BLE/KW47;UWBレンジャー5;SE;モーション・センサ) 2.IIoT Kinetis MCX Wxx(MCX W71/72 および MCX W23)IIoT用パワープロファイルツール - NXPコミュニティ Bluetooth LEは単体でMCX W71/MCX W72製品用です。 MCX W23製品のBluetooth LEをスタンドアロンで提供します。 スタンドアロン (IIoT) の MCX W71 および W72 マター製品用の 802.15.4 Matter ICD SIT & LIT および ZED。 Aliro Doorlockアプリケーション    3. オートモーティブおよび工業技術向けローカリゼーションアプリケーション(CCC CS) Kinetis MCX Wxx(KW47およびMCX W72)Bluetoothローカライゼーション用パワープロファイルツール - NXPコミュニティ 4. 持続血糖モニタリング [CGM][MCX W23] MCX W23 CGM用パワープロファイルツール - NXPコミュニティ 5. 新しいツールが登場します: Zephyr・ズボス Zephyr BLE KW45/MCX W71 または KW47/MCX W72 を使用して PCB を構築し、無線の性能と無線認証 (CE/FCC/IC) に関する情報をすべて得るには、次の重要なリンクを参照してください。 KW45(カーアクセサリ)を使ってPCBを構築する最良の方法 - NXPコミュニティ 電力および低電力アプリケーションノートについては、製品ページをご覧ください。便宜上、いくつかの直接リンクを次に示します。 MCXW71 - 電源管理ハードウェア KW45/K32W148 - 電源管理ハードウェア 異なる体験:One コネクティビティ Power Profilingツール コネクティビティの電力プロファイリングツールをすべて一つにまとめています。 Kinetis(KW3x/4x、MCX W7xおよびMCX W23)One コネクティビティ Power Profile Tool - NXPコミュニティ 注:このツールはかなり遅いですが、Kinetis製品を比較するのに非常に興味深いです。 製品: K32W0 製品: K32W1 製品: KW 34|35|36 製品: KW 37|38|39 製品: KW41Z |31Z | 21Z 製品: QN9080|SIP 製品: QN9090|30 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) こんにちは、エベレット。 パスワードは、変更や競合他社のベンチマークの詳細が多すぎることを避けるために設定されています。 ご不便をおかけして申し訳ございませんが、それはCANません。 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) こんにちは、christophe_menardさん。 @christophe_menardシート保護のパスワードを教えていただけますか。よろしくお願いします。 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは 、 OneConnectivityPowerProfilingtool_SDK_26_03.zip を使用したいのですが、トロイの木馬が検出されました。 このツールの使い方。 サポートありがとうございます Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは、 @pierre_demeyer この件を確認するため、社内のIT部門に問い合わせチケットを発行しました。 近いうちにまたご連絡します。 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは、 @pierre_demeyer IT認証の結果、CrowstrikeやDefenderのソフトウェアを使ってトロイの木馬ウイルスは検出されませんでした。
View full article
用于 NFC 驾驶舱的 SPI 适配器 你好 我找到了你的 PN5180 和其他阅读器的探索板,它上面似乎有一个 USB <-> SPI 适配器,所以 NfcCockpit 可以用它与 PN5180 之类的东西通信。 我的问题是:有没有基于 Arduino 的固件可以实现同样的功能? 我有很多基于 esp32 或 rp2040 的板,但你提供的固件似乎不支持它们... Re: SPI Adapter for the NFC Cockpit 你好,谢谢你的建议! 最后,我设计了自己的解决方案: https://github.com/dakhnod/NFCCockpitSPIAdapter 再次感谢! Re: SPI Adapter for the NFC Cockpit 你好@dakhnod 1.我的问题是:有没有基于 Arduino 的固件可以实现同样的功能? 没有,没有基于 Arduino 的固件。 2。我有很多基于 esp32 或 rp2040 的板,但你提供的固件似乎不支持它们... 你可以将 NFC COCKPIT VCOM 移植到 tesp32 或 rp2040,源代码可以从 NFC Cockpit 下载|恩智浦半导体
View full article
TEA2017 27-30V 550W 设计,PFC Mosfet 在 DCM/QR/CCM 模式下迅速发热。 你好我正在处理一个客户项目,该项目采用 TEA2017 PFC 和 LLC 设计,电压为 27-30V,功率为 550W。 最初,我们使用固定频率 55khz 的 PFC,mosfets 的温度比平时高,但仍可通过散热片控制,但现在我们正试图提高 PFC 的效率。因此采用 DCM/QR/CCM 模式。遗憾的是,在我们的设计中,在 DCM/QR/CCM 模式下,mosfets 的温度会迅速升高到失效温度。 我们尝试过但没有成功的方法: 1:使用晶体管作为栅极驱动器来驱动 Pfc 栅极 2:确认我们的开关是在振荡周期之后和 DrainPFC 下降时进行的。 3.禁用 LLC 并将负载直接连接到 Vboost,以测试/调整 PFC(结果:茶水没有切换 PFC,Vboost 保持在 327V(SNSBoost 为 2V)) 我们的设计或 TEA 设置没有太大变化,因为我们正在尝试测试 DCM/QR/CCM。任何正确方向的帮助/线索都将非常有用。 我已经公布了原理图的 PFC 部分,我们使用的是 CONFIG_D。 Re: TEA2017 27-30V 550W Design, PFC Mosfet rapidly getting hot with DCM/QR/CCM Mode. HI 1:您应该确认哪个元器件变热了电感器或其他元器件,然后提供散热解决方案。 2: 您也可以按照所附的 excel 计算表配置电路,然后更新原理图。
View full article