MCU-Link - Linkserver - 性能テストにおける不要サイクルカウントの注入 こんにちは、 まず最初に、書かれている内容はすべてClaudeエージェントによるものです。なぜなら、私が作成するものはすべてObsidianリポジトリ内で作成され、エージェントに書き込ませる方が速いからです。 🙂  私は修士論文のために、FRDM-MCXN947を用いてサイクル精度のタイミング測定を行っており、いくつかのリアルタイムオペレーティングシステムのスケジューリングオーバーヘッドを比較しています。報告するすべての数値は2つのDWT->CYCCNT読み取り値の差なので、測定は1サイクル単位で繰り返し可能でなければなりません。違いますし、かなり長い調査の末、原因はドキュメントから確認できない一つのメカニズムに絞り込みました。私の説明が本当に正しいかどうか確認したいのですが、もし間違っているとしたら、他の可能性をすべて排除してしまい、候補が一人も残っていないことになります。 質問の要点を簡潔にまとめると、デバッグセッションが開いている間、LinkServerは定期的にDHCSRとCPACRを読み取り、コアが停止したかどうかを確認します。これらはどちらもプライベート周辺バス内のSCSレジスタであり、アクセスはコア内で処理され、コードバスやシステムバスには表示されません。私の仮定では、そのようなアクセスはコア内部の命令フェッチやデータアクセスと競合しており、これが測定ウィンドウ内にポールが届くたびに数サイクルのコストを落とす原因だと思います。その推測は正しいですか？ 設定 ボードはFRDM-MCXN947で、コア0のみを使用しています。実際の測定では150MHz、後述する制御実験では12MHzを使用しています。搭載MCU-Linkを使ってLinkServerを使ってデバッグしており、これはUSBでCMSIS-DAP v2を言語し、SWDの50と500のワイヤークロックも試しました。起動設定は--no-rtosと--semihost-port=-1を通過し、liveWatchは無効化されているため、コアが動作している間はIDEがターゲットから何かを読み取ることはありません。 テスト対象のコードは、RAMのアドレス0x2000_0000から実行されます。つまり、システムバス経由でフェッチされるということです。キャッシュとRAM ECCは無効になっています。画像がRAMに入る方法にはもう一つ別のバリエーションがあります。ほとんどの作業ではプローブが単にRAMに読み込みますが、ある実験では画像をフラッシュに保存し、起動時にRAMにコピーしました。なぜなら、RAMにしか存在しないイメージはプローブなしでは起動できないからです。その区別はその実験に限っていて、今ここで言及するのは後で明確に設定できるようにするためです。 計測対象は、指定された回数だけ実行される空のカウントループであり、実行前後にCYCCNTを読み取ることで時間を計測します。私はそれぞれの測定を64回繰り返します。 問題 同じ測定を2回行っても、同じ結果は得られない。空ループでは64の値が3〜6サイクルにわたって分散し、実際のアプリケーションコードでは10万回中約9回が他のすべての反復より1〜10サイクル上に出てきます。偏差は常に上昇する一方であり、下降することは決してなく、最小値は完全に安定しており、再現性も高い。最も参考になったのは、測定間隔の長さに応じて変動するコストが、測定呼び出しごとの固定コストではないという点です。これは、私の計測機器のどこかに一定のオーバーヘッドが存在する可能性をすでに排除しています。 これが全容です。各セルは空のループの64回の測定値です。「外れ値」は、64回のうち最初の値を超えた回数をカウントし、minとmaxはループのクリーン値からのサイクル数として示されます。 コアループ数 SWD 50: 外れ値最小値最大値 SWD 500: 外れ値最小値最大値 コアF ループ 64回の測定あたりの外れ値 最小ジッター数 最大ジッター数 外れ値/64mea。 最小ジッター 最大ジッター 12MHz 100 0 +13 +13 0 +13 +13   1000 4 +13 +15 7 +13 +16   10000 24 +13 +16 18 +13 +17   100000 55 +13 +23 57 +13 +22   1,000,000 56 +40 +69 59 +45 +102 150MHz 100 0 +13 +13 0 +13 +13   1000 0 +13 +13 1 +13 +15   10000 4 +13 +15 3 +13 +15   100000 13 +13 +15 16 +13 +17   1,000,000 53 +13 +20 60 +13 +25 この表からは３つのことが分かります。まず、定数+13は問題の一部ではありません。これは、コアクロックとワイヤ速度の両方において、飽和していないすべてのセルで最小値として現れ、ループのプロローグとCYCCNTの読み取り自体に単純に一致します。これはコアクロックとプローブの両方から独立しているため、私が減算する固定バイアスであり、+13を超える値はすべて私が実際に追い求めているものです。 第二に、そしてこれが重要な点だが、この障害は実行されたサイクル数ではなく、実際の時間経過に比例する。同じループ回数で2つのクロックを比較すると、150 MHzよりも12 MHzの方が一貫して外れ値が多くなります。1000回の反復では4対0、7対1、1万回の反復では24対4、18対3、10万回の反復では55対13、57対16です。命令ストリームは両者とも同一であるため、同じサイクル数を実行し、唯一の違いは12 MHzの実行がリアルタイムで12.5倍長くかかることです。 第三に、SWDワイヤークロックは全く影響しません。上記の10組の一致した対では、カウントは両方向に散乱し、カウントノイズ内にとどまるため、ワイヤーレートが10倍に変化してもカウントは残ります。何がペースを決めるにせよ、それはワイヤーではない。 根本原因から除外 最初に断っておきたいのは、リセット時のデフォルト値がまだ有効であると仮定するのではなく、セッションを開いた状態でターゲットから関連するレジスタを実際に読み戻すことによって、これらの可能性の多くが排除されたということです。 SoC側では、CPU1、eDMA0、eDMA1、SmartDMAはすべて無効化されており、RAMのECCもコードキャッシュもオフなので、他のメモリが競合していません。トレース側では、ITMが無効化され、刺激ポートも有効化されず、タイムスタンプもオフ、ストール・フォー・トレースビットはクリアでETMもオフになります。つまり、トレースパケットが何も生成されていないため、何もストールしていないため、それを配信するものが何も起こらないということです。DWT内では、PCサンプリングがオフで、例外トレースがオフで、すべてのイベントカウンタがオフで、ウォッチポイントコンパレータも使われず、パフォーマンスモニターもオフです。TRCENAはもちろん設定されていますが、CYCCNTが依存しているため、妨害されたCASEと未攪乱のCASEの両方に設定されている必要があります。したがって、それが両者の違いにはなりません。 割り込みと例外は、その規模の大きさという理由だけで除外されます。このコアにおける例外処理は、25～50サイクル程度のコストがかかり、私の場合は1～10の誤差が生じる。例外の小さなバージョンは存在せず、割り込みマスクが何を言おうとクラス全体が除外されます。ブレークポイントも同様の理由で使われていません。FPBコンパレータはマッチするまでコストがかかり、マッチするとコアを停止させるため、わずかに遅延しません。 対照実験の結果、テスト対象のコードは除外されました。空ループにはデータ依存的な仕事が一切含まれないため、それ自体で変化することはなく、いずれにせよ変化します。つまり、原因は私が測定しているものではなくプラットフォームにあります。 左デバッガメモリの読み取り値は、これまでで最も有望な説明であり、私がそれを却下した理由を説明したいと思います。なぜなら、それはほとんどの人が合理的に疑うであろうメカニズムだからです。SRAMのデバッグリードはコアから離れ、バスポートをめぐってコアと戦うため、この仕組みは完璧に機能します。問題は、それが起こらないということだ。IDEが行うすべての読み取りはGDB mパケットとして移動し、gdbserverログには$vCont間に単一のパケットはありません。実行を開始し、ホストが32秒後に割り込みます。そのログで読み取られるすべてのメモリは停止後に残っており、これはコアが停止した後にIDEがビューを埋めるだけです。同じ議論は、デバッガがCYCCNT自体を読み取っているという、さらに魅力的な理論を否定する。この理論は私の測定結果と直接矛盾する。なぜなら、それもmパケットとして現れるはずだが、実際には現れず、いずれにせよliveWatchは無効になっているからだ。 どうやら プローブをセッションから分離するために、プローブを物理的に接続した状態で同一のバイナリを実行しました。 しかし、デバッグセッションは開かれていません。これは、起動時にフラッシュメモリからRAMへのコピーが必要だった実験です。 前述したように、RAMのみのイメージはプローブなしではロードする方法がないためです。探査機はそのまま残った 両方のランでコネクテッドだったので、違いはセッションが接続されているかどうかだけでした。 デバッグセッションを行わないと、ジッターは解消される。同じバイナリ、同じクロック、同じブートパス。SO、 プローブがコネクテッドなのではなく、単に接続されているだけで「いいえ」を発信するプローブではありません トランザクションはコストがかかりませんし、セッションを接続するとジッターが戻ります。 その時点で、セッション自体が確実に引き起こした乱れがあり、リアルタイムでペースが調整されています コアクロックでではなく、私は考えられる限りのあらゆるメカニズムを排除していました。 コアが稼働している間にLinkServerが何を送信しているかを調べるために、USBPcapとWiresharkでMCU-LinkのCMSIS-DAPバルクエンドポイントをキャプチャしました。2つのDAP_Transferリクエストが、約50ミリ秒ごとに継続的に繰り返される。 その数字については、すぐに補足説明をしなければなりません。ポーリングは固定タイマーのようには見えません。なぜなら、ホストは前の応答が返ってきた後に次のリクエストを送るように見えるため、この間隔は少なくとも部分的にイベント駆動型です — ホストのターンアラウンドとUSBレイテンシ、さらにホストが自ら挿入する遅延が加わるのです。つまり50ミリ秒は、繰り返しの頻度を示す桁違いの数字であり、引用したい期間ではありません。また、その速度からきれいに逆算することもできません。 最初の要求では、DHCSRとCPACRが一緒に記載されています。回線上のデータは 05 00 06 08 00 00 00 00 05 f0 ed 00 e0 0f 08 00 00 00 00 05 88 ed 00 e0 0f であり、これをデコードすると次のようになります。 # Req デコードデータ ターゲットアクセス 1 08 DP書き込みSELECT 0x00000000 なし（DP内部） 2 05 AP は TAR を書きます 0xE000EDF0 (DHCSR) なし（AP内部） 3 0F AP通信はDRWを読んだ。 — 1読了、PPB 4 08 DP書き込みSELECT 0x00000000 なし（DP内部） 5 05 AP は TAR を書きます 0xE000ED88 (CPACR) なし（AP内部） 6 0F AP通信はDRWを読んだ。 — 1読了、PPB 回答は、DHCSR = 0x01100001 であり、これはコアがセキュアデバッグを有効にして命令をリタイアしていることを意味します。また、CPACR = 0x00F00003 であり、これはFPUに完全にアクセスできることを意味します。2 番目の要求は 05 00 03 08 00 00 00 00 05 f0 ed 00 e0 0f で、これは上記の前半部分のみで、FPU チェックなしでコアが停止したかどうかのみを尋ねます。 SO、測定ウィンドウ中にターゲットに到達する全トラフィックは2PPB読み取り、短いリクエストの場合は1回です。SELECTとTARの書き込みは、それぞれDPとAP内部にあるため、ターゲットアクセスは一切発生しません。実際にどこかへ行くのは2回のDRW読み取りだけです。転送カウントとデータワードカウントを照合し、このアダプターでposted-readシフトなしの直接的な値-レジスタ対応を確認したので、どの値がどのアドレスに属しているか確信を持っています。 両方のアドレスはPPB内のSCSレジスタであり、どちらもSoCバスマトリックスには表示されません。この中にはSRAMアクセスはなく、コアレジスタファイルにもアクセスできません。なぜなら、DCRSR/DCRDRキーホールを通るものは一切入らないため、コアを先に停止させる必要があるからです。補足として、S0からS31およびFPSCRの71転送分のダンプが別途キャプチャに含まれていますが、これはコアがstopAtSymbolブレークポイントで停止した時点のみであり、実行中ではありません。私の推測では、CPACRはDHCSRとセットされているため、コアが停止した瞬間に浮動小数点レジスタが稼働しているかどうかをアダプターがすでに把握できるようにしているのだと思います。 確認すべき前提条件： 私が現在考えているのは、こういうことです。リクエストはD-AHBデバッグを通じてコアに入ります ポートはコア内部のインターコネクトによって、コア自身の命令に対して仲裁されます フェッチやデータアクセス。コア内で解決されているからといって、アクセスが 実行から分離;それでも実行は共有された内部段階で行われます。コアが優先され、 SO、通常のCASEではデバッグアクセスが待機し、コアは影響を受けずに継続されます。残留費用 デバッグビートがすでに進行中でプリエンプトできない場合にのみ現れ、その場合コアは そのビートが終わるのを待たなければなりません。その待ち時間はまさに私が観察している通りです。数サイクル、いつも 上昇傾向を示し、しかも世論調査がたまたま含まれる測定期間のごく一部に限られる。 質問: 私が上で説明したメカニズムは、実際には正しいのでしょうか？DHCSRやCPACRなどのPPBやSCSレジスタのDAP発端読み取りは、D-AHBデバッグポート経由で到着し、M33内で実行中のコア自身のアクセスと競合し、わずかなサイクルだけストップさせることができるのでしょうか?それとも、デバッグポートはPPBターゲットの実行パスから本当に切り離していて、すべて除外してしまい、本当の原因が見つからないのでしょうか? これはどこかに文書化されていますか？私はCortex-M33 TRM(100230_0100_07_en)を持っていて、D-AHBと内部インターコネクトが見えますが、コアが稼働している間にコア内部PPB空間へのデバッグアクセスにかかる費用については何も見つかりませんでした。適切な箇所、あるいはMCXN947特有のDAPの統合方法に関する情報があれば、大変助かります。 CYCCNTはそもそもそのような停滞を認識できるだろうか？言い換えれば、コアは本当に支えられていて、CYCCNTがカウントする実際の実行サイクルであり、他のルートによって妨害されているのではないかということです。 LinkServerの停止状態ポーリングを遅くしたり、無効にしたりする方法はありますか？そうすれば、私が求めている明確な確認が得られるでしょう。つまり、投票頻度を変更して、外れ値の発生率がそれに追随するかどうかを確認するのです。それに関する設定は見つからず、コアの実行中に定期的なDHCSR読み取りを減らすか停止させるものであれば、このテストには有効です。 もしその仕組みが実在するなら、セッションを接続せずに測定することは、この部品のサイクル精度を正確に測定するための正しい方法なのでしょうか？それが今の私のやり方で、セッションが避けられない場合は、複数のウィンドウにわたって最小値を取得し、どれだけのウィンドウがどれだけずれたかを報告するという方法に頼っています。それが一般的な回答なのか、それともライブセッションで正確に測定するための適切な方法があるのかを知りたいです。 コアとメモリ 開発ボード Re: MCU-Link - Linkserver - Injection of unwanted cyclecounts at performance tests こんにちは、 @hms-isyu さん。 詳細な分析をありがとうございました。 申し訳ありませんが、この質問はNXP MCUアプリケーションのサポートの通常の範囲を超えています。MCXN947、MCU-Link、SDK、デバイス使用に関する質問にはお手伝いできます。しかし、あなたが調査している挙動はCortex-M33のデバッグアーキテクチャとサイクル精度の高いパフォーマンス解析に関わっており、私の専門外です。 パフォーマンス測定時に追加サイクルカウントを注入することに関する質問は、Armサポートにお問い合わせください。 ご理解いただきありがとうございます。 BR アリス

如何获取 SC667512MVA 的数据手册 尊敬的恩智浦技术支持团队： 我写信是为了询问如何才能获得SC667512MVA的官方数据手册。   请告知获取此文件所需的步骤。 谢谢！ 顺祝商祺！ Re: How to obtain datasheet for SC667512MVA 嗨@shenye SC667512MVA 是一个定制零件编号。定制设备的文档仅提供给为之开发该设备的特定客户。很遗憾，我们没有权限分享或提供与此设备相关的文档。 问候， 卢卡斯

S32K311 LCU Rise/Fall Filter Deadtime Occasionally Reduced from 2 µs to 1 µs Hi NXP Team, I am using an S32K311 with RTD 5.0. The PWM signals are generated by eMIOS0 and routed directly to the LCU0 outputs: eMIOS0_CH0 -> LCU0_OUT0 eMIOS0_CH1 -> LCU0_OUT1 eMIOS0_CH2 -> LCU0_OUT2 eMIOS0_CH3 -> LCU0_OUT3 eMIOS0_CH4 -> LCU0_OUT4 eMIOS0_CH5 -> LCU0_OUT5   The LCU is configured to insert deadtime using the Rise/Fall Filter.   Configuration MCU: S32K311 RTD Version: 5.0 PWM source: eMIOS0 Deadtime generation: LCU Rise/Fall Filter Rise Filter on Highside Channels = 192 Fall Filter on Lowside Channels = 192 Configured deadtime = 2 µs Observed behavior Most switching events generate the expected 2 µs deadtime. However, occasionally one transition (either the rising edge or the falling edge) has only about 1 µs deadtime instead of 2 µs. This occurs intermittently while the PWM frequency and duty cycle remain unchanged. The attached logic analyzer capture shows this behavior. Questions Is this variation expected when using the LCU Rise/Fall Filter? Are there any synchronization requirements between the eMIOS outputs and the LCU filter? Can the LCU filter occasionally shorten the programmed delay due to internal synchronization or clock-domain crossing? Is there any known limitation or errata related to the Rise/Fall Filter on the S32K311? Any guidance would be appreciated. Thank you. Re: S32K311 LCU Rise/Fall Filter Deadtime Occasionally Reduced from 2 µs to 1 µs Hi@Esakki 1. Your value  192 = 2 µs  implies an LCU filter tick of about： 2us / 192 = 10.4167 ns -> 1/ 10.4167 ns = 96MHz, If the effective LCU/peripheral clock or prescaler changes, or if a different clock is selected than assumed, the real delay changes. 2.Using an oscilloscope for testing is more accurate, and the waveform is related to the external capacitive reactance; a large capacitive reactance can also cause waveform instability.

需要协助解决NBP8FD4ST1压力传感器SPI通信问题 您好， 我正在使用NBP8FD4ST1压力传感器和S32K146微控制器。传感器的CS_B/WAKE-UP引脚连接到微控制器的 GPIO 引脚。 逻辑分析仪的信号映射关系如下： D0 → SCLK D1 → CS_B D3 → 就绪 D5 → 中同轴 D7 → MOSI 在通信序列中，当我将CS_B引脚拉低以请求 SPI 通信时， READY引脚如预期般置位。READY 变为高电平后，我发送SPIOPS 寄存器 READ命令 (0x00E1) 。但是，该传感器在 MISO 上始终返回0x0000 。因此，固件验证失败，随后 CS_B 引脚被拉高以终止事务。 请问您能否帮我确认一下我的 SPI 通信序列是否正确，或者我是否遗漏了任何必要的步骤，例如数据手册中描述的唤醒序列、虚拟传输或 SPIOPS 处理？ 我还附上了逻辑分析仪的截图供您参考。 感谢您提前给予的支持。 此致， 普拉蒂尤莎。 Pratyusha_0-1783666219816.png 压力传感器 Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor 你好， Pratyusha， 请注意，NXP 的 MEMS 传感器业务（包括 NBP8FD4ST1 等压力传感器）已转让给意法半导体。自 2026 年 2 月 2 日起，这些传感器的技术支持、产品文档和开发活动将由 STM 负责。因此，很遗憾，我们无法再为 NBP8FD4ST1 提供技术支持。 我建议您直接通过STM的支持渠道或社区论坛联系他们，那里的传感器专家可以帮助您解决实施和通信方面的问题。 BRs，托马斯 Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor 从你的图表 D0 → SCLK 来看，读取 SPIOPS 时没有时钟信号？ Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor @suncongjohnson谢谢你的回复。我已经将 SPI 外设配置为 16 位传输，因此我期望每次 SPI 事务都会产生 16 个 SCLK 脉冲。但是，当发出 SPIOPS READ命令时，D0 (SCLK) 线上不会产生 SCLK 信号。 const lpspi_master_config_t lpspiCom1_MasterConfig0 = { 每秒比特数= 1000000U， .whichPcs= LPSPI_PCS0， .pcs极性= LPSPI_ACTIVE_LOW， .isPcs连续= true， .bitcount= 16U， .lpspiSrcClk= 8000000U， .clkPhase= LPSPI_CLOCK_PHASE_1ST_EDGE， .clkPolarity= LPSPI_SCK_ACTIVE_HIGH， .lsbFirst= false， .转移类型= LPSPI_USING_INTERRUPTS， .rxDMAChannel= 255， .txDMAChannel= 255， 。打回来= NULL， .callbackParam= NULL， };

i.MXRT685S: Boot from external flash via HS SPI bus I have an external SPI NOR flash device wired to the HS SPI bus interface (Flexcomm 14) on a RT685s. I want to boot from this flash device; however, I've read that the only master boot options are a FlexSPI boot, SD boot, and eMMC boot. Is it possible to boot from this external flash using the high-speed SPI bus (Flexcomm 14)? If so, what are the requirements/setup steps I must follow to execute this? Re: i.MXRT685S: Boot from external flash via HS SPI bus Here below is some application notes for reference for NOR boot  AN12751 How to Enable Recovery Boot from QSPI Flash AN12773 How to Enable Master Boot from Serial NOR Flash Re: i.MXRT685S: Boot from external flash via HS SPI bus Hi @lgibarra9, It is not possible to boot from an external SPI NOR Flash using the High-Speed SPI bus from FC14. This bus can be used (besides run-time SPI communication) to download an image when the MCU is in ISP mode. But for normal boot operation from an external flash, the High-Speed SPI bus is not an option, so your SPI NOR flash should instead be connected to the FlexSPI bus. BR, Edwin.

Regarding FEE initialization time Hi, NXP expert, I have an issue with the S32K312 feed initialization time and would like to consult about it. The details are as follows: I configured two fee storage clustergroups, one primary and one standby. The standby is a backup of the primary. A total of 19 blocks were configured, and the blocks are stored in both the primary and standby. The software version is Mcal RTD4.0.0 HF02, and Burst mode is enabled. Chenxu1_0-1785460201957.png Test method: Upon power-up, the initialization time is printed (after calling Mem_43_INFLS_Initt(), MemAcc_Initt(), and Fee_Init(), wait for the Fee_GetStatus() interface to return MEMIF_IDLE), and all blocks are written with data once. The test results are as follows: Number of power-ups Initialization time (ms) illustrate 1 8 2 15 3 twenty three 4 40 5 48 6 57 7 65 8 74 9 82 10 90 11 99 12 107 13 115 14 124 15 133 16 141 17 149 18 158 19 166 20 175 twenty one 183 twenty two 192 twenty three 200 twenty four 209 25 217 26 226 27 234 28 8 Cluster paging Based on the above tests, we found that the time for each increment changes very quickly. Therefore, we would like to inquire whether there is a formula for calculating the initial time and whether it can be optimized. Re: 关于FEE初始化时间 Hi @Chenxu1  There is no formula provided by the FEE driver documentation to calculate the initialization time. The initialization time depends on the actual state of the FEE storage, such as the amount of stored data, number of records, and whether any cluster recovery or swap is required. The main configuration parameter that can improve initialization performance is FeeDataBufferSize, as a larger buffer allows more data to be processed per Fls_MainFunction cycle. See please Fee user manual for details. For a realistic estimate, the initialization time should be measured on the target configuration after prolonged FEE usage and multiple write cycles. Regards, Lukas Re: 关于FEE初始化时间 Yes, this has been discussed here several times. For example: https://community.nxp.com/t5/S32K/S32K312-FEE-FLS-INIT-time/m-p/2024041 Regards, Lukas Re: 关于FEE初始化时间 Hi， Currently, writing 16 bytes causes the next initialization to take 2ms longer. At this point, there's no page switching involved—just reinitializing and reading 16 bytes again, which adds 2ms. Is this normal?

RW612 - PM4 current is abnormal. Hi Experts. We have recently been using the u-blox W10 module in some of our mass-production products. However, we have observed that the PM4 current consumption varies significantly from module to module, ranging from around 300 µA up to 1 mA. To further investigate, I tested with two FRDM-RW612 development kits, without making any rework or modifications, and programmed both with the Power Manager Test (bare-metal) sample application from the NXP SDK v25.6.0. On DK1, measuring current through JP9, the PM4 current consumption is around 400 µA, which is as expected. On DK2, under the exact same test conditions, the PM4 current consumption is around 1 mA. I repeated this test 120 times, and the results were consistently the same. Interestingly, when I applied hot air to DK2, the PM4 current dropped to ~400 µA (normal value). But after a few minutes of cooling, the current rose back to ~1 mA. Reapplying hot air again would temporarily bring the current back down. Could you please advise how I should analyze this issue? I am using the official development kits and the unmodified sample code, and I can reproduce the problem reliably. Re: RW612 - PM4 current is abnormal. Hi Daniel. The yellow cable on this K.O. board is used to measure the current of VPA with 0 ohms resistance(R218). WeiliWang_0-1758787079290.png Also,i have sent a private message. Could you check it? Re: RW612 - PM4 current is abnormal. Hi, I tested the power manager test with the 25.09 SDK using 2 FRDM-RW612 board. Nevertheless, I got expected results with both of them. DanielRuvalcaba_4-1758773852825.png The measurement is on JP9. Could you please tell me what the cables in your KO FRDM board are for? Regards, Daniel. Re: RW612 - PM4 current is abnormal. Hi Daniel. The K.O. board yellow cable for measuring VPA current. I've removed the R218 for measuring the VPA current WeiliWang_0-1758687668677.png Re: RW612 - PM4 current is abnormal. Hi, Sorry for the delay. I don't currently have a way to measure current consumption, but I should be able to do it tomorrow. Please give me some time to gather the measurements. By the way, could you please tell me what the cables in the KO FRDM are for? Regards, Daniel. Re: RW612 - PM4 current is abnormal. Hi Daniel. Here's another update: We used the uBlox IRIS-W106-30B module. We opened the shielding cover and measured the current leakage in the ublox IRIS-W106-30B module under a specific test condition (K.O. case). We found a current leakage of 657 µA at VPA. Therefore, based on the experimental results, the source of the leakage current in both the FRDM612 and ublox IRIS-W106-30B appears to be the current drawn from the VPA. Re: RW612 - PM4 current is abnormal. Hi Daniel. My FRDM's picture is below: WeiliWang_0-1758328990924.png WeiliWang_1-1758329028621.png WeiliWang_2-1758329081576.png WeiliWang_3-1758329134480.png Re: RW612 - PM4 current is abnormal. Hi, Could you please share a picture of your FRDMs? We are checking this. Please give me some time until I get an update to share. Regards, Daniel. Re: RW612 - PM4 current is abnormal. Hi Daniel. I've identified the 700µA "gap current"; my measurements show that this current is being drawn from the VPA pin. Is this issue something that can be resolved through software updates or patches? We have already purchased 1560 units from U-blox, and our client is about to undergo RF certification in six different countries. I need to know if this problem can be fixed. Is it possible to solve this problem using a patch? WeiliWang_0-1758251280118.png Re: RW612 - PM4 current is abnormal. Hi Daniel. also I have tried tested PM3 mode For the PM3 mode. both the FRDM612 are the same. the PM3 current consumption about 0.96mA However, when entering PM4 mode, the problematic FRDM612 will become 1.19mA, while the normal FRDM is about 0.47mA Re: RW612 - PM4 current is abnormal. Hi Daniel. Sorry, JP9: 474mA should be corrected to 474uA, not mA. Also, I looked at the power tree after JP9, except for JP7 and JP5. If I want to analyze this further, can I only measure R218 and R196 to identify the power consumption sources? Would measuring the power tree of these two paths be helpful to you? I have uploaded the FRDM612 schematic in the attached file. FRDM-RW612-SCH.pdf WeiliWang_0-1758180854622.png Re: RW612 - PM4 current is abnormal. Hi,  Thank you for such detailed information. I just want to be completely sure I understand your setup. I will need to do some testing on my side.  Meanwhile, please confirm if this is a typo: "This means that I have approximately 800mA of leakage". Aren't these 800uA? You also mentioned "On DK1, measuring current through JP9, the PM4 current consumption is around 400 µA, which is as expected.". But you also mentioned "FRDM1(O.K case) JP9:474mA JP5:21uA JP7:444uA.". Is the measure on JP9 474uA instead of 474mA? Regards, Daniel. Re: RW612 - PM4 current is abnormal. Hi Daniel. Your understanding is very correct. I studied AN14464. I used three current meters to measure JP9, JP5, and JP7. The results are as follows: FRDM1(O.K case) JP9:474mA JP5:21uA JP7:444uA. FRDM2(K.O case) JP9:1.26mA JP5:21uA JP7:448uA. In K.O.'s case, I noticed that JP9 consumed 1.26mA, but JP5 and JP7 combined consumed 469uA. This means that I have approximately 800mA of leakage coming from somewhere below the JP9 node. Do you have any suggestions that I can try to troubleshoot? We're using the Ublox W10 and are experiencing this issue. We've done some small-scale production. 413 modules have a current draw between 300 and 500uA. 70 modules have a current draw between 501 and 800uA. 32 modules have a current draw between 801 and 900uA. 15 modules have a current draw between 901 and 1050uA. Re: RW612 - PM4 current is abnormal. Hi, Could you please help me confirm the following? You ran the same test using the same example on two FRDM boards. FRDM 1 shows normal current consumption, even when hot air is applied. FRDM 2 consumes about 1 mA more than FRDM 1 under normal conditions, but when hot air is applied, its current consumption drops to match that of FRDM 1. Is my understanding correct? For reference, I recommend taking a look at AN14464. Regards, Daniel Re: RW612 - PM4 current is abnormal. Was this issue ever resolved? I’m seeing similar behavior on an RW612-based module. In PM3, the total VDD current consumption is 318 µA, while in PM4 it increases to 425 µA. I measured VPA current directly and observed 877 nA in PM3 compared to 330 µA in PM4.

料金の初期化時間について NXPのエキスパートの方、こんにちは。S32K312のフィード初期化時間に問題があり、ご相談させていただきたいのですが。詳細は以下のとおりです。 プライマリとスタンバイの2つのデータストレージクラスタグループを設定しました。スタンバイはプライマリのバックアップです。合計19個のブロックが設定され、これらのブロックはプライマリとスタンバイの両方に保存されます。ソフトウェアバージョンはMcal RTD4.0.0 HF02で、バーストモードが有効になっています。 Chenxu1_0-1785460201957.png 試験方法： 電源投入時に初期化時刻が出力され（Mem_43_INFLS_Initt()、MemAcc_Initt()、Fee_Init() を呼び出した後、Fee_GetStatus() インターフェースが MEMIF_IDLE を返すまで待機）、すべてのブロックにデータが一度書き込まれます。 試験結果は以下のとおりです。 パワーアップアイテムの数 初期化時間（ミリ秒） 例示する 1 8 2 15 3 23 4 40 5 48 6 57 7 65 8 74 9 82 10 90 11 99 12 107 13 115 14 124 15 133 16 141 17 149 18 158 19 166 20 175 21 183 22 192 23 200 24 209 25 217 26 226 27 234 28 8 クラスタページング 上記のテスト結果から、各増分にかかる時間が非常に速く変化することが分かりました。そこで、初期時間を計算する式が存在するかどうか、また、その式を最適化できるかどうかをお伺いしたいと思います。 Re: 关于FEE初始化时间 こんにちは@Chenxu1 FEEドライバのドキュメントには初期化時間を計算するための公式は提供されていません。初期化時間は、保存されているデータ量、レコード数、クラスタの復旧やスワップが必要かどうかなど、FEEストレージの実際の状態によって異なります。初期化性能を向上させる主な構成パラメータはFeeDataBufferSizeであり、バッファが大きいほどFls_MainFunctionサイクルあたりより多くのデータを処理できます。詳細は「Please Fee ユーザーマニュアル」をご覧ください。より現実的な見積もりを行うには、初期化時間を、FEEを長時間使用し、複数回の書き込みサイクルを行った後の対象構成で測定する必要があります。 よろしくお願いいたします。 ルーカス Re: 关于FEE初始化时间 こんにちは、 現在、16バイトを書き込むと、次の初期化に2ミリ秒余計に時間がかかります。この時点では、ページ切り替えは発生せず、単に再初期化して16バイトを再度読み込むだけなので、2ミリ秒余計に時間がかかります。これは普通のことですか？ Re: 关于FEE初始化时间 はい、この件についてはここで何度か議論されています。例えば： https://community.nxp.com/t5/S32K/S32K312-FEE-FLS-INIT-time/m-p/2024041 よろしくお願いいたします。 ルーカス

Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor Hi, I am using the NBP8FD4ST1 pressure sensor with the S32K146 microcontroller. The CS_B/WAKE-UP pin of the sensor is connected to a GPIO pin on the microcontroller. The logic analyzer signal mapping is as follows: D0 → SCLK D1 → CS_B D3 → READY D5 → MISO D7 → MOSI During the communication sequence, when I pull the CS_B pin low to request SPI communication, the READY pin is asserted as expected. After READY goes high, I send the SPIOPS register read command (0x00E1). However, the sensor always returns 0x0000 on MISO. As a result, the firmware validation fails, and the CS_B pin is subsequently driven high to terminate the transaction. Could you please help me understand whether my SPI communication sequence is correct or if I am missing any required step, such as the wake-up sequence, dummy transfer, or SPIOPS handling described in the datasheet? I have also attached the logic analyzer screenshots for reference. Thank you in advance for your support. Best regards, Pratyusha. Pratyusha_0-1783666219816.png Pressure Sensors Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor Hi Pratyusha, Please note that NXP's MEMS Sensors business, including pressure sensors such as the NBP8FD4ST1, has been transferred to STMicroelectronics. Effective February 2, 2026, technical support, product documentation and development activities for these sensors are now handled by STM. As a result, we are unfortunately no longer able to provide technical support for the NBP8FD4ST1. I recommend that you contact STM directly through their support channels or community forum, where the sensor experts can assist you with your implementation and communication troubleshooting. BRs, Tomas Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor from your chart D0 → SCLK, there is no clock signal when you read SPIOPS? Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor @suncongjohnson Thanks for your reply. I have configured the SPI peripheral for 16-bit transfers, so I expect 16 SCLK pulses to be generated for each SPI transaction. However, when issuing the SPIOPS read command, no SCLK signal is generated on the D0 (SCLK) line. const lpspi_master_config_t lpspiCom1_MasterConfig0 = { .bitsPerSec = 1000000U, .whichPcs = LPSPI_PCS0, .pcsPolarity = LPSPI_ACTIVE_LOW, .isPcsContinuous = true, .bitcount = 16U, .lpspiSrcClk = 8000000U, .clkPhase = LPSPI_CLOCK_PHASE_1ST_EDGE, .clkPolarity = LPSPI_SCK_ACTIVE_HIGH, .lsbFirst = false, .transferType = LPSPI_USING_INTERRUPTS, .rxDMAChannel = 255, .txDMAChannel = 255, .callback = NULL, .callbackParam = NULL, };

如何将配置文件放入 S32DS 中进行版本、调试……项目 I just started with AUTOSAR and I have S32K144EVB I want to find instructions on how to use Tresos to generate config file and put it in S32DS for debug, build... Can anyone tell exactly where I should start from where? Re: How to put config file to S32DS for build, debug.... project 对于任何使用 S32DS 并试图正确设置版本和调试配置的人来说，这都是一个很有帮助的问题。查阅了一些相关资料（包括普特南法院判决书参考，引用）后，我发现配置步骤更容易遵循。关键似乎在于正确放置配置文件并确保项目设置指向该文件。如果能提供一个清晰的步骤示例，对于初学者来说就更容易理解了。 Re: How to put config file to S32DS for build, debug.... project 所得税的概念涉及对个人、公司、合伙企业和其他实体所赚取的收入进行评估和征税。 Re: How to put config file to S32DS for build, debug.... project 从现有项目文件生成新项目。构造 3. 调试是第五个。最终目的地。9……我们的 IDE 和开发环境 Eclipse 将开始加载。然后……转到“文件”>“新建”>“S32DS 应用程序项目”……导航到版本配置中的 (1) C/C++ 构建、(2) 设置和 (3) 目标处理器。 [[ ## completed ## ] Re: How to put config file to S32DS for build, debug.... project 从现有项目文件创建项目。3. 建筑物。5. 调试。6. 终端。9……它将开始加载我们将用于编写和测试代码的Eclipse环境和IDE。然后，它会……文件>新建>S32DS应用程序项目……在版本设置中，转到（1）C/C++版本，（2）设置，（3）目标处理器

How to put config file to S32DS for build, debug.... project I just started with AUTOSAR and I have S32K144EVB I want to find instructions on how to use Tresos to generate config file and put it in S32DS for debug, build... Can anyone tell exactly where I should start from where? Re: How to put config file to S32DS for build, debug.... project This is a helpful question for anyone working with S32DS and trying to get the build and debug setup right. I found the configuration steps easier to follow after checking a few related resources including Putnam Court Judgments for reference. The key seems to be placing the config file correctly and ensuring the project settings point to it. A clear step-by-step example would make this even easier for beginners to follow. Re: How to put config file to S32DS for build, debug.... project The concept of income tax involves the assessment and taxation of income earned by individuals to get help, corporations, partnerships, and other entities. Re: How to put config file to S32DS for build, debug.... project Generation of a new project from an existing project file. Construction 3. Debugging is the fifth. A final destination. 9 ... Our IDE and development environment, Eclipse, will begin to load. This will then... Go to File > New >S32DS Application Project... Navigate to (1) C/C++ Build, (2) Settings, and (3) Target Processor in the build's configuration. Re: How to put config file to S32DS for build, debug.... project Creating a project from existing project file. 3. Building. 5. Debugging. 6. Terminal. 9 ... It will begin to load the eclipse environment and IDE we will be using to write and test code. It will then ... File > New >S32DS Application Project ... In the build settings, go to (1) C/C++ Build, (2) Settings, (3) Target Processor

关于FEE初始化时间 Hi，NXP专家，我遇到一个S32K312 FEE初始化的时间想咨询一下，描述如下： 我配置了2个fee存储的clustergroup，一个主区，一个备区，备区是主区的备份，共配置了19个block，block同时存储在主区和备区中。软件版本Mcal RTD4.0.0 HF02，使能了Burst mode。 Chenxu1_0-1785460201957.png 测试方法： 上电时打印初始化时间（调用Mem_43_INFLS_Initt()，MemAcc_Initt()，Fee_Init()后等待Fee_GetStatus()接口返回MEMIF_IDLE），所有block写入一次数据 测试结果如下： 上电次数 初始化时间（ms） 说明 1 8 2 15 3 23 4 40 5 48 6 57 7 65 8 74 9 82 10 90 11 99 12 107 13 115 14 124 15 133 16 141 17 149 18 158 19 166 20 175 21 183 22 192 23 200 24 209 25 217 26 226 27 234 28 8 Cluster换页 根据以上实测发现每次递增的时间变化很快，所以想咨询一下有没有初始胡时间的计算公式、是否可以优化？ Re: 关于FEE初始化时间 嗨@Chenxu1 FEE驱动程序文档中没有提供计算初始化时间的公式。初始化时间取决于 FEE 存储的实际状态，例如存储的数据量、记录数，以及是否需要任何集群恢复或交换。能够提高初始化性能的主要配置参数是 FeeDataBufferSize，因为更大的缓冲区允许每个 Fls_MainFunction 周期处理更多的数据。详情请参阅收费用户手册。为了进行实际的估计，应该在长时间使用 FEE 和多次写入周期后，在目标配置上测量初始化时间。 此致， Lukas Re: 关于FEE初始化时间 是的，这个问题之前已经讨论过好几次了。例如： https://community.nxp.com/t5/S32K/S32K312-FEE-FLS-INIT-time/m-p/2024041 此致， Lukas Re: 关于FEE初始化时间 你好， 目前，写入 16 字节会导致下次初始化时间延长 2 毫秒。此时不涉及页面切换——只是重新初始化并再次读取 16 个字节，这会增加 2 毫秒。这正常吗？

MX8-DSI-OLED1 Display part No and sequence. Hi Team, We are planning to use MX8-DSI-OLED1 accessory in our custom board as well. Could you please share the display part no and if there is any power sequence to be maintained. Re: MX8-DSI-OLED1 Display part No and sequence. Hi Team, Any updates on this? Re: MX8-DSI-OLED1 Display part No and sequence. Hello, Could you share what kind of information you are looking for? The display for the MX8-DSI-OLED1A (raydium rm67199) is a MIPI-DSI OLED display with touch support. Following are some key features: • 5.49" FHD (1080p@60fps) AMOLED display • 16.7 M (RGB*8bits) display color • Touch screen • 4-lane MIPI-DSI interface for display • I2C interface for touch and control Also, note that for this part there is not much information we can share. Best regards/Saludos, Aldo. Re: MX8-DSI-OLED1 Display part No and sequence. Hi @AldoG I would like to understand if there is any power up sequence to be followed for these rails. VDD_1V8 VEXT_3V3 VDD_5V

圧力センサのSPI通信に関する支援NBP8FD4ST1必要 こんにちは、 S32K146マイクロコントローラでNBP8FD4ST1圧力センサーを使っています。センサーの CS_B/WAKE-UP ピンはマイクロコントローラのGPIOピンに接続されています。 ロジックアナライザの信号マッピングは以下のとおりです。 D0 → SCLK D1 → CS_B D3 → 準備完了 D5 → MISO D7 → MOSI 通信シーケンス中に、 CS_BピンをローレベルにプルダウンしてSPI通信を要求すると、 READYピンは期待どおりにアサートされます。READYがハイになった後、 SPIOPSレジスタ読み取りコマンド(0x00E1)を送信します。しかし、MISOではセンサーは常に 0x0000 戻ってしまいます。その結果、ファームウェアの検証が失敗し、CS_Bピンがハイレベルに駆動されてトランザクションが終了します。 私のSPI通信シーケンスが正しいのか、それともデータシートに記載されているウェイクアップシーケンス、ダミー転送、SPIOPS処理など、必要なステップを見落としているのか教えていただけますか? 参考までに、ロジックアナライザのスクリーンショットも添付しました。 サポートにあらかじめ感謝いたします。 よろしくお願いします、 プラチューシャ。 Pratyusha_0-1783666219816.png 圧力センサ Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor こんにちは、プラティウシャさん。 なお、NXPのMEMSセンサ事業、NBP8FD4ST1などの圧力センサはSTMicroelectronicsに移管されました。2026年2月2日付で、これらのセンサの技術サポート、製品ドキュメント、開発活動はSTMが担当しています。その結果、残念ながらNBP8FD4ST1の技術サポートは提供できません。 サポートチャネルやコミュニティフォーラムを通じて直接STMに連絡することをお勧めします。センサの専門家が実装やコミュニケーションのトラブルシューティングをサポートいたします。 BRs、トーマス Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor あなたのチャートのD0→SCLKから、SPIOPSを読み取る際にクロック信号がないということでしょうか？ Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor @suncongjohnsonご返信ありがとうございます。SPIペリフェラルは16ビット転送に設定しているので、SPIトランザクションごとに16回のSCLKパルスが生成されると予想しています。しかし、SPIOPSの読み取りコマンドを発行しても、D0（SCLK）ラインにはSCLK信号が生成されません。 const lpspi_master_config_t lpspiCom1_MasterConfig0 = { .bitsPerSec= 1000000U、 .whichPcs= LPSPI_PCS0、 .pcs極性= LPSPI_ACTIVE_LOW、 .isPcsContinuous= 真、 .bitcount= 16U、 .lpspiSrcClk= 8000000U、 .clkPhase= LPSPI_CLOCK_PHASE_1ST_EDGE、 .clkPolarity= LPSPI_SCK_ACTIVE_HIGH、 .lsbFirst= 偽、 .transferType= LPSPI_USING_INTERRUPTS、 .rxDMAChannel= 255、 .txDMAChannel= 255、 。折り返し電話= NULL、 .callbackParam= NULL、 };

i.MXRT685S：通过 HS SPI 总线从外部闪存启动 我有一个外部 SPI 或非 闪存设备，通过 HS SPI 总线接口（Flexcomm 14）连接到 RT685s。我想从这个闪存设备启动；但是，我了解到只有 FlexSPI 启动、SD 启动和 eMMC 启动这三种主启动选项。是否可以使用高速 SPI 总线（Flexcomm 14）从该外部闪存启动？如果是这样，我需要遵循哪些要求/设置步骤才能执行此操作？ Re: i.MXRT685S: Boot from external flash via HS SPI bus 以下是一些关于NOR启动的应用笔记，供您参考。 AN12751 如何从 QSPI Flash 启用恢复启动 AN12773 如何从串行 或非 Flash 启用主启动 Re: i.MXRT685S: Boot from external flash via HS SPI bus 嗨@lgibarra9 ， 使用 FC14 的高速 SPI 总线无法从外部 SPI 或非 Flash 启动。除了运行时 SPI 通信外，该总线还可以在 MCU 处于 ISP 模式时下载图像。但是，对于从外部闪存进行正常启动操作而言，高速 SPI 总线不是一个选项，因此您的 SPI NOR 闪存应该连接到 FlexSPI 总线。 BR， 埃德温。

ビルド、デバッグ、プロジェクトのためにS32DSに設定ファイルを配置する方法 I just started with AUTOSAR and I have S32K144EVB I want to find instructions on how to use Tresos to generate config file and put it in S32DS for debug, build... Can anyone tell exactly where I should start from where? Re: How to put config file to S32DS for build, debug.... project これは、S32DS を扱っていて、ビルドとデバッグの設定を正しく行おうとしている人にとって、非常に役立つ質問です。参考資料としてパットナム裁判判例集などいくつかの関連資料を確認したところ、設定手順がより分かりやすくなった。重要なのは、設定ファイルを正しい場所に配置し、プロジェクト設定がそのファイルを指していることを確認することのようです。明確な手順を示す例があれば、初心者でもさらに理解しやすくなるでしょう。 Re: How to put config file to S32DS for build, debug.... project 所得税の概念は、個人、法人、パートナーシップ、その他の事業体が得た所得を評価し、課税することを含みます。 Re: How to put config file to S32DS for build, debug.... project 既存のプロジェクトファイルから新しいプロジェクトを生成する。構築 3. デバッグは 5 番目です。最終目的地。9 ...私たちのIDEsと開発環境であるEclipseが読み込みを開始します。これ なら...新しい>S32DSアプリケーションプロジェクト>ファイルへ移動...ビルドの設定で(1) C/C++ビルド、(2) 設定、(3) ターゲットプロセッサへ移動します。 Re: How to put config file to S32DS for build, debug.... project 既存のプロジェクトファイルから新しいプロジェクトを作成します。3. ビルディング。5. デバッグ。6. ターミナル。9 ...Eclipse環境とIDEの読み込みが始まり、コードを書 いたりテストしたりします。そうすれば...ファイル>新>S32DSアプリケーションプロジェクト...ビルド設定で、(1) C/C++ビルド、(2) 設定、(3) ターゲットプロセッサに進みます

RW612 - PM4 电流异常。 专家们好 我们最近在一些量产产品中使用了 u-blox W10 模块。不过，我们发现不同模块的 PM4 电流消耗量差别很大，从约 300 µA 到 1 mA 不等。 为了进一步调查，我使用两个 FRDM-RW612 开发套件进行了测试，没有进行任何返工或修改，并使用恩智浦 SDK v25.6.0 中的电源管理器测试（裸机）示例应用程序对两个套件进行了编程。 在 DK1 上，通过 JP9 测量电流，PM4 的电流消耗约为 400 µA，符合预期。 在 DK2 上，在完全相同的测试条件下，PM4 的电流消耗约为 1 mA。我重复了 120 次测试，结果始终如一。 有趣的是，当我给 DK2 吹热风时，PM4 电流下降到 ~400 µA（正常值）。但冷却几分钟后，电流又回升到 ~1 mA。再次注入热空气会使电流暂时回落。 请问我该如何分析这个问题？我使用的是官方开发工具包和未修改的示例代码，可以可靠地重现该问题。 Re: RW612 - PM4 current is abnormal. 嗨，丹尼尔 这款 K.O. 板上的黄色电缆用于测量 VPA 的电流，电阻为 0 欧姆 (R218)。 WeiliWang_0-1758787079290.png 此外，我还发送了一条私人信息。 你能检查一下吗？ Re: RW612 - PM4 current is abnormal. 您好， 我使用 2 个 FRDM-RW612 板测试了 25.09 SDK 的电源管理器测试。 尽管如此，我还是得到了预期的结果。 DanielRuvalcaba_4-1758773852825.png 测量在 JP9 上进行。 你能告诉我你的 KO FRDM 板上的电缆是干什么用的？ 此致， 丹尼尔 Re: RW612 - PM4 current is abnormal. 嗨，丹尼尔 用于测量 VPA 电流的 K.O. 板黄色电缆。 我去掉了用于测量 VPA 电流的 R218 WeiliWang_0-1758687668677.png Re: RW612 - PM4 current is abnormal. 您好， 抱歉耽搁了。 目前我还没有办法测量电流消耗，但明天应该可以做到。请给我一些时间来收集测量数据。 顺便问一下，您能告诉我 KO FRDM 中的电缆是做什么用的吗？ 此致， 丹尼尔 Re: RW612 - PM4 current is abnormal. 嗨，丹尼尔 下面是另一个更新： 我们使用了 uBlox IRIS-W106-30B 模块。 我们打开屏蔽罩，测量了 ublox IRIS-W106-30B 模块在特定测试条件下的漏电流情况（K.O.情况）。我们发现 VPA 处的漏电流为 657 微安。 因此，根据实验结果，FRDM612 和 ublox IRIS-W106-30B 的漏电流源似乎是从 VPA 吸收的电流。 Re: RW612 - PM4 current is abnormal. 嗨，丹尼尔 我的 FRDM 照片如下： WeiliWang_0-1758328990924.png WeiliWang_1-1758329028621.png WeiliWang_2-1758329081576.png WeiliWang_3-1758329134480.png Re: RW612 - PM4 current is abnormal. 您好， 您能分享一下 FRDM 的照片吗？ 我们正在检查。请给我一些时间，等我有了最新进展再与大家分享。 此致， 丹尼尔 Re: RW612 - PM4 current is abnormal. 嗨，丹尼尔 我已经确定了 700µA"间隙电流" ；测量结果显示，该电流来自 VPA 引脚。这个问题可以通过软件更新或补丁解决吗？我们已经从 U-blox 购买了 1560 台设备，我们的客户即将在六个不同的国家进行射频认证。我想知道这个问题能否得到解决。 有可能用补丁解决这个问题吗？ WeiliWang_0-1758251280118.png Re: RW612 - PM4 current is abnormal. 嗨，丹尼尔 我还测试了 PM3 模式 对于 PM3 模式。 FRDM612 都是一样的。 PM3 的电流消耗约为 0.96mA 然而，当进入 PM4 模式时，有问题的 FRDM612 将变为 1.19mA，而正常 FRDM 约为 0.47mA Re: RW612 - PM4 current is abnormal. 嗨，丹尼尔 对不起，JP9：474mA 应更正为 474uA，而不是 mA。 此外，我还查看了 JP9 之后的电源树，除了 JP7 和 JP5。 如果我想进一步分析，是否可以只测量 R218 和 R196 来确定功耗源？测量这两条路径的功率树对您有帮助吗？ 我已在附件中上传了 FRDM612 原理图。 FRDM-RW612-SCH.pdf WeiliWang_0-1758180854622.png Re: RW612 - PM4 current is abnormal. 你好、 感谢您提供如此详细的信息。我只想确定我完全理解了你的设置。 我这边需要做一些测试。 同时，请确认这是否是错字：" 这意味着我的漏电流约为 800mA "。这些不是800uA 吗？ 您还提到"在 DK1 上，通过 JP9 测量电流，PM4 的电流消耗约为400 µA，符合预期。" 。但您还提到"FRDM1（正常情况下），JP9:474mA，JP5:21uA，JP7:444uA。" 。JP9 上的测量值是 474uA 而不是 474mA？ 此致， 丹尼尔 Re: RW612 - PM4 current is abnormal. 嗨，丹尼尔 你的理解非常正确。 我研究过 AN14464。 我用三个电流表测量了 JP9、JP5 和 JP7。 结果如下 FRDM1（正常情况下） JP9:474mA JP5:21uA JP7:444uA。 FRDM2（K.O 外壳） JP9:1.26mAJP5:21uA JP7:448uA. 在 K.O. 的案例中，我注意到 JP9 消耗了 1.26mA 电流，但 JP5 和 JP7 加起来消耗了 469uA 电流。这意味着我有大约800mA的漏电流来自JP9节点下方的某个地方。 您有什么建议可以让我尝试排除故障吗？ 我们使用的是 Ublox W10，也遇到了这个问题。 我们已经进行了一些小规模生产。 413 模块的电流消耗在 300 至 500uA 之间。 70 个模块的电流消耗在 501 至 800uA 之间。 32 个模块的电流消耗在 801 至 900uA 之间。 15 个模块的电流消耗在 901 至 1050uA 之间。 Re: RW612 - PM4 current is abnormal. 您好， 能否请您帮我确认以下内容？ 您在两个 FRDM 板上使用相同的示例进行了相同的测试。 FRDM 1 显示电流消耗正常，甚至在热空气作用下也是如此。 在正常情况下，FRDM 2 比 FRDM 1 多消耗约 1 mA 电流，但当使用热空气时，其电流消耗会下降到与 FRDM 1 相当。 我的理解正确吗？ 作为参考，我建议看看 AN14464。 致： Daniel Re: RW612 - PM4 current is abnormal. 这个问题最终解决了吗？ 我在基于 RW612 的模块上也看到了类似的情况。在 PM3 中，VDD 总电流消耗为 318 µA，而在 PM4 中，VDD 总电流消耗增加到 425 µA。我直接测量了VPA电流，发现PM3中的VPA电流为877 nA，而PM4中的VPA电流为330 µA。

MX8-DSI-OLED1 ディスプレイの部品番号とシーケンス。 こんにちは、チームのみなさん。 カスタムボードにはMX8-DSI-OLED1アクセサリーも使用する予定です。 ディスプレイの部品番号と、維持すべき電源順序があれば教えていただけますか? Re: MX8-DSI-OLED1 Display part No and sequence. こんにちは、 どのような情報をお探しですか? MX8-DSI-OLED1A(raydium rm67199)のディスプレイは、タッチ対応のMIPI-DSI OLEDディスプレイです。以下は主な特徴です: • 5.49インチFHD(1080p@60fps)AMOLEDディスプレイ • 16.7 M(RGB*8ビット)表示色 ・タッチスクリーン • 表示用の4レーンMIPI-DSIインターフェース ・タッチおよび制御のためのI2Cインターフェース また、この部分については共有できる情報があまり多くないことにご注意ください。 よろしくお願いいたします。 アルド。 Re: MX8-DSI-OLED1 Display part No and sequence. チームの皆さん、こんにちは。 この件について何か進展はありますか？ Re: MX8-DSI-OLED1 Display part No and sequence. こんにちは、 @AldoGさん これらのレールに電源を入れる際の順序があるかどうかを知りたいです。 VDD_1V8 VEXT_3V3 VDD_5V

i.MXRT685S: HS SPIバス経由で外部フラッシュからブート 私はRT685sのHS SPIバスインターフェース(Flexcomm 14)に接続した外部SPI NORフラッシュデバイスを使っています。このフラッシュデバイスから起動したいのですが、マスターブートのオプションはFlexSPIブート、SDブート、eMMCブートしかないと読みました。高速SPIバス（Flexcomm 14）を使用して、この外部フラッシュメモリから起動することは可能ですか？もしSOなら、実行するためにどのような要件やセットアップ手順に従うべきでしょうか? Re: i.MXRT685S: Boot from external flash via HS SPI bus 以下はNORブート用の参考となるアプリケーションノートです AN12751 QSPIフラッシュからのリカバリブートを有効にする方法 AN12773 シリアルNORフラッシュからのマスターブートを有効にする方法 Re: i.MXRT685S: Boot from external flash via HS SPI bus こんにちは、@lgibarra9 さん。 FC14の高速SPIバスを使用して、外部SPI NORフラッシュからブートすることはできません。このバスは(実行時SPI通信以外にも)MCUがISPモードの際にイメージをダウンロードするために使用できます。しかし、外部フラッシュからの通常の起動動作では高速SPIバスは使えないため、SPI NORフラッシュはFlexSPIバスにコネクテッドすべきです。 BR、 エドウィン。

S32K311 LCUの立ち上がり/立ち下がりフィルタのデッドタイムが、2µsから1µsに短縮されることがあります。 こんにちは、NXP チームの皆様、 私はRTD 5.0を搭載したS32K311を使用しています。 PWM信号はeMIOS0によって生成され、 LCU0の出力に直接送られます。 eMIOS0_CH0 -> LCU0_OUT0 eMIOS0_CH1 -> LCU0_OUT1 eMIOS0_CH2 -> LCU0_OUT2 eMIOS0_CH3 -> LCU0_OUT3 eMIOS0_CH4 -> LCU0_OUT4 eMIOS0_CH5 -> LCU0_OUT5   LCUは、立ち上がり/立ち下がりフィルタを使用してデッドタイムを挿入するように構成されています。   設定 MCU:S32K311 RTDバージョン：5.0 PWMソース: eMIOS0 デッドタイム生成：LCU上昇/下降フィルタ ハイサイドチャネルのライズフィルター = 192 ローサイドチャネルのフォールフィルター = 192 設定デッドタイム = 2 µs 観察された行動 ほとんどのスイッチングイベントは、予想 される2μsのデッドタイムを生み出します。 しかし、時折、一方の遷移（立ち上がりエッジまたは立ち下がりエッジ）のデッドタイムが、2 µs ではなく約1 µsしかない場合があります。これは、PWM周波数とデューティサイクルが変化しない状態で断続的に発生します。 添付のロジックアナライザのキャプチャ画像に、この動作が示されています。 質問 LCUの上昇/下降フィルターを使用した場合、このような変動は想定されるものですか？ eMIOSの出力とLCUフィルタの間には、同期に関する要件はありますか？ LCUフィルターは内部同期やクロックドメイン交差によってプログラム遅延を時折短縮することはありますか? S32K311の立ち上がり/立ち下がりフィルタに関して、既知の制限事項や不具合はありますか？ 何かアドバイスをいただければ幸いです。 よろしくお願いします。 Re: S32K311 LCU Rise/Fall Filter Deadtime Occasionally Reduced from 2 µs to 1 µs こんにちは、 Esakkiさん。 1. あなたの値 192 = 2 µs  LCUフィルターのティック値は約： 2us / 192 = 10.4167 ns -> 1/ 10.4167 ns = 96MHz、 有効なLCU/周辺クロックやプリスケーラが変化したり、想定と異なるクロックが選択された場合、実際の遅延は変わります。 2. オシロスコープを用いてテストする方が正確で、波形は外部静電容量リアクタンスに関連しています。大きな静電容量リアクタンスも波形の不安定性を引き起こすことがあります。