Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
i.MX8 Nano DDR Tool Test Results – Acceptance Confirmation Hi, Below are our DDR validation results from the DDR Tool. Could you please review them and let us know whether the results are acceptable? If not, could you please suggest possible ways to improve the results? Re: i.MX8 Nano DDR Tool Test Results – Acceptance Confirmation Hello, The report looks in general good, the functional tests pass and the subsequent Data and CA vTSA tests pass. for more information:   DDR Tool — Config Tools for i.MX Applications Processors 26.06 documentation     to improve the result:   Select ODT/driver values toward the middle of the passing region, rather than using values adjacent to failed combinations. If margins remain a concern, review DDR PCB signal integrity, particularly impedance, routing, termination, and signal integrity around DQ/DQS and CA. Re-run validation across the intended operating conditions and hardware population rather than relying on a single board/result. Keep in mind the DDR Tool is an evaluation/debug/optimization aid and that its results cannot substitute for traditional validation and compliance testing required to establish JEDEC compliance.
查看全文
[I.MX95] Failed to enable LVDS1 + MIPI-DSI Hello NXP technical supports, My i.mx95 env is lf-6.18.y. I am using pixel_interleaver ch0 for DSI and ch1 for LVDS port 1. Now I got a problem that MIPI-DSI doesn't work when enabling LVDS1 and MIPI-DSI at the same time in the device-tree. I used modetest to see the information, but I see nothing about DSI. But if I disabled pixel_interleaver channel@1, DSI was to be OK. How do I configure the device-tree for enabling DSI + single port LVDS? Can show me an example? Attachments are my dtso files, but I changed the file name, because your webpage doesn't allow uploading files which's name with .dtso. Thanks in advance. Re: [I.MX95] Failed to enable LVDS1 + MIPI-DSI Hello,  Please try to use the following patch: https://community.nxp.com/t5/Multi-Source-Translation-Content/2046000-en-US/ta-p/2411639  It enables MIPI-DSI plus two LVDS outputs, so enabling only LVDS1 is a valid subset.
查看全文
Status and Reliability Inquiry for SPC5200CVR400B Dear NXP Support Team, We are using the SPC5200CVR400B IC in our product. Could you please confirm: • Whether SPC5200CVR400B is active, obsolete, or discontinued. • If this device is still being manufactured. Whether any known issues related to data/software corruption have been reported for this device. • Recommended methods to prevent or diagnose such corruption. • A suitable replacement/alternate part if the device is obsolete or approaching end-of-life. Your guidance on the possible root causes and corrective actions would be highly appreciated. Thank you for your support. Best Regards, Abhijeet Solanki Re: Status and Reliability Inquiry for SPC5200CVR400B Hello, Based on the MPC5200 feature set (Linux MPU, MMU, Ethernet, USB, CAN, industrial temperature, modest performance): Best overall ARM replacement                    LS1021A Industrial networking / future-proof           LS1028A Lowest cost modern ARM migration           i.MX93 Best regards, Peter Re: Status and Reliability Inquiry for SPC5200CVR400B Part no. of alternate IC please. Re: Status and Reliability Inquiry for SPC5200CVR400B Hello, Whether SPC5200CVR400B is active, obsolete, or discontinued. This product is end of life. If this device is still being manufactured. Whether any known issues related to data/software corruption have been reported for this device. No Recommended methods to prevent or diagnose such corruption. I am not aware of any published silicon erratum specifically identifying a generic data or software corruption mechanism for the SPC5200CVR400B. To investigate potential corruption issues you can: Perform RAM and Flash integrity checks using checksums or CRCs. A suitable replacement/alternate part if the device is obsolete or approaching end-of-life. i.MX application processors - Recommended path for new designs requiring continued product support. Best regards, Peter
查看全文
i.MX93 SAI1 TX FIFO エラー プラットフォーム ボード:i.MX93 EVK;/sys/devices/soc0/soc_id=i.MX93, /sys/devices/soc0/revision=1.1。パッケージのマーキング/マスクはまだ記録されていません。 Linux: 6.12.20-lts-next-gdfaf2136deb2,先取り、A55。 テキサス州0x443b0000のSAI1(44000000.dma-controller-CH21経由)。 SAI1シリアルルート:VIDEO_PLLから40 MHz;40 MHz BCLK、1.25 MHzのフレームレート。 SAI3/WM8962はLinux所有で、以下の複製では使用されていません。 LMX2571 I2S FSKシンク:アクティブスロットには符号付き16ビットコード、その他のスロットにはゼロ。 定数コード+8500は期待される+17 kHzのRFオフセットを生成します。 最小限のLinux再現(M33リモートプロックオフライン) カスタムDTBはSAI1をALSA再生デバイスとして公開します。SAI1 PCMカード0。 静的ALSA PCM:hw:0,0、S16_LE、2チャネル、1,250,000フレーム/秒; 期間は2,400フレーム、バッファは19,200フレームです。ガウスフィルターやその他のフィルターは使用していません。 リアルタイム波形生成。TX FIFO深度32ワード、TX DMAバースト8ワード、 FIFO透かし24。静的データ: スロット 0=8500、スロット 1=0。 コマンド: python3 /root/cp7g_static_playback.py --device hw:0,0 --seconds 600 最新の結果:7億5000万フレームを599.958秒で書き込み、ALSA xruns=0。 SAI1 FEF IRQ診断:1エピソード、2.685ms間に9回のIRQエントリ。 単調稼働時間約675.892537秒で初めて観測されました。 再生が停止する7.16秒前でした。ストリーム終了時のドレインイベントではありません。 最初の割り込み処理(FEFハードウェアアサーション後のタイミング) TCSR=0x90150c01; 連続読み取り時間=41 ns; 最初の読み取り前にハンドラが動作 TCSR読み取り=209 ns; 最初のTCSR regmap読み取り=120,607 ns (戻り値0)。 FEF W1C regmap 書き込み=241,007 ns (戻り値 0)、詳細スナップショット前。 ACK後TFR0=0x00020001、読み取り時間=242,799 ns。 ACK後のeDMA CH21の最初の生レジスタ読み出し=241,423 ns; 合計CH21 スナップショット時間=487,722 ns。CH_CSR=0x80000005、CH_ES=0x00000000、 CH_INT=0x00000000、CH_SBR=0x00208003、CH_PRI=0x00000000。 TFR0とCH21の値は、確認後ではなく、 初期FEFアサーション。長い読み書きでは、 初期のFIFOエラーを引き起こしました。CH_ES=0はチャネルエラーがなかったことを示すだけです サンプリングされるとラッチ(吸付)ができた。FEFはALSA xruns=0にもかかわらずハードウェアイベントです。 独立簡易ファームウェア再現 Linux起動時にALSAキャプチャがアイドル状態の場合、M33コードは同じSAI1 TXを駆動しました 単一のセルフリンクeDMA CH21 TCDを使用し、一定の+8500スロット、 メジャーループのコールバックもフォアグラウンドバッファのリフィルもガウスフィルターもありません。 40 MHz BCLK、FIFO 深度 32、ウォーターマーク 24、DMA マイナーループ 16 バイト、 216秒後(Rev R)にSAI1 FEFで停止しました。FEF障害発生後のスナップショットでは、 CH21_ES=0、DMAグローバルES=0の場合、TCDは依然として自己リンク状態でした。同様の故障が発生した 後の優先順位付け試験および内部BCLK試験において。半額料金での試行も失敗に終わった。 したがって、PythonもM33波形計算/再充填も必要ありません。 断続的なSAI1 FEFを再現する。Linuxの再生も M33、オフライン。プローブの負荷と外部ワイヤの長さの変更は除去されませんでした 問題。 追加の観察 burst-4 / watermark-28のLinux実行では、稼働時間にFEFエピソードが1回ほどありました 別ブートでは676.889秒、最新のバースト8フォルトは675.893秒でした。 最新の起動で約670〜682秒のシステムジャーナル検索では、何も見つかりませんでした 記録された活動。同様の稼働時間はあくまで示唆的なものであり、タイマーの存在を証明するものではありません。 NXPへの質問 1.i.MX93 rev 1.1マスクのエラタムや低消費電力/インターコネクトの既知のものはありますか? SAI1およびeDMA CH21レジスタへのアクセスやDMAを遅らせる可能性のある状態 SAI1 TXとそのクロックが有効である間に100〜250 USのサービスができるのでしょうか? 2. ハードウェアの状態、クロックゲーティング、インターコネクト、またはeDMAトレースが可能なもの FEFの前に最初に見落としたSAI1のFIFOサービスリクエストを特定しますか? 3. SAI1 TX FEFは実際のFIFO以外の状態を示しているか? この非同期マスター構成でアンダーラン? 4. SAI1/eDMAのバースト、ウォーターマーク、またはクロックの制約は文書化されていますか? i.MX93上の連続40MHz BCLK / 1.25 MHzステレオフレーム出力の場合? カスタムDTBやLinux fsl_sai.c/hも提供可能です変更と静的再生 スクリプト、M33自己リンクTCDソース、完全なブートクロックツリー、およびスコープ/RFデータ。 オーディオ(PDM |I2S |SAI) Re: i.MX93 SAI1 TX FIFO errors こんにちは、 遅れて申し訳ございません。中国の祝日期間中は通信帯域幅が限られているため、返信が遅れる場合がございますのでご了承ください。ご理解いただきありがとうございます。 1. いいえ、あなたの設計で見られる挙動を説明する訂正表はありません。 2. TCSR[FEF]は、有効化された送信FIFOにアンダーランエラーが発生し、原因がDMA要求の喪失かどうかは特定できないことを意味します。 3. いいえ、単にFIFOアンダーランです。 4. この構成はSAIスイッチング仕様の範囲内です。この挙動の原因となる明らかな問題がないか確認するために、変更点を教えてください。ドライバの改造は当方で検証されていませんのでご注意ください。 よろしくお願いいたします。
查看全文
RCONからブート こんにちは、 現在SAF8444チップを使用しているのですが、RCONに関する詳細について確認する必要があります。リファレンス・マニュアルでは、Parallel RCONから起動できることがわかり、RCON[15:0]はBOOT_CFG1[15:0]と1対1に対応しています。しかし、マニュアルではRCON[7]とRCON[8]に対応するピンしか見つかりません。他のピンの定義が見つかりません。この情報はどこで探せばいいですか? 返信をお願いします。ありがとうございます! Re: Boot from RCON こんにちは、 SAF84xxはまだNPI(新製品導入)段階の試作機です。サポートをいただける場合は、NXPの担当者にご連絡ください。 一般公開されると、一般サポートが質問に答えることができます。 よろしくお願いいたします。 ピーター
查看全文
PREEMPT_RT on Linux QoriQ Hi, we are currently using the NXP QorIQ Linux kernel from the linux-6.12-rt branch, but we would like to move to a newer kernel version, possibly Linux 6.18. I have a few questions regarding the RT kernel support and branch strategy: What exactly is the difference between linux-6.12-rt and lf-6.12.y? Is a separate linux-6.18-rt branch planned, similarly to linux-6.12-rt? If not, is lf-6.18.y intended to be used directly with CONFIG_PREEMPT_RT=y? My understanding is that linux-6.12-rt contains additional PREEMPT_RT-related changes compared to lf-6.12.y. However, starting with Linux 6.12, the core PREEMPT_RT support has been merged into the upstream kernel: https://kernel-internals.org/locking/preempt-rt/ At the same time, I can see that RT-specific development and stable RT patch releases still continue separately upstream. Given this, I would like to understand how this is handled in the newer NXP QorIQ releases. For Linux 6.18, should we simply use the lf-6.18.y branch with CONFIG_PREEMPT_RT=y, with all NXP-specific changes required for PREEMPT_RT already included there? Or is a separate QorIQ RT branch/release still planned, containing additional RT patches on top of lf-6.18.y? If no separate RT branch is planned, are there any additional RT patches that NXP recommends applying on top of lf-6.18.y? Re: PREEMPT_RT on Linux QoriQ Hello, For QorIQ/Layerscape, do not assume that lf-6.18.y plus CONFIG_PREEMPT_RT=y is equivalent to NXP’s supported RT release. NXP’s current Real-Time Edge material shows Linux PREEMPT_RT 6.18 releases based on LF 6.18, while internal development tracks a separate downstream RT patch stack. Use the matching NXP 6.18 RT release, preferably the latest one available for your QorIQ platform. Compare your current linux-6.12-rt tree against the corresponding LF 6.18 base, but do not assume that enabling CONFIG_PREEMPT_RT=y alone includes all NXP-specific RT changes. Also validate: architecture support for ARCH_SUPPORTS_RT ; NXP networking, DPAA/DPAA2, ENETC, DSA, TSN, PTP, and interrupt behavior; latency under representative load; any driver-specific RT patches in the NXP downstream stack. The upstream article’s main qualification is also relevant: PREEMPT_RT became mainline-selectable in 6.12, but support is architecture-dependent and does not imply that every vendor driver has been validated for deterministic behavior Regards Re: PREEMPT_RT on Linux QoriQ Thanks for clarification. Do you know when, more or less can we expect the NXP Linux 6.18 RT support release? Re: PREEMPT_RT on Linux QoriQ So, if you mean the next 6.18-based RT update, the current roadmap points to Real-Time Edge 3.6 in December 2026. Note that the standard i.MX Linux BSP—not RT—already has newer 6.18 releases, including 6.18.37 on September 24, 2026. Regards
查看全文
EB AutoCoreのアクティベーションが失敗しました こんにちは、みんな、 今日、NXPから提供された新しいAutoCoreライセンスのアクティベーションを試みました。ライセンスを有効化しようとすると、ライセンスが古いというエラーメッセージが表示されますが、ウェブサイトには2026年12月30日まで有効と記載されています。 アクティベーションログを添付します。 NodeLockedライセンス7FCB-75DF-0F6E-4E7Aを有効化しています。ライセンス数:1 ステータス: 4、リクエストを作成中 ステータス: 5、リクエストが作成されました ステータス: 6、コンテキストが作成されました ステータス:7、リモートサーバーにコネクテッド ステータス: 8、リクエスト送信済み Status: 9, Polling for response(ステータス9:応答を問い合わせ中) ステータス: 10、応答待ち Status: 9, Polling for response(ステータス9:応答を問い合わせ中) ステータス: 10、応答待ち Status: 9, Polling for response(ステータス9:応答を問い合わせ中) ステータス: 10、応答待ち Status: 9, Polling for response(ステータス9:応答を問い合わせ中) ステータス: 10、応答待ち Status: 9, Polling for response(ステータス9:応答を問い合わせ中) ステータス: 10、応答待ち Status: 9, Polling for response(ステータス9:応答を問い合わせ中) Status: 11, Done(ステータス11:完了) エラー:flxActAppActivationSend(50040,41147,10248) ライセンスはすでに期限切れで、作成できません。 FlexNetオペレーションサーバーへの接続に失敗しました。 Re: EB AutoCore activation fails こんにちは、私も同じ問題を抱えています...
查看全文
EB AutoCore activation fails Hello everyone, Today I tried to activate the new AutoCore licence provided by NXP. When I try to activate it I get a failure message stating the licence is old, but in the web it says it is valid until 12/30/2026. I attach the activation log: Activating NodeLocked License 7FCB-75DF-0F6E-4E7A, Number Of Licenses: 1 Status: 4, Creating request Status: 5, Request created Status: 6, Context created Status: 7, Connected to remote server Status: 8, Request Sent Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 11, Done ERROR: flxActAppActivationSend (50040,41147,10248) License can not be generated, it is already expired. Connection to FlexNet Operations Server failed. Re: EB AutoCore activation fails Hello, I have the same problem...
查看全文
TagInfoのオクトパスカードの現在の値 AndroidのTagInfoアプリを使ってOctopusの公共交通カードをスキャンしているのですが、現在の金額の計算方法にバグがあるのではないかと思います。 調べてみたところ、2017年10月以降、カードの入金金額が35ドルから50ドルに変更されることが関係しているようです。アプリはメモリ上に0x00000357を表示しますが、これは855 - 350 = 505、つまり50.5ドルです。しかし、実際の値は855 - 500 = 355、つまり35.5ドルです。 もしこの情報をアプリ開発者に転送して、将来のアップデートで計算結果を示せるようにしていただけるとありがたいです。ありがとう。 はじめに Re: TagInfo current value for Octopus cards こんにちは、 @chfoo さん、 ご意見ありがとうございます。残念ながら、これはNXPのポートフォリオに含まれていないサードパーティのアプリケーションや製品に関するものであり、当社のサポート範囲外です。 ご迷惑をおかけして申し訳ございません。 BR ハビブ
查看全文
[I.MX95] LVDS1 + MIPI-DSI の有効化に失敗しました こんにちは、NXPの技術サポートの皆さん、 私のi.mx95のエンビューはlf-6.18.yです。 私はDSI用にpixel_interleaver ch0を、LVDSポート1用にch1を使用しています。 デバイスツリーでLVDS1とMIPI-DSIを同時に有効にすると、MIPI-DSIが動作しないという問題が発生しました。modetestを使って情報を確認しましたが、DSIに関する情報は何も表示されませんでした。 しかし、pixel_interleaver channel@1 を無効にすれば、DSI は問題ないはずだった。DSIとシングルポートLVDSを有効にするには、デバイスツリーをどのように構成すればよいですか?CANの例を教えてもらえますか? 添付ファイルは私のdtsoファイルですが、あなたのウェブページでは.dtsoという拡張子のファイルをアップロードできないため、ファイル名を変更しました。 前もって感謝します。 Re: [I.MX95] Failed to enable LVDS1 + MIPI-DSI こんにちは、 以下のパッチをお試しください。 https://community.nxp.com/t5/Multi-Source-Translation-Content/2046000-en-US/ta-p/2411639 MIPI-DSIに加えて2つのLVDS出力を有効にするため、LVDS1のみを有効にするのは有効なサブセットです。
查看全文
TagInfo current value for Octopus cards I am using the TagInfo app on Android to scan an Octopus public transport card and I think there may be a bug in how it calculates the current value. After doing some research, I think it involves the deposit amount changing from $35 to $50 for cards after October 2017. The app shows 0x00000357 in memory, which is 855 - 350 = 505 or $50.5, but the actual value is 855 - 500 = 355 or $35.5. If this info could be forwarded to the app developers so it can show the updated calculation in a future update, it would be appreciated. Thank you. Getting Started Re: TagInfo current value for Octopus cards Hello @chfoo, Thank you for your comments. Unfortunately, this concerns a third-party application and product that are not part of NXP's portfolio, therefore, this is outside the scope of the support we can provide. I apologize for any inconvenience this may cause. BR Habib
查看全文
SPC5200CVR400B 的状态和可靠性查询 尊敬的恩智浦技术支持团队: 我们的产品中使用了SPC5200CVR400B集成电路。 请您确认一下: • SPC5200CVR400B 是处于活跃状态、过时状态还是已停产状态。 • 如果该设备仍在生产,是否有关于该设备数据/软件损坏的已知问题报告? • 预防或诊断此类损坏的推荐方法。 • 如果设备已过时或即将报废,则提供合适的替代/备用零件。 如果您能就可能的根本原因和纠正措施提供指导,我们将不胜感激。 感谢您的支持。 此致, 阿比吉特·索兰基 Re: Status and Reliability Inquiry for SPC5200CVR400B 你好, 基于 MPC5200 的功能集(Linux MPU、MMU、以太网、USB、CAN、工业级温度、中等性能): 最佳整体 ARM 替代品 LS1021A 工业网络/面向未来的LS1028A 成本最低的现代 ARM 迁移方案 i.MX93 顺祝商祺! Peter Re: Status and Reliability Inquiry for SPC5200CVR400B 请提供备用集成电路的零件编号。 Re: Status and Reliability Inquiry for SPC5200CVR400B 你好, SPC5200CVR400B 是处于活跃状态、过时状态还是已停产状态。 该产品已停产。 如果这款设备仍在生产的话。该设备是否已报告任何与数据/软件损坏相关的已知问题? 无 预防或诊断此类损坏的推荐方法。 我不知道有任何已发布的硅勘误表专门指出 SPC5200CVR400B 的通用数据或软件损坏机制。 要调查潜在的腐败问题,您可以: 使用校验和或 CRC 执行 RAM 和闪存完整性检查。 如果设备已过时或即将报废,则可使用合适的替代/备用零件。 i.MX 应用处理器 - 推荐用于需要持续产品支持的新设计。 顺祝商祺! Peter
查看全文
[I.MX95] 启用 LVDS1 + MIPI-DSI 失败 您好,NXP技术支持团队, 我的 i.mx95 环境是 lf-6.18.y。 我使用 pixel_interleaver ch0 处理 DSI,使用 ch1 处理 LVDS 端口 1。 现在我遇到了一个问题,当在设备树中同时启用 LVDS1 和 MIPI-DSI 时,MIPI-DSI 无法工作。我使用 modetest 查看了信息,但没有看到任何关于 DSI 的信息。 但是,如果我禁用 pixel_interleaver channel@1,DSI 就可以正常工作了。如何配置设备树以启用 DSI + 单端口 LVDS?能给我举个例子吗? 附件是我的 dtso 文件,但我更改了文件名,因为您的网页不允许上传文件名以 .dtso 结尾的文件。 提前致谢。 Re: [I.MX95] Failed to enable LVDS1 + MIPI-DSI 你好, 请尝试使用以下补丁: https://community.nxp.com/t5/Multi-Source-Translation-Content/2046000-en-US/ta-p/2411639 它支持 MIPI-DSI 和两个 LVDS 输出,因此仅启用 LVDS1 是一个有效的子集。
查看全文
SPC5200CVR400Bのステータスおよび信頼性に関する照会 親愛なるNXPサポートチームへ、 私たちは製品にSPC5200CVR400B ICを使用しています。 確認いただけますか: • SPC5200CVR400Bが現役、廃止、または廃止されているかどうか。 ・このデバイスがまだ製造中かどうか。このデバイスに関してデータやソフトウェア破損に関する既知の問題が報告されているかどうか。 ・このような腐敗を防止または診断するための推奨方法 ・機器が旧式化している場合、または耐用年数が近づいている場合は、適切な代替部品または交換部品を用意してください。 考えられる根本原因と是正措置についてのご助言をいただければ大変ありがたいです。 ご支援ありがとうございます。 よろしくお願いします、 アビジート・ソランキ Re: Status and Reliability Inquiry for SPC5200CVR400B こんにちは、 MPC5200機能セット(Linux MPU、MMU、イーサネット、USB、CAN、インダストリアル温度、適度な性能)に基づいて以下の通りです: Best overall ARM replacement                    LS1021A インダストリアル networking / future-proof           LS1028A Lowest cost modern ARM migration           i.MX93 よろしくお願いいたします。 ピーター Re: Status and Reliability Inquiry for SPC5200CVR400B 代替ICの部品番号を教えてください。 Re: Status and Reliability Inquiry for SPC5200CVR400B こんにちは、 SPC5200CVR400Bが現在も使用されているか、旧式化されているか、製造中止になっているか。 この製品は寿命切れです。 この機器がまだ製造されている場合。このデバイスに関してデータやソフトウェア破損に関する既知の問題が報告されているかどうか。 なし このような破損を防止または診断するための推奨方法。 私は、SPC5200CVR400Bに関する公開されたシリコンエラタムで、一般的なデータまたはソフトウェア破損メカニズムを具体的に特定しているものについては存じません。 *(Note: The target text preserves the original polite nuance while accurately inserting "ソフトウェア" as requested by the glossary term, adjusting the surrounding phrasing minimally for grammatical coherence.)* Reintegrated target: 私は、このSPC5200CVR400Bに関する一般的なデータまたはソフトウェア破損メカニズムを特定したシリコンエラタムは知りません。 潜在的な汚職問題を調査するには、以下の方法があります: チェックサムまたはCRCを使用して、RAMとフラッシュメモリの整合性チェックを実行します。 機器が旧式化している場合、または耐用年数が近づいている場合に適した代替部品。 i.MXアプリケーション・プロセッサ - 継続的な製品サポートを必要とする新しいデザインへの推奨パス。 よろしくお願いいたします。 ピーター
查看全文
Getting Started with UWB on the NXP Trimension® SR250 - Part 2: SR250UWBSHIELD + FRDM-RW612 Setup Guide (Japanese Blog) 1. Introduction In the first installment, we introduced the SR250 as a device that integrates UWB ranging and UWB radar onto a single chip, and that it was released for the mass market in March 2026. From this point on, we'll finally get the board working. Let's go through the process together, from obtaining the evaluation board to verifying its operation. 1st Basics of UWB and an overview of the SR250 Part 2 (This article) Setting up the SR250 evaluation board (SR250UWBSHIELD) 3rd Let's try UWB ranging. 4th Try out UWB radar. There are two main ways to try out the SR250: the build-free PnP (Plug-and-Play) route and the Zephyr SDK route for full-fledged development. The necessary preparations differ depending on which route you choose, so it's best to decide beforehand. Those who want to do both are also very welcome! While it can run on systems other than Windows, this guide will use the command prompt on a Windows PC. root For people like this Development environment A. PnP First, I want to try it out easily! Python + PySerial only B. Zephyr SDK I want to develop this seriously and combine it with BLE. Git・CMake・Python・Zephyr SDK 2. Hardware Preparation (Common to A and B) Required hardware For UWB distance measurement, a device on the other end is required. If you have two sets, you can measure distance between two SR250 UWB SHIELD boards. If you have a smartphone equipped with UWB, you can measure distance to the smartphone with just one set. SR250UWBSHIELD : Arduino-compatible shield board equipped with SR250. FRDM-RW612 : Host MCU board ( Wi-Fi 6 / Bluetooth Low Energy 5.4 / 802.15.4 equipped) Two USB Type-C cables One cable is included with the FRDM-RW612, so please prepare another one. You will need a cable that supports data communication, not just a charging-only cable. The connector that connects to the PC can be either Type-A or Type-C. Regarding USB connection The SR250UWBSHIELD + FRDM-RW612 requires two USB-C cables to operate. Let's review the purpose of each cable. connector Purpose remarks J10 (MCU-Link) Power supply, programming, and debugging. This connection is required. Without it, the power will not turn on. J8 (HS-USB) Serial communication (Virtual COM Port) When checking the COM port, use the port number on the J8 side. Two COM ports will appear in Windows Device Manager, but the one used for serial communication is the COM port on the J8 (HS-USB) device. It will be displayed as "USB Serial Device (COMx)". Rework: Critical tasks that need to be checked first. The SR250-ARD shield and FRDM-RW612 communicate via SPI, but SPI does not function correctly with the default Arduino header wiring. Please address this using one of the following two methods. Method 1: Rework by soldering (recommended) If you have a soldering iron, I recommend reworking the SPI lines. Once done, you won't need any cables, resulting in a cleaner setup. For detailed rework procedures, please refer to the Start Guide: Start Guide for the Trimension SR250 Development Board Method 2: Alternative connection using jumper wires (for those who want to try it easily) If you want to try it without soldering, connect the Arduino header pins of the FRDM-RW612 with two female-to-female jumper wires as shown below. If you'd like to test the functionality first, please use this method. 3A. PnP Route: Easily try it with just Python The PnP application requires no build; you can directly control the SR250 from your PC using the USB serial communication and SPI communication protocol converter firmware (PnP firmware) for the FRDM-RW612, available on GitHub. You can verify its operation simply by running a Python UCI script from your PC. When preparing, you will encounter two different firmwares. The first one to be written is the protocol conversion firmware that operates within the RW612. After that, you will update the SR250's firmware. The writing methods for each are different (RW612 via ISP mode, SR250 via PnP firmware), so please pay attention to the procedure.   Obtain the necessary files from GitHub. You can download the ZIP file from the "Code" dropdown menu in the upper right corner. GitHub: SR250 UWB Plug-and-Play Application Required software Python 3.x PySerial: pip install pyserial procedure Step 1: Write the firmware for RW612 PnP Connect two USB cables (J10 and J8). To start the RW612 in ISP mode (In-System Programming), which is a firmware writing-only mode: Press and hold SW3 (ISP), then press and release SW1 (Reset) → Release SW3. To write the firmware to the RW612 using ISP over USB, double-click the program_FRDM-RW612.bat file located in the FRDM-RW612_PnP folder to run the batch file: FRDM-RW612_PnP/program_FRDM-RW612.bat Most errors are caused by the device not starting in ISP mode. If you have difficulty entering ISP mode using switch 2, try connecting the USB to J10 while holding down SW3. Once the batch file processing is complete, unplug the USB cable, replug it, and restart the board. Step 2: SR250 FW Update To update the SR250's firmware, double-click Update_SR250_FW.bat located in the SR250_FW folder to run the batch file: SR250_FW/Update_SR250_FW.bat If successful, unplug the USB cable, replug it, and restart the board. Step 3: Operation Check Check the COM port number for communication on the J8 side in Device Manager (e.g., COM10). Start the Python script located in the Simple_demos folder, using the COM port number you just confirmed as an argument, and verify that communication is successful. python demo_ranging.py COM10 The PnP route setup is now complete! 3B. Zephyr SDK Route: For full-scale development This route uses a Zephyr OS-based SDK for building and debugging. It supports integration with BLE and the development of custom applications. There are two methods: using VS Code + MCUXpresso, and using the west command line. Either method is fine. Here, we will introduce the method using the west command in a Windows environment. Let's start by creating a folder as close to the root of the C drive as possible. For instructions on using VS Code with MCUXpresso, please refer to the Getting Started guide or the MCUXpresso for VS Code documentation . Please also refer to the important points regarding using VS Code with MCUXpresso, which are listed at the end of this document. Required software Git : Latest version CMake : 3.21.1 or later Zephyr SDK : 0.17.x There are dependencies between the Zephyr version and the Zephyr SDK. This procedure uses Zephyr SDK 0.17.x Please install it. Different SDK versions may cause build errors. Python : 3.8 or later Make sure you have Ninja and West installed. pip3 install west ninja Serial terminal: TeraTerm, PuTTY, or any other serial terminal of your choice. Environment setup procedure Step 1: Clone the repository git clone https://github.com/nxp-uwb/sr250-uwbiot-zephyr.git Step 2: west initialization cd sr250-uwbiot-zephyr west init -l --mf west.yml uwbiot-top Step 3: Obtain Dependencies west update west update This process will take some time to complete. If it stops midway, please restart it. Proceeding to the next step before completion will cause a build error. Step 4: Install Python dependency packages pip install -r zephyr\scripts\requirements.txt Step 5: Setting environment variables Set the path to the Zephyr SDK in your environment variables. zephyr\zephyr-env.cmd Build and write Since an update is required first, we will build a demo for the firmware update. west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_sr2xx_fw_update\zephyr I will write to the file once the build is successful. west build We will check the logs via serial communication. By default, the code is executed only after communication is established. Connect two USB cables (J10 and J8). Check the COM port number on the side connected to J8 (see Step 3: Operation Check for PnP Root). Launch your terminal software and configure the port as follows: Set the baud rate to 3,000,000 bps . Many terminal programs, such as TeraTerm and PuTTY, do not display 3,000,000 as a baud rate option. Even if it's not in the options, you can enter it manually . Type "3000000" into the text box. If the log message " Success!" appears at the end, as shown below, then it was successful. Similarly, build and flash the calibration demo. west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_device_calibration\zephyr west flash The Zephyr SDK root setup is now complete! Points to note Windows path length limit (MAX_PATH) Windows has a default path length limit of 260 characters. Zephyr repositories have a deep directory structure, which can cause this limitation to be exceeded. We strongly recommend saving your project in a location close to the root of the C drive (e.g., C:\uwb\ ). Placing it in a deeper directory structure like C:\Users\username\Documents\Projects\... will cause the path generated by Zephyr's build system to exceed the limit and result in an error. This issue is more pronounced with VS Code + MCUXpresso. If it's difficult to place it close to the root of the C drive, please consider the following workarounds. How to do it: We recommend using WSL2 (Windows Subsystem for Linux). Alternatively, enable LongPathsEnabled in the Windows registry. Notes on importing projects in VS Code + MCUXpresso When importing a project, you need to set the App type to "Repository application" . This is not highlighted in the Getting Started guide, but it is a point where build errors are likely to occur if you get it wrong. Please be sure to check this. Cases where a pristine build is required If you change build options or the error persists, try a pristine build: west build --pristine -b frdm_rw612 sr250-uwbiot-zephyr/samples/demo_uwb_controller FW version error demo_sr2xx_fw_update Running other demos before executing this will result in a firmware version error. Always perform the firmware update first. Next episode preview Once the environment is set up, we'll finally run the demo. Next time, we'll explain how to run the UWB ranging demo using two different routes: the PnP route and the Zephyr SDK route. Stay tuned! Reference links Trimension SR250 Development Board Start Guide SR250 UWB Plug-and-Play Application (GitHub) sr250-uwbiot-zephyr (GitHub) FRDM-RW612 Product Page Trimension SR250 Evaluation Board MCUXpresso for VS Code ========================= We are currently unable to respond to comments left in the "Comment" section of this post. We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) In the first installment, we introduced the features of the SR250 (integration of UWB ranging and UWB radar on a single chip). In the second installment, we will set up an environment to actually run the SR250 using the evaluation board SR250UWBSHIELD + FRDM-RW612. We will explain two routes: the build-free PnP (Plug-and-Play) route and the Zephyr SDK route for full-fledged development. (Estimated work time: 10 minutes) Japanese Blog
查看全文
NXP Trimension® SR250 UWB 入门指南 - 第 2 部分:SR250UWBSHIELD + FRDM-RW612 设置指南(日语博客) 1. 引言 在第一期中,我们介绍了 SR250,这是一款将 UWB 测距和 UWB 雷达集成到单个芯片上的设备,并于 2026 年 3 月面向大众市场发布。 从现在开始,我们将最终让电路板正常工作。让我们一起完成整个过程,从获取评估板到验证其运行情况。 第一 UWB基础知识及SR250概述 第二部分(本文) 设置 SR250 评估板 (SR250UWBSHIELD) 第三 我们来试试超宽带测距。 第四 试试超宽带雷达。 体验 SR250 主要有两种方式:无需编译的即插即用 (PnP) 方式和使用 Zephyr SDK 进行全面开发的方式。根据您选择的方式,所需的准备工作有所不同,因此最好提前决定。我们也非常欢迎想要两种方式都尝试的用户! 虽然它可以在 Windows 以外的系统上运行,但本指南将使用 Windows PC 上的命令提示符。 根 对于像这样的人来说 开发环境 A. PnP 首先,我想先尝试一下! 仅限 Python + PySerial B. Zephyr SDK 我想认真开发这项技术,并将其与蓝牙低功耗技术结合起来。 Git、CMake、Python、Zephyr SDK 2. 硬件准备(A 和 B 通用) 所需硬件 对于UWB距离测量,另一端需要一个设备。如果您有两套设备,则可以测量两个SR250 UWB SHIELD板之间的距离。如果您有一部配备UWB功能的智能手机,则只需一套设备即可测量到该智能手机的距离。 SR250UWBSHIELD :配备 SR250 的 Arduino 兼容扩展板。 FRDM-RW612 :主机MCU板(支持Wi-Fi 6/蓝牙低功耗5.4/802.15.4 ) 两条 USB Type-C 数据线 FRDM-RW612 附带一根电缆,请另备一根。 你需要一根支持数据通信的线缆,而不仅仅是一根只能充电的线缆。 与电脑连接的接口可以是A型接口或C型接口。 关于USB连接 SR250UWBSHIELD + FRDM-RW612 需要两根 USB-C 数据线才能工作。我们来看看每根数据线的作用。 连接器 目的 备注 J10(MCU-Link) 电源供应、编程和调试。 这个连接是必需的。没有它,电源将无法开启。 J8(HS-USB) 串行通信(虚拟 COM 端口) 检查 COM 端口时,请使用 J8 端的端口号。 Windows 设备管理器中会出现两个 COM 端口,但用于串行通信的是 J8 (HS-USB) 设备上的 COM 端口。它会显示为“USB 串行设备 (COMx)”。 返工:需要首先检查的关键任务。 SR250-ARD扩展板和FRDM-RW612通过SPI接口通信,但使用默认的Arduino排针接线无法正常工作。请使用以下两种方法之一解决此问题。 方法一:焊接返工(推荐) 如果你有电烙铁,我建议你重新焊接SPI线路。焊接完成后,你就不需要任何线缆了,这样布线会更简洁。 有关详细的返工步骤,请参阅入门指南: 《Trimension SR250 开发板入门指南》 方法二:使用跳线连接(适合想要轻松尝试的人) 如果您想尝试不焊接,请按如下方式将 FRDM-RW612 的 Arduino 排针用两根母对母跳线连接起来。 如果您想先测试一下功能,请使用此方法。 3A. PnP 方案:只需使用 Python 即可轻松尝试 此即插即用 (PnP) 应用无需编译;您可以使用适用于 FRDM-RW612 的 USB 串口通信和 SPI 通信协议转换器固件(即 PnP 固件),直接从 PC 控制 SR250。该固件可在 GitHub 上获取。您只需在 PC 上运行 Python UCI 脚本即可验证其运行情况。 准备过程中,您会遇到两种不同的固件。首先要写入的是RW612内部运行的协议转换固件。之后,您需要更新SR250的固件。两者的写入方法不同(RW612通过ISP模式写入,SR250通过PnP固件写入),请务必仔细阅读操作步骤。   从 GitHub 获取所需文件。您可以从右上角的“代码”下拉菜单下载 ZIP 文件。 GitHub: SR250 UWB 即插即用应用程序 所需软件 Python 3.x PySerial: pip install pyserial 程序 步骤 1:写入 RW612 PnP 的固件 连接两根 USB 线缆(J10 和 J8)。 要启动 RW612 的 ISP 模式(系统内编程),即固件写入模式:按住 SW3(ISP),然后按下并松开 SW1(重置)→ 松开 SW3。 要使用 USB 上的 ISP 将固件写入 RW612,请双击位于 FRDM-RW612_PnP 文件夹中的 program_FRDM-RW612.bat 文件来运行该批处理文件: FRDM-RW612_PnP/program_FRDM-RW612.bat 大多数错误是由设备未以 ISP 模式启动引起的。如果您在使用开关 2 进入 ISP 模式时遇到困难,请尝试在按住 SW3 的同时将 USB 连接到 J10。 批处理文件处理完成后,拔下 USB 电缆,重新插上,然后重新启动开发板。 步骤 2:SR250 固件更新 要更新 SR250 的固件,请双击位于 SR250_FW 文件夹中的 Update_SR250_FW.bat 文件来运行该批处理文件: SR250_FW/Update_SR250_FW.bat 如果成功,拔下 USB 连接线,重新插上,然后重启主板。 步骤 3:运行检查 在设备管理器中检查 J8 端的通信 COM 端口号(例如 COM10)。 启动位于 Simple_demos 文件夹中的 Python 脚本,使用您刚刚确认的 COM 端口号作为参数,并验证通信是否成功。 python demo_ranging.py COM10 PnP路由设置现已完成! 3B. Zephyr SDK 方案:用于全面开发 此方案使用基于 Zephyr OS 的 SDK 进行构建和调试。它支持与 BLE 集成以及自定义应用程序的开发。 有两种方法:使用 VS Code + MCUXpresso,以及使用 west 命令行。两种方法都可以。这里,我们将介绍在 Windows 环境下使用 west 命令的方法。首先,在尽可能靠近 C 盘根目录的位置创建一个文件夹。 有关如何将 VS Code 与 MCUXpresso 配合使用的说明,请参阅入门指南或MCUXpresso for VS Code 文档。另请参阅本文档末尾列出的关于将 VS Code 与 MCUXpresso 配合使用的要点。 所需软件 Git :最新版本 CMake :3.21.1 或更高版本 Zephyr SDK :0.17.x Zephyr 版本与 Zephyr SDK 之间存在依赖关系。本教程使用Zephyr SDK 0.17.x 版本。请安装。不同版本的 SDK 可能会导致构建错误。 Python :3.8 或更高版本 请确保您已安装 Ninja 和 West。 pip3 install west ninja 串口终端:TeraTerm、PuTTY 或您选择的任何其他串口终端。 环境设置步骤 步骤 1:克隆存储库 git clone https://github.com/nxp-uwb/sr250-uwbiot-zephyr.git 步骤 2:西部初始化 cd sr250-uwbiot-zephyr west init -l --mf west.yml uwbiot-top 步骤 3:获取依赖关系 西部更新 west update 此过程需要一些时间才能完成。如果中途停止,请重新启动。在完成之前进行下一步操作会导致构建错误。 步骤 4:安装 Python 依赖包 pip install -r zephyr\scripts\requirements.txt 步骤 5:设置环境变量 在环境变量中设置 Zephyr SDK 的路径。 zephyr\zephyr-env.cmd 构建和编写 由于首先需要进行更新,我们将构建一个固件更新演示。 west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_sr2xx_fw_update\zephyr 构建成功后,我会将信息写入文件。 west build 我们将通过串口通信检查日志。默认情况下,代码仅在通信建立后执行。 连接两根 USB 线缆(J10 和 J8)。 检查连接到 J8 的一侧的 COM 端口号(参见步骤 3:PnP Root 的操作检查)。 启动终端软件并按如下方式配置端口: 将波特率设置为3,000,000 bps 。许多终端程序,例如 TeraTerm 和 PuTTY,不会将 3,000,000 列为波特率选项。即使选项中没有,您也可以手动输入。在文本框中输入“3000000”。 如果日志消息“成功!”出现在末尾,如下所示,则表示操作成功。 同样地,构建并刷写校准演示程序。 west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_device_calibration\zephyr west flash Zephyr SDK 根目录设置已完成! 需要注意的事项 Windows 路径长度限制(MAX_PATH) Windows 默认路径长度限制为 260 个字符。Zephyr 仓库的目录结构较深,这可能会导致路径长度超出限制。我们强烈建议您将项目保存在C 盘根目录附近的位置(例如 C:\uwb\ )。如果将其放置在更深的目录结构中,例如 C:\Users\username\Documents\Projects\... ,Zephyr 构建系统生成的路径将超出长度限制,从而导致错误。使用 VS Code + MCUXpresso 时,此问题尤为突出。如果难以将其放置在 C 盘根目录附近,请考虑以下解决方法。 操作方法: 我们建议使用 WSL2(适用于 Linux 的 Windows 子系统)。 或者,在 Windows 注册表中启用 LongPathsEnabled。 关于在 VS Code + MCUXpresso 中导入项目的注意事项 导入项目时,您需要将应用类型设置为“存储库应用程序” 。入门指南中并未重点提及这一点,但如果设置错误,很可能会导致构建错误。请务必检查此项。 需要完美构建的情况 如果更改构建选项或错误仍然存在,请尝试全新构建: west build --pristine -b frdm_rw612 sr250-uwbiot-zephyr/samples/demo_uwb_controller 固件版本错误 demo_sr2xx_fw_update 在执行此操作之前运行其他演示程序会导致固件版本错误。请务必先执行固件更新。 下一集预告 环境搭建完毕后,我们就可以运行演示了。下次,我们将讲解如何使用两种不同的方式运行 UWB 测距演示:即插即用 (PnP) 方式和 Zephyr SDK 方式。敬请期待! 参考链接 Trimension SR250 开发板入门指南 SR250 UWB 即插即用应用程序(GitHub) sr250-uwbiot-zephyr(GitHub) FRDM-RW612 产品页面 Trimension SR250 评估板 适用于 VS Code 的 MCUXpresso ========================= 即使您在本文的“评论”栏留言,我们目前也无法回复。 给您带来不便,我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 (如果您已经是NXP的代理商或与其有合作关系,可以直接向负责人咨询。) 在第一部分中,我们介绍了SR250的特性(将UWB测距和UWB雷达集成在单个芯片上)。在第二部分中,我们将搭建一个环境,使用评估板SR250UWBSHIELD + FRDM-RW612实际运行SR250。我们将介绍两种方案:无需构建的即插即用(PnP)方案和用于完整开发的Zephyr SDK方案。 (预计工作时间:10分钟) 日本博客
查看全文
NXP Trimension® SR250で始めるUWB入門 第2回:SR250UWBSHIELD + FRDM-RW612 セットアップガイド (日本語ブログ) 1. はじめに 第1回では、SR250がUWB測距とUWBレーダーを1チップに統合したデバイスであること、そして2026年3月にマスマーケット向けにリリースされたことを紹介しました。 今回からは、いよいよ実際にボードを動かします。評価ボードを入手して動作確認まで一緒に進めていきましょう。 第1回 UWBの基礎とSR250の概要 第2回(本記事) SR250評価ボード (SR250UWBSHIELD) のセットアップ 第3回 UWB測距 (Ranging) を試してみる 第4回 UWBレーダー (Radar) を試してみる SR250を試す方法は大きく2通りあります。ビルド不要のPnP (Plug-and-Play) ルートと、本格開発向けのZephyr SDKルート、どちらのルートかによって必要な準備が変わるため、先に決めておくとスムーズです。どちらも!という方も大歓迎です。 Windows以外でも動作可能ですが、今回はWindows PCのコマンドプロンプトを使用します。 ルート こんな方に 開発環境 A. PnP まず手軽に動かしてみたい! Python + PySerial のみ B. Zephyr SDK 本格的に開発したい・BLEと組み合わせたい Git・CMake・Python・Zephyr SDK 2. ハードウェアの準備 (A, B共通) 必要なハードウェア UWB測距の場合は相手側のデバイスが必要となります。2セットご用意いただければ、SR250 UWB SHIELDボード同士での測距を行うことができます。UWBが搭載されたスマートフォンをお持ちであれば、1セットのみでスマートフォンと測距することも可能です。 SR250UWBSHIELD:SR250搭載のArduino互換シールドボード FRDM-RW612:ホストMCUボード (Wi-Fi 6 / Bluetooth Low Energy 5.4 / 802.15.4 搭載) USB Type-Cケーブル × 2本 1本はFRDM-RW612に同梱されているので、もう1本ご準備ください 充電専用ケーブルではなく、データ通信対応のケーブルが必要です PCへの接続側はType-AでもType-Cでも構いません USB接続について SR250UWBSHIELD + FRDM-RW612の動作にはUSB-Cケーブルを2本接続します。それぞれの用途を確認しておきましょう。 コネクタ 用途 備考 J10 (MCU-Link) 電源供給・書き込み・デバッグ 接続必須。これがないと電源が入らない J8 (HS-USB) シリアル通信 (Virtual COM Port) COMポート確認時はJ8側のポート番号を使用 Windowsのデバイスマネージャーに2つのCOMポートが表示されますが、シリアル通信に使うのはJ8 (HS-USB) 側のCOMポートです。「USB Serial Device (COMx)」と表示されます。 リワーク:最初に確認が必要な重要作業 SR250-ARDシールドとFRDM-RW612はSPIで通信しますが、デフォルトのArduinoヘッダー配線ではSPIが正しく動作しません。以下の2通りのいずれかで対応してください。 方法1:半田付けによるリワーク(推奨) はんだごてをお持ちの方はSPIラインのリワークを行うことをお勧めします。一度やってしまえばケーブルも不要でスッキリします。 リワーク手順の詳細はスタートガイドを参照してください:Trimension SR250用開発ボードのスタート・ガイド 方法2:ジャンパ線での代替接続(手軽に試したい方) はんだ付けなしで試したい場合は、メスメス (Female-to-Female) のジャンパ線2本でFRDM-RW612のArduinoヘッダーピンを以下のように接続してください。 まず動作確認したい方はこちらの方法からどうぞ。 3A. PnPルート:Pythonだけで手軽に試す PnPアプリはビルド不要で、GitHubで提供されているFRDM-RW612用のUSBシリアル通信とSPI通信のプロトコル変換用FW (PnP用FW) を使ってSR250をPCから直接操作できます。PC側からPythonのUCIスクリプトを実行するだけで動作確認できます。 準備をするにあたって、2つの異なるFWが出てきます。最初に書き込むのは、RW612内で動作するプロトコル変換用のFWです。その後に、SR250のFW更新を行います。それぞれ書き込み方法が異なります (RW612はISPモード経由、SR250はPnP FW経由) ので、手順にご注意ください。   GitHubから必要なファイルを入手します。右上の "Code" のプルダウンメニューからZIPダウンロードが可能です。 GitHub: SR250 UWB Plug-and-Play Application 必要なソフトウェア Python 3.x PySerial: pip install pyserial 手順 Step 1: RW612 PnP用FWの書き込み USBケーブル2本 (J10・J8)を接続 ファームウェア書き込み専用モードであるISPモード(In-System Programming)でRW612を起動させる:SW3(ISP)を押しながらSW1 (リセット) を押して離す → SW3を離す ISP over USBでRW612へFWを書き込むため、FRDM-RW612_PnPフォルダにあるprogram_FRDM-RW612.batをダブルクリックでバッチファイルを実行: FRDM-RW612_PnP/program_FRDM-RW612.bat エラーが出る場合の多くはISPモードで起動できていないことが原因です。2のスイッチ操作でISPモードに入りにくい場合は、SW3を押しながらJ10にUSBを接続してみてください。 バッチファイルの処理が完了したら、USBケーブルを一度抜いて再接続し、ボードを再起動してください。 Step 2: SR250 FWアップデート SR250のFW更新のため、SR250_FWフォルダにあるUpdate_SR250_FW.batをダブルクリックでバッチファイルを実行: SR250_FW/Update_SR250_FW.bat 成功したら、USBケーブルを一度抜いて再接続し、ボードを再起動してください。 Step 3: 動作確認 デバイスマネージャーでJ8側の通信用COMポート番号を確認します (例: COM10) Simple_demosフォルダ内にあるPythonスクリプトで先ほど確認したCOMポート番号を引数にして起動し、通信が成功していることを確認します python demo_ranging.py COM10 PnPルートの準備はこれで完了です! 3B. Zephyr SDKルート:本格開発向け Zephyr OSベースのSDKを使ってビルド・デバッグを行うルートです。BLEとの組み合わせや独自アプリの開発に対応しています。 VS Code + MCUXpressoを使う方法と、westコマンドラインを使う方法の二つあります。どちらでも構いません。ここではWindows環境でwestコマンドを使う方法を紹介します。なるべくCドライブ直下に近いところにフォルダを作成して始めましょう。 VS Code + MCUXpressoを使う方法についてはスタートガイドやMCUXpresso for VS Codeをご参照ください。VS Code + MCUXpressoを使う方法での注意点だけ最後に記載にしてますので、そちらもご参照ください。 必要なソフトウェア Git: 最新版 Cmake: 3.21.1以降 Zephyr SDK: 0.17.x ZephyrのバージョンとZephyr SDKには依存関係があります。本手順では Zephyr SDK 0.17.x をインストールしてください。異なるバージョンのSDKではビルドエラーが発生する場合があります。 Python: 3.8以降 ninjaとwestをインストールしておきましょう pip3 install west ninja シリアルターミナル: TeraTerm・PuTTYなど、お好みのシリアルターミナル 環境構築手順 Step 1: リポジトリのクローン git clone https://github.com/nxp-uwb/sr250-uwbiot-zephyr.git Step 2: west初期化 cd sr250-uwbiot-zephyr west init -l --mf west.yml uwbiot-top Step 3: 依存関係の取得 west update west update は完了まで時間がかかります。途中で止まった場合は再実行してください。未完了のまま次に進むとビルドエラーの原因になります。 Step 4: Python依存パッケージのインストール pip install -r zephyr\scripts\requirements.txt Step 5: 環境変数の設定 Zephyr SDKのパスを環境変数に設定します。 zephyr\zephyr-env.cmd ビルドと書き込み 最初に更新が必要なため、まずFW更新用のデモをビルドします。 west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_sr2xx_fw_update\zephyr ビルドに成功したら書き込みます。 west build シリアル通信でログを確認します。デフォルトでは通信が確立してはじめてコードを実行するようになっています。 USBケーブル2本 (J10・J8)を接続 J8に接続している側のCOMポート番号を確認 (PnPルートのStep 3: 動作確認を参照) ターミナルソフトを起動し、ポートを以下のように設定します。 ボーレートは 3,000,000 bps に設定します。TeraTerm・PuTTYなど多くのターミナルソフトでは、ボーレートの選択肢に3,000,000が表示されません。選択肢になくても直接手入力できます。テキストボックスに「3000000」と打ち込んでください。 以下のように、最後にSuccess!のログが出力されていれば成功です。 同様にキャリブレーションデモをビルドして書き込みます。 west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_device_calibration\zephyr west flash Zephyr SDKルートの準備もこれで完了です! 注意点 Windowsのパス長制限(MAX_PATH) Windowsではデフォルトでパス長が260文字に制限されています。Zephyrのリポジトリは深いディレクトリ構造を持つため、この制限に引っかかることがあります。プロジェクトの保存場所はCドライブ直下に近い場所(例: C:\uwb\ など)を強くお勧めします。 C:\Users\username\Documents\Projects\... のような深い階層に置くと、Zephyrのビルドシステムが生成するパスが制限を超えてエラーになります。VS Code + MCUXpressoではこの問題がより顕著です。Cドライブ直下に近い場所に置くのが難しい場合は以下の対処方法をご検討ください。 対処方法: WSL2(Windows Subsystem for Linux)の使用を推奨 またはWindowsのレジストリでLongPathsEnabledを有効化 VS Code + MCUXpressoでのプロジェクトインポート時の注意 プロジェクトのインポート時には、App typeを「Repository application」に設定することが必要です。スタートガイドにはハイライトされていませんが、ここを誤るとビルドエラーになりやすいポイントです。必ず確認してください。 pristine buildが必要なケース ビルドオプションを変更した場合や、エラーが解消しない場合はpristineビルドを試してください: west build --pristine -b frdm_rw612 sr250-uwbiot-zephyr/samples/demo_uwb_controller FWバージョンエラー demo_sr2xx_fw_update を実行する前に他のデモを動かすとFWバージョンエラーが発生します。必ずFWアップデートを最初に実行してください。 次回予告 環境が整ったら、いよいよデモを動かします。次回はUWB測距デモを動かす方法について、PnPルートとZephyr SDKルート、2つのルートそれぞれ解説します。お楽しみに! 参考リンク Trimension SR250用開発ボードのスタート・ガイド SR250 UWB Plug-and-Play Application(GitHub) sr250-uwbiot-zephyr(GitHub) FRDM-RW612 製品ページ Trimension SR250 評価ボード MCUXpresso for VS Code ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) 第1回ではSR250の特長 (UWB測距+UWBレーダーの1チップ統合) を紹介しました。第2回では評価ボード SR250UWBSHIELD + FRDM-RW612 を使って、実際にSR250を動かすための環境を整えます。ビルド不要のPnP (Plug-and-Play) ルートと、本格開発向けのZephyr SDKルートの2通りを解説します。 (作業時間:最短10分) 日本語ブログ
查看全文
Solution to FRDM-A-S32K144 and FRDM-A-S32K144N not detected during initial USB-C connection Overview The FRDM-A-S32K144 and FRDM-A-S32K144N boards ship with a factory-programmed demonstration application that showcases USB Power Delivery functionality through an RGB LED example. Under certain USB-C host and cable combinations, the factory application may prevent the on-board OpenSDA/K20 debugger from completing its initialization sequence and becoming available to the host system. When this occurs, the board may appear unresponsive and cannot be programmed through the standard OpenSDA interface. This article describes how to identify the condition and provides a simple one-time recovery procedure. This behavior is limited to the following boards: FRDM-A-S32K144 FRDM-A-S32K144N No other FRDM boards are affected. Symptoms The behavior is typically observed during the initial programming session while the factory application is still present. During the first use of the board, users may observe the following: The board is connected using a USB-C to USB-C cable. The operating system does not detect the board. No OpenSDA programming interface appears. Debugging and programming tools cannot establish communication. The OpenSDA/K20 status LED (D4) remains OFF. Although the board may not be detected by the host computer, the factory application may continue running on the target MCU. FRDM-A-S32K144 OpenSDA/K20 debugger status LED (D4) not working as expectedFRDM-A-S32K144 OpenSDA/K20 debugger status LED (D4) not working as expected     Issue The factory image included on the affected boards performs USB Power Delivery negotiation during startup. On certain USB-C host configurations, this initialization sequence may prevent the on-board OpenSDA/K20 debugger from reaching its operational state. As a result, the debugger does not enumerate on the host PC and programming access is not available. Once the factory image is replaced with a user application, the startup sequence changes and the OpenSDA/K20 debugger initializes normally. Workaround Materials required FRDM-A-S32K144 or FRDM-A-S32K144N board USB-A to USB-C data cable Host computer with an available USB port S32 Design Studio IDE 3.6.5 or above Any valid S32K144 application image If the board is not detected through a USB-C to USB-C connection during the initial programming session: Disconnect the board from the host PC Reconnect the board using a USB-A to USB-C cable Verify that the D4 LED is illuminated solid orange Program in S32 Design Studio any valid application to the S32K144 MCU, such as: S32K144 GPIO LED Blink example Any S32K144 Application Code Hub demonstration project Any S32K144 custom user application Wait for the programming operation to complete successfully The newly programmed application replaces the factory image and restores normal debugger operation.   Expected operation Once the workaround described above is applied successfully, the board LED D4 is illuminated with a solid orange light, and the device manager operating system detects the board as a COM port and a PEMicro OpenSDA Debug Driver. FRDM-A-S32K144 OpenSDA/K20 debugger status LED (D4) working as expectedFRDM-A-S32K144 OpenSDA/K20 debugger status LED (D4) working as expected FRDM-A-S32K144 correctly detected by Windows device managerFRDM-A-S32K144 correctly detected by Windows device manager After a successful programming session: USB-C to USB-C cables can be used normally. Debugging functions operate as expected. Programming functions operate as expected. No additional configuration is required. The recovery process only needs to be performed once. Subsequent application updates can be performed using either USB-C to USB-C or USB-A to USB-C connections (if no PD is needed). Troubleshooting checklist If D4 is OFF, the OpenSDA/K20 debugger has not completed initialization. Check the next list before applying the turnaround again:  Verify that D4 is solid orange. Confirm the USB cable supports data transfer. Check that the operating system detects the OpenSDA device. Reprogram the board using a USB-A to USB-C connection. Test with an alternative USB port or host PC. Choose another project application to flash. If D4 is still OFF, the OpenSDA/K20 debugger may be damaged or present another error. Please review the S32K Knowledge Base or the FRDM community for more information. Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction. If your FRDM-A-S32K144 or FRDM-A-S32K144N is not detected during its first USB-C connection, this article explains the cause, how to verify OpenSDA/K20 status, and the steps to quickly enable normal operation.
查看全文
S32K344 EVB HDQFP172 的 ADC 配置 您好, 我想执行连接到板载电位器的 ADC 通道ADC0_P7 ,并将转换后的值用于调暗板载 LED( GPIO29 )。 配置完成后,显示如下内容: 错误: platform.driver.pins 此外,在配置完成后构建项目时,我们遇到了以下编译错误:image(error_Adc) 我还附上了下面的配置设置。 注:我已添加了示例中的项目。 请解决此问题。 谢谢! 拉基 Re: ADC Configuration for S32K344 EVB HDQFP172 您好, 请尝试按照提示解决“问题”窗口中显示的错误。 大部分个人驱动程序可能不会添加到工具链中。在较新的 S32DS 中,通常在通过配置工具更新代码后,此功能就会消失。或者您需要通过“管理 SDK 元器件”手动添加它。 请确保已选择使用的元器件,然后再次更新代码。 对于 Siul2_Port 元器件,可能出现 2 个错误。 - Pin 工具配置了 2 个引脚,而 Siul2_port 只配置了 1 个引脚,两者设置不匹配。 对于 ADC 输入,无需进行引脚设置,模拟路径始终启用,您可以从引脚工具中删除它。 - 另一个可能是引脚工具中的功能组命名。 如果遇到问题,请分享您的完整项目。 BR,彼得 Re: ADC Configuration for S32K344 EVB HDQFP172 您好, 添加 Siul2_Port 后出现此错误。 我的引脚配置如下: 非常感谢您抽出时间回复。 BR, 拉基 Re: ADC Configuration for S32K344 EVB HDQFP172 您好, 添加 Siul2_Port 元器件,更新代码,并构建。 BR,彼得 Re: ADC Configuration for S32K344 EVB HDQFP172 嗨@PetrS , 谢谢你的关注。 附件如下。 Br, 拉基 Re: ADC Configuration for S32K344 EVB HDQFP172 您好, 您没有上传任何文件或截图。 您可以参考以下使用电位器进行ADC采样的示例: 示例 S32K312 ADC IP 连续扫描 DMA (S32DS 3.6, RTD 6.0.0) RTD400 LLD K344 ADC 软件/硬件触发示例 BR,Petr Re: ADC Configuration for S32K344 EVB HDQFP172 嗨,Petrs, 感谢您的支持。 您能否提供一些关于AUTOSAR版本的资源供我尝试? 我尝试了示例中的项目。但却不起作用。 请帮忙。 BR, 拉基
查看全文
MCX-N9XX 评估板 1.8V 电源存在问题。 我有一个 MCXN9XX 评估板,需要从 P1_16 (J17) 和 P1_17 (J18) 焊盘上获得 1.8V 输出,以便与工作电压为 1.8V 的外部 I3C 集线器进行 I3C 通信。为了在焊盘上获得 1.8V 电压,我重新排列了跳线,以便在 MCU_PWR 轨上获得 1.8V 电压,该轨也为 VDD_MCU 供电。执行此配置后,“MCUXpresso”工具无法发现目标设备,并显示“无法与内核通信”(屏幕截图附后)。 请问谁能帮我确定正确的跳线设置,以便在烧录代码的同时,能够在 IO 焊盘 J16 和 J17 上获得 1.8V 电压? 错误截图: 电路板设计 FRDM 培训 HW-开源 MCX N
查看全文