about imx6q ddr stresstest I am running a DDR stress test on the i.mX6Q and need to know which Excel file to use. I have obtained `MX6Q_SabreSD_DDR3_register_programming_aid_v2.5.xlsx`; does this appear to be the correct file? I am currently using Samsung K4B4G16 256M×16 chips (4 chips totaling 2GB), but the test fails to complete, returning the error "No chip select is enabled." How can I resolve this issue? Thanks. Re: about imx6q ddr stresstest Hi @GavinChen  This RPA table is right for i.MX6Q. please share your RPA able. B.R

RT685 DSPイメージは、MacOS上で新たに組み込まれたZephyr sysbuildの代わりにキャッシュバイナリを使用しています プラットフォーム:MacOS 15.6.1 (24G90) VS Code(バージョン:1.112.0)（ユニバーサル） MCUXpresso for VS Code: 26.8.29 Zephyr toolchain: zephyr-sdk-1.0.1, zsdk nxp-v4.4.1.1 用途: amp_blinkyをZephyr-freestandingとしてインポート 基板: MIMXRT685-EVK 説明： 私はMacOSで開発環境を設定していますが、同じ手順はLinuxマシンでも問題なく動作していました。ビルドとフラッシュは MCUXpressoで重大な警告やエラーを出さなかったが、ARMコアとDSPコアの両方でアプリケーションは正常に動作していた。その後、remote/srcとremote/prj.confのコードを編集し、クリーンビルド後にフラッシュしました。しかし、DSPコアは編集前に前の画像を実行していました。 以下に、興味深い行動例をいくつか示します。 Armコアコードの編集も試みましたが、その変更は成功裏に適用されました。 DSPコアコードの変更は「作業なし」と表示される代わりに、非純粋なビルドを引き起こすことがあります。 cmakeでCCACHEを無効にすると問題が解決するようです。 今のところ、コンパイラがsysbuildを実行する際にDSPイメージの変更を無視し、キャッシュされたバイナリを使っているというCAHCE関連の問題のように思えます。これは再構築されているにもかかわらずです。おそらくnxp_zephyr/zephyr/samples/boards/nxp/adsp/rtxxx/common/src/dspimgsが原因です。Sは更新されていません。また、Linuxマシンでは気づかなかったので、MacOSだけの問題かもしれません。 これは既知の問題ですか？CCACHEを無効にする以外の、より洗練された解決策はありますか？ よろしくお願いいたします。 ユエ ゼファー・オス・エッジ  i.MX RT600

1080p RTSP IPカメラ用のNXP i.MX プロセッサの推奨 こんにちは、皆さん 1080p RTSP IPカメラストリームを処理できる、最も安価なNXP i.MX プロセッサーを誰か教えてもらえますか? 私の要望は以下の通りです。 1つのRTSP IPカメラ入力 2 1080p解像度 3 約25～30 FPS 4 この問題を安定して扱える、最も低コストで i.MX プロセッサ/ボードを探しています 主な目的は、可能な限り低いハードウェアコストで1080pのRTSPカメラストリームを受信し、処理/表示することです。 もし同じようなケースで低コストの i.MX プロセッサを試したことがある方がいれば、ぜひおすすめや体験を共有してください。 よろしくお願いします！ Re: Recommendation for NXP i.MX Processor for 1080p RTSP IP Camera こんにちは、 IPカメラを使った純粋な受信・表示アプリケーションとしては、i.MX8MMを検討してください。なぜなら、1080p60デコード対応の専用ハードウェアVPUが含まれているからです。 よろしくお願いいたします。

MCXN947 DLL auto-adjusted function not working Hello, I'm using the MCXN947 via FlexSPI with an OctalRAM (IS66WVO32M8DALL-200BLI). The FlexSPI root clock is supplied at 150 MHz via PLL1, and since the RAM operates in DDR mode, I have an output clock rate of 75 MHz. The `flexspi_device_config_t` has the following parameters: flexspi_device_config_t psram_config = { .flexspiRootClk = 150000000U, .isSck2Enabled = false, .flashSize = OCTALRAM_ISSI_SIZE, .CSIntervalUnit = kFLEXSPI_CsIntervalUnit1SckCycle, .CSInterval = 2, .CSHoldTime = 2, .CSSetupTime = 2, .dataValidTime = 2, .columnspace = 4, .enableWordAddress = false, .AWRSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_WRITEDATA, .AWRSeqNumber = 1, .ARDSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_READDATA, .ARDSeqNumber = 1, .AHBWriteWaitUnit = kFLEXSPI_AhbWriteWaitUnit2AhbCycle, .AHBWriteWaitInterval = 0, .enableWriteMask = true, }; To initialize FlexSpi, I use the SDK FLEXSPI_DRIVER, version 2.6.0. When I configure the delay cells using the auto-adjusted function (as described in the manual under section 10.3.15.6, “DLL configuration for sampling”) with the following values: • SLVDLYTARGET=0x0F (divider 16/32 * root_clock = 3.33 ns) • REFPHASEGAP=0x02 • DLLEN=0x01 • OVRDEN=0x01 After waiting for the ASLVLOCK and AREFLOCK lock bits, I get 0x01 for ASLVSEL and 0x00 for AREFSEL. Consequently, the RAM's read and write functions do not work, since the set delay time is approximately 120 ps! /* Configure DLL. */ configValue = FLEXSPI_CalculateDll(base, config); base->DLLCR[index] = configValue; /* DLL neu kalibrieren */ base->DLLCR[0] |= FLEXSPI_DLLCR_DLLRESET_MASK; base->DLLCR[0] &= ~FLEXSPI_DLLCR_DLLRESET_MASK; /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Lock abwarten */ while ((base->STS2 & (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) != (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) { } SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); Even if I use different values for SLVDLYTARGET, the output of ASLVLOCK and AREFLOCK does not change. However, if I set the delay time to a fixed value using the registers OVRDEN=0x01 and OVRDVAL=0x1b (corresponding to a delay time of approximately 3.36 ns), reading from and writing to RAM works without any problems. However, since the root clock is greater than 100 MHz, NXP recommends using the DLL's auto-adjustment feature. Unfortunately, it doesn't seem to be able to determine the correct delay time! Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Core and Memory MCXN

关于 imx6q DDR 压力测试 我正在对 i.mX6Q 进行 DDR 压力测试，需要知道应该使用哪个 Excel 文件。 我已获取到 `MX6Q_SabreSD_DDR3_register_programming_aid_v2.5.xlsx` 文件；请问这是否是正确的文件？ 我目前使用的是三星 K4B4G16 256M×16 芯片（4 颗芯片共 2GB），但测试未能完成，并返回错误“未启用芯片选择”。 我该如何解决这个问题？ 谢谢。 Re: about imx6q ddr stresstest 嗨@GavinChen 此 RPA 表适用于 i.MX6Q。 请分享您的RPA能力。 B.R

Migrating custom model from S32K3xx MBDT 1.5.0 to 1.8.0, Hardware Settings error Hi NXP Support Team, We need your assistance migrating an existing Simulink model from Model-Based Design Toolbox for S32K3xx version 1.5.0 to version 1.8.0. Our model incorporates our custom IOC toolbox and previously worked with MBDT 1.5.0. After upgrading to 1.8.0 while using MATLAB/Simulink R2024b, our engineer encounters an error when opening the model’s Hardware Settings. The steps to reproduce are: 1. Install MBDT for S32K3xx version 1.8.0. 2. Open our existing demo model, IOC_DemoPrj.slx. 3. Select HARDWARE → Hardware Settings. The Configuration Parameters dialog fails to open and displays this error: Output argument "out" (and possibly others) not assigned a value in the execution with "mbd_s32k3.nxp.target.get_target_memory_entries" function. The dialog also references getTargetHardwareDetailWidgets.p. Please see the attached screenshot for the full message. We contacted MathWorks Technical Support under case #09014041. They advised us to consult NXP because the MBDT add-on is developed by NXP; the root cause has not yet been confirmed. Could you please help us with the following? 1. Migration procedure: What is the supported process for migrating a model from MBDT 1.5.0 to 1.8.0? Is a migration guide or conversion utility available, and can we upgrade directly? 2. Error diagnosis: Is this get_target_memory_entries error a known issue? Are there any applicable patches or workarounds? 3. Existing configuration: Does the model’s hardware, target memory, or peripheral configuration need conversion or regeneration? If so, how should we perform this when Hardware Settings cannot open? 4. Custom IOC toolbox: Which changes between these versions could require updates to our custom blocks, model callbacks, or build integration? Please identify the relevant interfaces and recommended changes. 5. Diagnostic information: What model files, configuration files, logs, and installation details would you need to determine whether this is a migration, installation/path, or custom toolbox integration issue? Our goal is to retain the existing IOC functionality and make the changes necessary to configure, build, and run the model successfully with MBDT 1.8.0. Thanks.

MCXW727CMFTBT — 工場出荷時のブランク状態のデバイスでSWD接続が失敗する（2台、同一の不具合） MCXW727CMFTBTサンプル(2ユニット、カスタムボード)にSWDデバッグ接続を確立することはできませんが、まったく同じプローブ/ケーブル/セットアップが同じ回路図、同じBOMのMCXW716Cに直接接続されます(回路図も同じBOM、MCUが異なるだけです)。 部品: MCXW727CMFTBT、HVQFN-48、日付コード9D2604、ロットPF2R73.00 ボード: カスタムPCB(10ピンCortex Debug SWD、ISPボタンなし)、工場出荷時の空白/未プログラム SDK: MCUXpresso SDK 26.06.00 — アプリケーションビルド/リンクは正常、故障はデバッグ接続段階のみです 兆候 NXP LinkServer 25.12.83と純正SEGGER J-Link Plusの両方で全く同じように失敗します。   LinkServer: Error: Wire Ack Fault - target connected? Ed:02: Failed on connect: Ee(42). No connection to chip's debug port J-Link: device MCXW727C_M33_0 / connect (VTref correctly read at 3.025V) ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF LinkServer 独自の MCXW7XX 事前接続スクリプト (LS_preconnect_MCXW7XX.scp) は自動的にデバッグセッション要求を発行しますが、それでも失敗します。nxpdebugmbox (SPSDK) のマニュアルの「デバッグセッションの開始」も、同じ WIRE ACK FAULT で失敗します。 既に除外済み プローブ／ケーブル／アダプター：動作確認済み（同じ構成でMCXW716Cにも問題なく接続できます） MCUでのVDD_IO / P3V3:~3.3V、正解 SWDIO/SWDCLKの導通：良好 VDD_CORE（内部LDO）：1.065V、範囲内 RESET_b は、ケーブルが抜かれた状態で、内部プルアップの約 3.3V (Ref.) の代わりに0Vを読み取ります。マニュアル§22.3.1）— 両方のユニットで 接続試行中にRESET_bを外部から3.3Vに強制的に設定（VTrefは3.025Vと正しく読み取られた）：変化なし、依然として「Wrong DM-AP IDCODE 0xFFFFFFFF」で失敗します。 2台の別々の物理ユニット／2枚の別々の基板で再現可能 関連スレッド 全く同じエラー (DM-AP IDCODE 0xFFFFFFFF が間違っています) が、同じデバイス名で報告されていますが、シナリオが異なります (ボードは動作していましたが、消去/再プログラム サイクル後に壊れました)。FRDM -MCXW72 は接続されなくなりました。当社のユニットは一度もフラッシュされたことがないので、そのThreadが示すようにNBU/コア状態へのリンクがあるなら、顧客が一度も触ったことのないユニットにも影響が出るようです。 質問 初期生産版MCXW727CMFTBT（ロットPF2R73.00）において、標準のデバッグメールボックス手順以外で、空のデバイスへのSWDをブロックするような既知のエラー、ブート構成要件、またはデフォルトのライフサイクル状態はありますか？ 両方のユニットで、RESET_bが静止時に0Vを読み取っている（内部プルアップに関する規定に反する）— このロットの製造上の問題か、それともPOR時にこのピンを駆動する別の要因が想定されているのか？ このケースでUARTベースのISPを必要としない推奨の復旧手順はありますか?(うちのボードにはUSB-UARTブリッジが搭載されていません) ご要望があれば、完全なログ、オシロスコープのキャプチャデータ、その他役立つ情報を提供いたします。 プロトコル：BLE→コネクティビティ プロトコル：Thread Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 迅速なご対応ありがとうございます！ 念のため申し上げますが、私たちは両方のプローブをそれぞれ適切なツールを使ってテストしました。LinkServerとJ-Linkプローブを混用したわけではありません。 NXP MCU-Link Proは LinkServer 25.12.83経由でアクセス可能です。MCUXpresso for VS Codeのデバッグ/フラッシュ統合(LinkServerのgdbserver/flashプログラマーを内部で起動します)を通じて。これが私たちの普段の日常的な作業環境です。 結果:ワイヤーアクトリック故障 - ターゲット接続?/ Ed:02: 接続に失敗しました: Ee(42)。LinkServerがMCXW7XX固有の事前接続スクリプト（LS_preconnect_MCXW7XX.scp、デバッグセッション要求を発行）を自動的に実行する場合も含め、チップのデバッグポートに接続できません。 別の本物の SEGGER J-Link Plus (ファームウェアV11.00)+ J-Link アダプターCortexM(20ピン→10ピン0.05インチ)が、 J-Link Commander V9.74 経由で直接アクセスできます(LinkServer経由ではありません)。 結果: エラー: 接続時に誤った DM-AP IDCODE が検出されました: 0xFFFFFFFF、VTref は 3.025 V で正しく読み取られました。 この2回目のテストは、LinkServerやMCU-Link特有の問題を除外するために実施しました。このまさに同じJ-Link Plus+アダプター+ケーブル+ラボ電源の組み合わせで、ターゲットボードだけをMCXW716Cバリアント(同じPCBでMCUが違います)に交換した場合、 J-Link Commanderは正常に接続し、Cortex-M33コアを識別 します。つまり、プローブ、ケーブル、アダプター、ツールが正常に動作していることが確認されます。故障はMCXW727C部品/基板に特有のようです。 J-FlashやLinkFlashはまだ試していません。試したのはJ-Link Commander（接続）とLinkServerに内蔵されている「デバッグ」および「復元」フラッシュプログラマーモードのみです。もし問題をさらに絞り込むのに役立つのであれば、これらのどちらかを試してみたいと思います。 他に有用な情報やログがあればお知らせください。 よろしくお願いいたします！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 @Rwaka さん。お元気でお過ごしでしょうか。 観察している挙動をよりよく理解するために、各CASEで外部のJ-Linkデバッガを使っているか確認していただけますか?それともMCU-Link Proでも試しましたか? さらに、SWD経由でアクセスするためにどのツール(LinkFlash、J-Flash、J-Link Commander)を使用しているかも教えてください。LinkserverはNXPデバッグプローブ(例:Σ30)のGDBサーバーを起動・管理するためのユーティリティです。したがって、J-LinkプローブはLinkserverに検出されないことが予想されます。J-Link Plusプローブは、J-Link Commander/J-Flashツールと連携してのみ検出され、使用可能です。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 @Rwaka さん。追加情報を提供していただきありがとうございます。 Reset_b信号が0Vを読み取っているとおっしゃっていましたが、これはデバイスが常にリセット状態にあることを意味します。以上のことから、観察された行動をさらに分析するのに役立ついくつかの質問をしたいと思います。 MCUのPTD0/RESET_bピンに接続されたハードウェアや回路はありますか?それは浮いていますか？ VDD_IO_Dレールは正しい電圧を測定していますか？この電源領域はリセットシステムに電圧を供給するためである。電源管理ハードウェアの推奨事項については 、AN14742 を参照してください。 RESET_bピンの抵抗値を測定できますか？もしそうなら、測定値を教えてください。 外部から強制リセットを行った際、外部電圧をリセットピンに直接接続しましたか？ ご依頼いただいた情報をお知らせください。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 @RomanVR さん、 サポートありがとうございます。以下は、当社のハードウェア構成に関する寸法と詳細です。 PTD0/RESET_b の回路: PTD0/RESET_b ピン (ピン 23) は、10 ピン SWD デバッグ ヘッダー (FTSH-105) のピン 10 に直接配線されています。PCB上のこのネットには外部プルアップ抵抗やデカップリングコンデンサはなく、完全にMCU内部のプルアップに依存しています。 VDD_IO_D レール電圧:レールはピンで直接3.28V を測定しており、これは AN14742 で想定される公称電圧の範囲内です。 RESET_bピンの抵抗値：基板の電源を切った状態で、RESETピンのGNDに対する抵抗値を測定したところ、異常に低い38オームでした。 外部リセットテスト：リセットラインに4.7kΩのプルアップ抵抗を外部から追加して3.3Vに接続し、ピンがハイになるかどうかをテストしました。しかし、効果はなく、SWD接続は依然として失敗しており、これはGNDに対する38オームのインピーダンスがプルアップ抵抗を完全に圧倒していることと一致します。 このまさに38オームのGNDに近い短絡電流が、工場出荷時のブランクMCXW727CMFTBTユニットの両方に存在しますが、MCXW716Cバリアントは同じPCBレイアウトで動作します。これはこのロット(ロットPF2R73.00)にシリコンや製造上の欠陥がある可能性を示しているのでしょうか?それとも内部ハードウェアの条件でこのラインが低下するのでしょうか? よろしくお願いいたします。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 @Rwaka さん。情報ありがとうございます。 観測された測定値をより詳細に分析するために、基板の回路図を共有していただけますでしょうか？ また、測定された抵抗値が低かったため、10kΩ～100kΩの範囲の外部プルアップ抵抗を追加してみてください。以下のコミュニティ投稿で推奨されているように: デバッグのための設計考慮事項。 また、RESET_bピンで観測されたリセット信号のオシロスコープ波形を共有していただけますでしょうか？ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 ご依頼いただいたテストはすべて、当社の3台目の、完全に未使用のユニット（これまで電源を入れたり、触ったりしたことが一度もない）で実施しました。 外部プルアップ抵抗（10kΩ、ご要望の10kΩ～100kΩの範囲内）： RESET_b、電源なし、10 kΩプルアップが設置されている: 16 kΩ (健康 — 外部10 kΩと並列で単独で測定された内部~313 kΩと一致) RESET_b、ボードの電源投入直後、同じ10kΩプルアップ抵抗がそのまま残っている場合： 0.013Vに低下する SWD接続試行（同じ設定）：やはり同じように失敗します — エラー：誤ったDM-AP IDCODEが検出されました：0xFFFFFFFF 電源投入時の RESET_b (PTD0) のオシロスコープ波形:当初報告したような平坦な線ではなく、より詳細な検査 (1ms/div、500mV/div) により、真の過渡現象が確認できます。ピンは約1V (3.3V ではなく) まで上昇し、わずかに上昇しながら約 1msの間その部分的なレベルを維持し、その後急激に低下して低いままになります。この同じ過渡現象は 外部10 kΩプルアップの有無に問わず存在し、デバッグコネクタだけでなくMCUピンに直接プローブしたことで確認されました。つまり、ケーブルやコネクタのアーティファクトではなく、ピンでの本物の信号です。タイムベースを100ms/divに広げ、さらに1s/divにすると、これは 一度き りのイベントであることが確認できます — リトライも繰り返しサイクルもありません。これはMCUがRESET_bを放出しようと失敗または部分的に試みた後、永久に停止したように見えます。繰り返しのブラウンアウトやウォッチドッグループ、あるいは最初の瞬間からピンが硬い0Vで保持されているわけではありません。 OSC1出力(ピン3、SIT8918BAアクティブオシレーター)のオシロスコープ: クリーンな32.000 MHzの方形波が存在し安定していることを確認しました。したがって、メインシステムクロックがEXTALに達したことが原因として除外されました。 追加データポイント — 公式FRDM-MCXW72ボード: この同じプローブを使って、問題なく本物のNXP FRDM-MCXW72評価ボードに接続しフラッシュできました。このボードのMCUマークは「MCXW72 / 7CMFTB / 3P57K / S1953603」と表示されており、故障しかけたカスタムボードユニットと同じ 部品番号(MCXW727CMFTB)およびマスクセット(3P57K )であることが確認できます。ただし、ロット/日付コード(S1953603とPF2R73.00)が異なります。これは、プローブ／ケーブル／治具に問題がないことを強く裏付けており、部品番号やマスクセット全般ではなく、ロットPF2R73.00に特有の問題であることを示唆しています。 概要: RESET_b は電源投入前は電気的に正常 (絶縁抵抗 313 kΩ / 外部プルアップ抵抗 16 kΩ) で、32 MHz 発振器も正常に動作していますが、電源投入と同時に RESET_b はほぼ 0V まで低下し、10 kΩ の外部プルアップ抵抗をかけてもその状態が維持され、リセットが保持された状態 (r/h/connect) を含め、SWD は接続できなくなります。これは、MCU自体が起動シーケンスの非常に早い段階でRESET_bをアクティブに低く保ち、決して離さないということを示しており、受動的または外部の電気的問題ではないということです。完全に未改造のユニットで再現可能であり、正常に動作するFRDM-MCXW72（同じプローブ）を陽性対照として使用した。 回路図の一部（RESET_b / SWDヘッダーネット、クロック部）を添付します。 次に何が一番役に立つか教えてください。接続試行中やその他のテスト中にSWDCLK/SWDIOのオシロスコープキャプチャを試してみます。 よろしくお願いいたします！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 @Rwaka さん、ご依頼いただいたテストを実施していただきありがとうございます。 ICの詳細な写真を共有していただけますか？お客様ご自身で作成された基板と、中古のFRDM基板の両方から取得します。 さらに、あなたの回路図についてですが、適切な電源構成が取られているかを確認するために、 AN14802 - MCX W71からMCX W72への移行ガイド と AN14742 - MCX W72の電源管理ハードウェア を参照することをお勧めします。サポートされていない電源モードの実装や電源設定の誤りを除外し、観測された動作を絞り込みます。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 AN14802/AN14742を回路図と照らし合わせて確認しました。ICの写真の前に1つ質問があります。 DCDC_LX:基板上でフローティング状態（外部インダクタなし）にしており、AN14742の「低コスト」構成に合致しています。しかしDC-DCを無効にするにはソフトウェア書き込みが必要で、私たちの空・プログラムされていないユニットでは絶対に書き込みがないため、DC-DCはLXをフロートさせたままハードウェアデフォルトで有効の状態を維持します。ただし、当社の稼働中のMCXW716C基板でも全く同じレイアウトが使用されています。 これ(DC-DC有効でLXフローティングの場合)は、コードが実行される前にブランクMCXW727Cで起動/SWDをブロックすることは現実的に可能でしょうか? 一時的にDCDC_LX GNDに接続するのは安全なテストでしょうか、それとも(内部スイッチノード、インダクタやスナビングなし)避けたほうがいいでしょうか? ICの写真を添付しました（カスタム基板＋FRDM基板、チップのマーキング）。 よろしくお願いいたします！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 @Rwaka さん。 設計でどのような電力構成アプローチを採用しているのか、確認していただけますか? 前の質問は重要な背景情報を提供しています。AN14742に記載されているように、「低コスト/バイパス」電源構成を使用している場合は、DCDC_LXピンをフローティング状態にしておくことが推奨されます。この電源構成を実装していない場合は、ピンをフローティング状態にしてはいけません。 このトピックに関連して、表58を参照することをお勧めします。MCXW72データシートの未使用インターフェースの接続を推奨し、供給構成に応じて未使用インターフェースの適切なピン接続を確保すること。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは@Rwaka。共有ドキュメントとの照合をありがとうございます。 VDD_CORE/VOUT_COREピンとVDD_LDO_COREピンでの信号のオシロスコープ測定を共有していただけますか? また、完全な回路図を共有できない場合は、以下のコミュニティ投稿を参照してください: KW47(オートモーティブ)またはMCX W72(IoT/インダストリアル)で初めてPCBを組み立てる最良の方法?記事の最後に、以下の2つのファイルが共有されています。 KW47 MCXW72 デザイン イン チェックリスト V3.xlsx: 設計がW72の適切な特性に完全に適合しているかどうかを判断するためのチェックリスト。 KW45 - MCX W71 - KW47 - MCX W72 最小BoMプレゼンテーション お客様May26.pdf:お使いの構成（LDOモード）に推奨される外部コンポーネントと接続に関するガイダンス。 指定された2つのファイル間で相互チェックを行い、その結果をお知らせください。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 確認ですが、当社のボードは「低コスト/バイパス」電源構成を採用しており、外部DC-DCインダクタは使用せず、DCDC_LXはフローティング状態になっています。 指示通り、表58（データシート）と照合しました。当社のレイアウトは、DC-DC関連のピンに関する推奨事項に準拠しています。 DCDC_LX: フローティング ✓ (「フロート」の推奨事項に一致) VSS_DCDC: GNDに接続済み ✓（「常にVSSに接続する」推奨事項に一致） 回路図のこの特定の箇所については、矛盾点は見つかりませんでした。表58に記載されているピンやエリアの中で、特に再確認してほしい箇所があればお知らせください。また、次に調査すべき別の角度があればお知らせください。 よろしくお願いいたします！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) こんにちは、 見つけることができました！そこへ導いてくださった皆様に感謝いたします！ 根本原因：カスタム基板上のVOUT_SYS/VDD_SYS（ピン22）にはデカップリングコンデンサが全くなく、完全にフローティング状態で、接続が全くありませんでした。ご紹介の公式FRDM-MCXW72回路図と比較すると、その基板はこのピンを4.7μF + 1.5μF + 0.1μFで並列に切り離しています(R36/LDO_SYS_BYPASSもDNPなので、VDD_SYSは完全に内部生成で、強くデカップリングされています)。 3台目の（これまで手を加えていなかった）ユニットのVDD_SYSとGNDの間に4.7µFのコンデンサを1個追加したところ、 SWDがすぐに接続され、フラッシュ書き込みも正常に動作するようになりました。 興味深いことに、MCXW716Cボードにも全く同じフローティングVDD_SYS(コンデンサなし)が存在し、それらは問題なく動作しています。つまり、これはW71とW72の電源管理ブロック間の実際の挙動の違い(AN14664で言及された新しいDC-DCランプ制御機能に関連している可能性がありますが、W71にはこの機能がありません)。ドキュメントの抜け穴というよりは、表58では「デカップリングコンデンサ以外は浮動」とVDD_SYS記載されていますが、最小値の指定はなく、W72特有の重要性を見落としがちです。 次回の基板改訂版では、VDD_SYSに適切なデカップリング（お客様の基準値に合わせる）を追加し、さらに他の2つのユニットについても確認します（これらのユニットは、以前のテストで発生したRESET_bの異常（今回の件とは無関係）も抱えていました）。 この件で最後までお付き合いいただき、本当にありがとうございました。表58／最小部品表の相互チェックに関するご提案は、まさに私たちが必要としていたものでした。本当にサポートに感謝しています。 よろしくお願いいたします！

i.MX8DXL EVK (J20) の TAMPER_OUT0/TAMPER_IN4 アクティブタンパーループ用の正しい snvs_cfg 値 こんにちは、 U-Boot を介して、i.MX8DXL EVK (MCIMX8DXL-WEVK) 上の外部アクティブタンパーループを検証しています。 基板の回路図から、J20（TAMPERヘッダー、1x3）の配線が以下のようになっていることを確認しました。 - ピン 1 = TAMPER_IN4 (ネット SNVS.TAMPER_IN4、ボール AJ13) - ピン2 = GND - ピン3 = TAMPER_OUT0 (ネットSNVS.TAMPER_OUT0、ボールAP22) これらは専用のSNVSピンであり、TAMPER_OUT1-4/IN0-3のようにSAI2/SAI3と共有されていません。 使用可能な U-Boot コマンド: tamper_pin_cfg、snvs_cfg (サブレジスタ hp.lock、hp.secvio_intcfg、hp.secvio_ctl、lp.lock、lp.secvio_ctl、lp.tamper_filt_cfg、lp.tamper_det_cfg、lp.tamper_det_cfg2、lp.tamper_filt1_cfg、lp.tamper_filt2_cfg、lp.act_tamper1_cfg ～ lp.act_tamper5_cfg、lp.act_tamper_ctl、lp.act_tamper_clk_ctl、lp.act_tamper_routing_ctl1、lp.act_tamper_routing_ctl2 を含む)、snvs_sec_status、snvs_clear_status。 TAMPER_OUT0/TAMPER_IN4はアクティブなタンパーペアを形成するため、私の質問は次のとおりです。 1. どのlp.act_tamperN_cfgチャネル(1-5)がTAMPER_OUT0に対応しているか? 2. lp.act_tamper_routing_ctl1/routing_ctl2ルートTAMPER_OUT0のパターンの値をTAMPER_IN4と比較してチェックする価値は? 3. このチャネルのパターンクロックを可能にするlp.act_tamper_clk_ctlの値は何? 4. このチャネルのアクティブ改ざん検出を可能にするグローバルなlp.act_tamper_ctl価値は何でしょうか? 目標：J20ピン1～3間のジャンパーを閉じるとsnvs_sec_statusでセキュアと表示され、ジャンパーを開くと違反が発生するようにする。 i.MX8DXLにおける外部アクティブタンパー検証に関するリファレンステスト手順またはアプリケーションノートはありますか？ よろしくお願いします！

MCXN947 DLL 自动调整功能无法正常工作 你好， 我正在使用 FlexSPI 连接 MCXN947，并搭配 OctalRAM (IS66WVO32M8DALL-200BLI)。 FlexSPI 根时钟通过 PLL1 以 150 MHz 的频率提供，由于 RAM 以 DDR 模式运行，因此我的输出时钟频率为 75 MHz。 `flexspi_device_config_t` 具有以下参数： flexspi_device_config_t psram_config = { .flexspiRootClk = 150000000U, .isSck2Enabled = false, .flashSize = OCTALRAM_ISSI_SIZE, .CSIntervalUnit = kFLEXSPI_CsIntervalUnit1SckCycle, .CSInterval = 2, .CSHoldTime = 2, .CSSetupTime = 2, .dataValidTime = 2, .columnspace = 4, .enableWordAddress = false, .AWRSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_WRITEDATA, .AWRSeqNumber = 1, .ARDSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_READDATA, .ARDSeqNumber = 1, .AHBWriteWaitUnit = kFLEXSPI_AhbWriteWaitUnit2AhbCycle, .AHBWriteWaitInterval = 0, .enableWriteMask = true, }; 为了初始化 FlexSpi，我使用了 SDK FLEXSPI_DRIVER，版本 2.6.0。 当我使用自动调整功能（如手册第 10.3.15.6 节“采样 DLL 配置”中所述）配置延迟单元时，使用以下值： • SLVDLYTARGET=0x0F（分频器 16/32 * 根时钟 = 3.33 ns） • REFPHASEGAP=0x02 • DLLEN=0x01 • OVRDEN=0x01 在等待 ASLVLOCK 和 AREFLOCK 锁定位之后，我得到 ASLVSEL 为 0x01，AREFSEL 为 0x00。因此，RAM 的读取和写入功能无法工作，因为设置的延迟时间约为 120 ps！ /* Configure DLL. */ configValue = FLEXSPI_CalculateDll(base, config); base->DLLCR[index] = configValue; /* DLL neu kalibrieren */ base->DLLCR[0] |= FLEXSPI_DLLCR_DLLRESET_MASK; base->DLLCR[0] &= ~FLEXSPI_DLLCR_DLLRESET_MASK; /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Lock abwarten */ while ((base->STS2 & (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) != (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) { } SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); 即使我使用不同的 SLVDLYTARGET 值，ASLVLOCK 和 AREFLOCK 的输出也不会改变。 但是，如果我使用寄存器 OVRDEN=0x01 和 OVRDVAL=0x1b 将延迟时间设置为固定值（对应于大约 3.36 ns 的延迟时间），则从 RAM 读取和写入数据都不会出现任何问题。 但是，由于根时钟大于 100 MHz，NXP 建议使用 DLL 的自动调整功能。 很遗憾，它似乎无法确定正确的延迟时间！ 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） 核心与内存 MCX N

RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Platform: MacOS 15.6.1 (24G90) VS Code (Version: 1.112.0 (Universal)) MCUXpresso for VS Code: 26.8.29 Zephyr toolchain: zephyr-sdk-1.0.1, zsdk nxp-v4.4.1.1 Application: amp_blinky imported as zephyr-freestanding Board: MIMXRT685-EVK Description: I am setting up dev environment on MacOS, same steps were working fine on my Linux machine. While build and flash threw no critical warning/error with MCUXpresso, application was running fine on both Arm and DSP cores. Then I edited the code under remote/src and remote/prj.conf, and flash it after a pristine build. However, the DSP core still ran the previous image before editing. Below are some of the interesting behaviors: I tried to edit the Arm core code too, but that change was applied successfully. Changes in the DSP core code can trigger a non-pristine build instead of showing "no work to do." Disabling CCACHE in cmake seems to solve the issue So far to me, it looks like a cahce-related issue that the compiler ignores the changes in the DSP image while running sysbuild, and uses the cached binary, regardless it has been rebuilt. It is probably caused by nxp_zephyr/zephyr/samples/boards/nxp/adsp/rtxxx/common/src/dspimgs.S isn't updated. Also, it might be a MacOS-only issue since I didn't notice it on my Linux machine. Is this a known issue? Is there an elegant solution instead of disabling CCACHE? Best Regards, Yue ZEPHYR-OS-EDGE  i.MXRT 600

Safety Mechanism SM1.INTERCONNECT_EDC _GASKET I need to enable the SM1.INTERCONNECT_EDC_GASKET safety mechanism for my project. I am using AUTOSAR RTD 3.0.0 and the S32 Design Studio (S32DS) tool to generate the code. Could you please clarify the following: 1.  Is there an option available within S32DS to enable this safety mechanism? If so, could you guide me on how to enable it? 2.  If this option is not available in S32DS, what is the recommended way to enable it? Please share example code if possible. Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET Hello @sandeepSingh18606, Use Safety Peripheral Drivers for S32K3xx. https://www.nxp.com/docs/en/product-brief/S32K-SPDPB.pdf The drivers are included in the S32K3xx Standard SW package: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K3-STDSW-D S32K3 Safety Peripheral Drivers version 1.0.3 is compatible with RTD 3.0.0. In the eMCEM driver, all available faults can be enabled. danielmartynek_1-1789975567252.png The SPD package contains a single EB Tresos demo. For S32DS, there is just one SPD example available (SPD 1.0.6, RTD 7.0.0): https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-BIST-eMCEM-SPD106-v2-0-S32DS365-RTD700/ta-p/2373113 Regards, Daniel Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET Hi @sandeepSingh18606, Safety Peripheral Drivers (SPD) are available free of charge, and it is an extension to RTD. Whereas Safety Software Framework (SAF) is a paid premium SW. Refer to this documentation: https://www.nxp.com/design/design-center/software/functional-safety-software/s32-safety-software-framework-saf-and-safety-peripheral-drivers-spd:SAF Regards, Daniel Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET I believe SPD is not free and requires a package purchase. Since the SM1 mechanism is implemented by NXP, the user only needs to enable it. However, NXP RTD does not support this feature. Without the SPD package, what is the recommended approach? Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET Hello @sandeepSingh18606, How did you install it if it is not listed? First of all, you need a version that is compatible with your RTD release. According to the SPD release notes: SPD v1.0.3: This SPD version is compatible with S32K3 Real-Time Drivers Version 3.0.0 and 3.0.0 P07. SPD v1.0.4: This SPD version is compatible with S32K3 Real-Time Drivers Version 4.0.0 and S32K3 Real-Time Drivers Version 3.0.0 P07 (Tresos version for the S32K324_MAPBGA257 derivative). The newer versions, v1.0.5 and v1.0.6, are compatible only with newer RTD releases. Download the update site ZIP package, for example: S32K3_SPD_1.0.3_DS_updatesite.zip Then add the update site in S32 Design Studio under Extensions. Thank you, BR, Daniel Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET It is available in the Previous tab, which appears to be inactive in your account. Let me check with the team responsible for managing it. I will get back to you as soon as possible. Regards, Daniel Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET Hi Daniel, I am currently using RTS 3.0.0. Per your suggestion, I need SPD v1.0.3, but I am unable to locate this version on the NXP website. Could you please advise on where I can find it or provide a direct link? Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET Hi Daniel, Thanks for the confirmation. I tried to install the SPD drivers in S32 Design Studio, but even after installing, I am still unable to find them under S32DS extensions and updates. Below is a screenshot of the RTDs currently installed on my system: Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET Hello Sandeep, Please check your account now. Let me know. Thank you  Re: Safety Mechanism SM1.INTERCONNECT_EDC _GASKET HI Daniel, I am able to access previous version now. Thanks for support.

针对1080p RTSP IP摄像机，推荐使用NXP i.MX处理器 大家好， 请问哪位可以推荐一款价格最低、能够处理 1080p RTSP IP 摄像头视频流的 NXP i.MX 处理器？ 我的要求是： 1 个 RTSP IP 摄像头输入 2. 1080p分辨率 3. 大约 25–30 帧/秒 4. 寻找能够可靠处理此任务的最低成本 i.MX 处理器/主板 主要目标是以尽可能低的硬件成本接收和处理/显示 1080p RTSP 摄像头流。 如果有人针对类似用途测试过低成本的 i.MX 处理器，请分享您的推荐和经验。 谢谢您！ Re: Recommendation for NXP i.MX Processor for 1080p RTSP IP Camera 你好， 对于使用 IP 摄像机的纯粹接收/显示应用，您可以考虑 i.MX8MM，因为它包含一个专用的硬件 VPU，能够解码 1080p60。 顺祝商祺！

MCXW727CMFTBT — 出厂空白设备上的 SWD 连接失败（2 台设备，故障相同） 我们无法与任何MCXW727CMFTBT 样品（2 个单元，定制板）建立 SWD 调试连接，而完全相同的探针/电缆/设置却能立即连接到其他方面完全相同的板（相同的原理图，相同的物料清单，只有 MCU 不同）上的 MCXW716C。 元件： MCXW727CMFTBT，HVQFN-48封装，日期代码9D2604，批号PF2R73.00；板：定制PCB（10引脚Cortex调试SWD，无ISP按钮），出厂空白/从未编程； SDK： MCUXpresso SDK 26.06.00 — 应用程序构建/链接正常，故障仅在调试连接阶段出现。 症状 使用 NXP LinkServer 25.12.83 和正版 SEGGER J-Link Plus 均出现完全相同的故障：   LinkServer: Error: Wire Ack Fault - target connected? Ed:02: Failed on connect: Ee(42). No connection to chip's debug port J-Link: device MCXW727C_M33_0 / connect (VTref correctly read at 3.025V) ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF LinkServer 自身的 MCXW7XX 预连接脚本 (LS_preconnect_MCXW7XX.scp) 会自动发出调试会话请求 — 但仍然失败。nxpdebugmbox (SPSDK) 手动启动调试会话也失败，出现相同的 WIRE ACK FAULT 错误。 已经排除 探头/电缆/适配器：已确认工作正常（同样的配置连接到MCXW716C也没问题） MCU 端的 VDD_IO / P3V3：~3.3V，正确 SWDIO/SWDCLK 连续性：良好 VDD_CORE（内部 低压差线性稳压器(LDO)）：1.065V，在范围内 RESET_b 处于静止状态，电缆拔出：读取0V而不是预期的内部上拉 ~3.3V（参考）。手册第22.3.1节）— 两个单元 连接尝试期间，强制外部将 RESET_b 设置为 3.3V（VTref 读取正确为 3.025V）：无变化，仍然失败，并出现相同的错误：DM-AP IDCODE 错误 0xFFFFFFFF 在两台独立的物理设备/两块独立的电路板上均可复现。 相关帖子 这里报告了完全相同的错误（DM-AP IDCODE 0xFFFFFFFF），设备名称相同，但情况不同（板卡工作正常，但在擦除/重新编程周期后损坏）： FRDM-MCXW72 不再连接。我们的设备从未进行过任何刷机，因此如果像该帖子所暗示的那样与 NBU/核心状态有关联，那么它显然也会影响客户从未触碰过的设备。 问题 对于早期生产的 MCXW727CMFTBT（批号 PF2R73.00），是否存在任何已知的勘误/启动配置要求/默认生命周期状态，导致在标准调试邮箱程序之外的空白设备上阻止 SWD 操作？ 两个单元的 RESET_b 在静止状态下读数均为 0V（与文档中记录的内部上拉电阻相反）——是该批次产品的制造问题，还是上电时会有其他因素驱动该引脚？ 针对这种情况，有没有不需要基于UART的ISP（我们的板子没有板载USB-UART桥接器）的推荐恢复方法？ 乐意根据要求提供完整日志、示波器捕获或其他任何有用的信息。 协议：BLE -> 连接性 协议：Thread Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 感谢您的快速跟进！ 为了澄清，我们使用两种探针分别进行了测试，每种探针都使用各自合适的工具——没有将 LinkServer 与 J-Link 探针混用： NXP MCU-Link Pro ，通过LinkServer 25.12.83访问，通过 MCUXpresso for VS Code 调试/闪存集成（它会在底层启动 LinkServer 的 gdbserver/flash-programmer）。这是我们日常的正常工作安排。 结果：线路确认故障 - 目标已连接？/ Ed:02: 连接失败: Ee(42)。无法连接到芯片的调试端口，即使 LinkServer 自动运行其 MCXW7XX 特定的预连接脚本（LS_preconnect_MCXW7XX.scp，该脚本会发出调试会话请求）时也是如此。 一个独立的、正品的SEGGER J-Link Plus （固件 V11.00）+ J-Link Adapter CortexM（20 针 → 10 针 0.05 英寸），通过J-Link Commander V9.74直接访问（而不是通过 LinkServer）。 结果：错误：检测到错误的 DM-AP IDCODE：连接时为 0xFFFFFFFF，VTref 已正确读取为 3.025 V。 我们专门进行了第二次测试，以排除任何 LinkServer/MCU-Link 特有的问题。使用完全相同的 J-Link Plus + 适配器 + 电缆 + 实验室电源设置，仅将目标板更换为我们的 MCXW716C 型号（PCB 相同，只有 MCU 不同）， J-Link Commander 连接成功并识别出 Cortex-M33 内核——因此确认探针、电缆、适配器和工具工作正常；故障似乎是 MCXW727C 部件/板特有的。 我们还没有专门尝试过 J-Flash 或 LinkFlash，只尝试过 J-Link Commander（连接）和 LinkServer 的内置“调试”和“恢复”闪存编程器模式——如果这有助于进一步缩小问题范围，我们很乐意尝试其中任何一个。 与我们联系，如果需要提供任何其他信息或日志。 顺祝商祺！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ，希望你一切都好。 为了更好地了解您观察到的现象，请您确认一下，在每种情况下，您是否都使用了外部 J-Link 调试器？或者您是否也尝试过使用 MCU-Link Pro？ 此外，请提供您用于通过 SWD 访问的工具（LinkFlash、J-Flash、J-Link Commander），因为 Linkserver 是用于启动和管理 NXP 调试探针的 GDB 服务器的实用程序（例如，因此，MCU-Link Pro），预计 Linkserver 不会检测到 J-Link 探针。J-Link Plus 探针只能与 J-Link Commander/J-Flash 工具一起被检测到和使用。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ，感谢你提供补充信息。 我注意到您提到 Reset_b 信号读数为 0V，这意味着设备处于持续 RESET 状态。鉴于此，我将提出一些问题，以帮助进一步分析观察到的行为： 请问MCU的PTD0/RESET_b引脚是否连接了任何硬件/电路？它浮空吗？ VDD_IO_D 轨电压测量结果是否正常？因为该电源域驱动复位系统上的电压。有关电源管理硬件建议，您可以参考AN14742 。 您能否测量 RESET_b 引脚的电阻？如果可以，请提供测量值。 当您从外部执行强制复位时，是否将外部电压直接连接到复位引脚？ 请告知我所需信息。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ，谢谢你提供的信息。 为了更好地分析观测到的测量结果，能否请您分享一下电路板的原理图？ 此外，鉴于测得的电阻值较低，请尝试添加一个阻值在 10kΩ-100kΩ 之间的外部上拉电阻？正如以下社区帖子中所建议的：调试的设计考虑因素。 另外，能否请您提供一下在 RESET_b 引脚上观察到的 RESET 信号的示波器波形图？ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@RomanVR ， 感谢您的支持。以下是我们硬件配置的尺寸和详细信息： PTD0/RESET_b 上的电路： PTD0/RESET_b 引脚（引脚 23）直接连接到我们的 10 针 SWD 调试接头（FTSH-105）的引脚 10。该PCB网络上没有外部上拉电阻或去耦电容；它完全依赖于MCU的内部上拉电阻。 VDD_IO_D 轨电压：直接在引脚处测量到轨电压为3.28V ，这完全在 AN14742 规定的预期标称电压范围内。 RESET_b 引脚的电阻：在电路板未通电的情况下，我测量到 RESET 引脚对地电阻异常低，为 38 欧姆。 External RESET test: 我在 RESET 线上的 3.3V 处添加了一个外部 4.7 kΩ 上拉电阻，以测试它是否会将引脚拉高。然而，这样做并没有效果，SWD 连接仍然失败，这与 38 欧姆的接地阻抗完全压倒上拉电阻的情况相符。 鉴于我们两块出厂空白的 MCXW727CMFTBT 芯片都存在 38 欧姆近乎短路到地线的情况——而我们的 MCXW716C 芯片在相同的 PCB 布局上开箱即用——这是否表明该批次（批号 PF2R73.00）存在硅/制造缺陷，或者是否存在内部硬件状况导致该线路拉低？ 顺祝商祺！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好，又见面了。 后续所有测试均在我们第三台全新未使用过的设备（此前从未通电/触碰过）上进行： 外部上拉电阻（10 kΩ，在您要求的 10kΩ–100kΩ 范围内）： RESET_b，未通电，接有 10 kΩ 上拉电阻： 16 kΩ （正常 - 与单独测量的内部 ~313 kΩ 一致，与我们的外部 10 kΩ 并联） RESET_b，电路板上电后，由于仍然使用相同的 10 kΩ 上拉电阻，电压立即降至0.013 V。 SWD 连接尝试（相同设置）：仍然失败，错误信息相同——错误：检测到错误的 DM-AP IDCODE：0xFFFFFFFF 上电时 RESET_b (PTD0) 的示波器波形：并非如我们最初报告的那样是一条硬平线——仔细观察（1ms/div，500mV/div）显示了一个真实的瞬态过程：引脚上升到大约1V （而不是 3.3V），以轻微的上升斜坡保持该部分电平约1ms ，然后急剧下降并保持低电平。无论是否使用外部 10 kΩ 上拉电阻，都会出现相同的瞬态波形，并且通过直接探测 MCU 引脚（而不仅仅是调试连接器）证实了这一点——因此，这是引脚上的真实信号，而不是电缆/连接器产生的伪影。将时间基准扩大到 100 毫秒/格，然后再扩大到 1 秒/格，可以确认这是一个单一的、一次性的事件——没有重试，没有重复循环。这看起来像是 MCU 尝试释放 RESET_b 一次失败/部分尝试，然后永久停止，而不是重复的欠压/看门狗循环，或者引脚从一开始就被保持在 0V。 示波器在 OSC1 输出端（引脚 3，SIT8918BA 有源振荡器）上显示：确认存在且稳定的干净 32.000 MHz 方波——因此，主系统时钟到达 EXTAL 的原因可以排除。 补充数据点——官方 FRDM-MCXW72 板：使用完全相同的探针，我们成功连接并刷写了真正的 NXP FRDM-MCXW72 评估板，没有任何问题。该板上的 MCU 标记显示为：MCXW72 / 7CMFTB / 3P57K / S1953603 — 确认其零件编号 (MCXW727CMFTB) 和掩模组 (3P57K) 与我们故障的定制板单元相同，只是批号/日期代码不同 (S1953603 对比我们的 PF2R73.00)。这有力地证实了探头/电缆/工具没有问题，并指出问题出在 PF2R73.00 批次上，而不是零件号或掩模组本身。 摘要：上电前 RESET_b 电气性能良好（313 kΩ 隔离 / 16 kΩ 带外部上拉），32 MHz 振荡器运行正常，但上电后 RESET_b 电压瞬间降至接近 0V 并保持在该电压状态——即使施加 10 kΩ 外部上拉电阻——SWD 始终无法连接，即使按住复位键（r/h/connect）也是如此。这表明 MCU 本身在其启动序列的早期就主动将 RESET_b 拉低，并且从未释放它，而不是被动/外部电气问题。在完全未改动的设备上可重复，以一台工作正常的 FRDM-MCXW72（相同探头）作为阳性对照。 附上原理图摘录（RESET_b / SWD 接头网络、时钟部分）。 请告诉我们接下来什么最有帮助——我们很乐意在连接尝试期间尝试 SWDCLK/SWDIO 示波器捕获，或者进行任何其他测试。 顺祝商祺！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) @Rwaka你好，感谢你执行了所需的测试。 请问您能否分享一下您的集成电路的详细照片？包括您定制的电路板和二手的FRDM电路板。 此外，关于您的原理图，我建议您参考AN14802 - MCX W71 到 MCX W72 的迁移指南和AN14742 - MCX W72 的电源管理单元硬件，以确保电源配置正确（例如）。排除不支持的电源模式实现或电源配置错误），并缩小观察到的行为范围。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好， 对照我们的原理图检查了 AN14802/AN14742——在 IC 图片之前有一个问题。 DCDC_LX：在我们的电路板上悬空（没有外部电感器），与 AN14742 的“低成本”配置相匹配。但禁用 DC-DC 需要软件写入，而这在我们空白/从未编程的设备上永远不会发生——因此 DC-DC 保持其硬件默认启用状态，LX 处于浮空状态。不过，我们正常工作的 MCXW716C 电路板也采用了完全相同的布局。 这种（DC-DC启用，LX浮空）是否真的能阻止空白MCXW727C在任何代码运行之前启动/写入？ 将 DCDC_LX 暂时连接到 GND 是否是一种安全的测试方法，还是应该避免这样做（内部开关节点，没有电感器/缓冲电路）？ 附图为集成电路图片（定制板+FRDM板，芯片标记）。 顺祝商祺！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ， 请问您在设计中采用了哪种电源配置方案？ 前面的问题提供了重要的背景信息，因为如果您使用的是“低成本/旁路”供电配置，建议按照 AN14742 中所述将 DCDC_LX 引脚浮空；如果您没有实现此供电配置，则该引脚不能悬空。 关于这个主题，我建议参考MCXW72 数据手册中的表 58。表 58 为未使用的接口推荐连接，以确保根据您的电源配置，未使用的接口具有正确的引脚连接。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ，感谢你对照共享文档进行核对。 能否提供一下VDD_CORE/VOUT_CORE引脚和VDD_LDO_CORE引脚的信号示波器测量结果？ 此外，如果您无法分享完整的原理图，请参考以下社区帖子：使用 KW47（汽车）或 MCX W72（物联网/工业）首次正确构建 PCB 的最佳方法？文章末尾分享了以下两个文件： KW47 MCXW72 设计检查清单 V3.xlsx：用于确定设计是否完全符合 W72 的正确特性的检查清单。 KW45 - MCX W71 - KW47 - MCX W72 最低物料清单演示客户 5 月 26 日.pdf：针对您的配置（LDO 模式）推荐的外部组件和连接提供指导。 请对这两个指定的文件进行交叉核对，并将结果告知我。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好， 确认：我们的板采用“低成本/旁路”供电配置——没有外部 DC-DC 电感，DCDC_LX 浮空。 我们按照建议，对照表 58（数据表）进行了交叉核对。我们的布局符合那里关于直流-直流相关引脚的建议： DCDC_LX：浮空 ✓（符合“浮动”建议） VSS_DCDC：接地 ✓（符合“始终连接到 VSS”建议） 我们没有发现原理图这一部分存在任何差异。如果您希望我们专门重新检查表 58 中的其他引脚/区域，或者您有其他角度需要调查，请告诉我们。 顺祝商祺！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好， 我们找到了——感谢您的指导！ 根本原因：我们定制的电路板上的VOUT_SYS/VDD_SYS（引脚 22）根本没有去耦电容——完全悬空，没有任何连接。与您指出的官方 FRDM-MCXW72 原理图相比，该板使用 4.7µF + 1.5µF + 0.1µF 并联对该引脚进行去耦（R36/LDO_SYS_BYPASS 在那里也是 DNP，因此 VDD_SYS 完全是内部生成的，只是进行了深度去耦）。 我们在第三个（之前未改动过的）单元的 VDD_SYS 和 GND 之间添加了一个 4.7µF 的电容——SWD 立即连接，刷写功能也正常工作。 有趣的是，我们的 MCXW716C 板上也存在完全相同的浮动 VDD_SYS（完全没有电容），而且这些板工作正常——因此，这似乎是 W71 和 W72 电源管理单元之间真正的行为差异（可能与 AN14664 中提到的新的 DC-DC 斜坡控制功能有关，W71 没有此功能），而不是文档上的疏漏——表 58 确实将 VDD_SYS 列为“除了去耦电容外，其余部分为浮动”，但没有指定最小值，很容易忽略它在 W72 上有多么关键。 我们将在下一个板版本中为 VDD_SYS 添加适当的去耦（与您的参考值匹配），并且还将检查我们的另外两个单元（它们在之前的测试中还出现了与此无关的自致 RESET_b 异常）。 非常感谢您一直陪伴我们——表 58 / 最小物料清单交叉检查建议正是我们所需要的。非常感谢您的支持。 顺祝商祺！

imx6q DDRストレステストについて i.mX6QでDDRストレステストを実行しているのですが、どのExcelファイルを使用すればよいか知りたいです。 `MX6Q_SabreSD_DDR3_register_programming_aid_v2.5.xlsx`というファイルを入手しましたが、これは正しいファイルでしょうか？ 現在、Samsung K4B4G16 256M×16チップ（合計2GBのチップ4個）を使用していますが、テストが完了しず、「チップセレクトが有効になっていません」というエラーが表示されます。 この問題をどう解決すればいいでしょうか? ありがとう。 Re: about imx6q ddr stresstest こんにちは、 @GavinChen さん。 このRPAテーブルはi.MX6Qに適しています。 あなたのRPAに関するご意見をお聞かせください。 B.R

MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) We cannot establish an SWD debug connection to any of our MCXW727CMFTBT samples (2 units, custom board), while the exact same probe/cable/setup connects immediately to an MCXW716C on an otherwise identical board (same schematic, same BOM, only the MCU differs). Part: MCXW727CMFTBT, HVQFN-48, date code 9D2604, lot PF2R73.00 Boards: custom PCB (10-pin Cortex Debug SWD, no ISP button), factory-blank/never-programmed SDK: MCUXpresso SDK 26.06.00 — application builds/links fine, failure is purely at debug-connect stage Symptom Fails identically with both NXP LinkServer 25.12.83 and a genuine SEGGER J-Link Plus:   LinkServer: Error: Wire Ack Fault - target connected? Ed:02: Failed on connect: Ee(42). No connection to chip's debug port J-Link: device MCXW727C_M33_0 / connect (VTref correctly read at 3.025V) ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF LinkServer's own MCXW7XX pre-connect script (LS_preconnect_MCXW7XX.scp) does issue a Debug Session Request automatically — still fails. nxpdebugmbox (SPSDK) manual Start Debug Session also fails with the same WIRE ACK FAULT. Already ruled out Probe/cable/adapter: confirmed working (same setup connects fine to MCXW716C) VDD_IO / P3V3 at the MCU: ~3.3V, correct SWDIO/SWDCLK continuity: good VDD_CORE (internal LDO): 1.065V, in range RESET_b at rest, cable unplugged: reads 0V instead of expected internal-pull-up ~3.3V (Ref. Manual §22.3.1) — on both units RESET_b forced externally to 3.3V during connect attempt (with VTref correctly read at 3.025V): no change, still fails with the same Wrong DM-AP IDCODE 0xFFFFFFFF Reproducible on 2 separate physical units / 2 separate boards Related thread Same exact error (Wrong DM-AP IDCODE 0xFFFFFFFF) reported here on the same device name, though in a different scenario (board worked, then broke after an erase/reprogram cycle): FRDM-MCXW72 no longer connects. Our units have never been flashed at all, so if there's a link to NBU/core state as that thread suggests, it apparently can also affect units that were never touched by the customer. Questions Any known erratum / boot-config requirement / default life-cycle state for early-production MCXW727CMFTBT (lot PF2R73.00) that would block SWD on a blank device beyond the standard Debug Mailbox procedure? RESET_b reading 0V at rest (contrary to documented internal pull-up) on both units — fabrication issue with this lot, or something else expected to drive this pin at POR? Recommended recovery procedure for this exact case that doesn't require UART-based ISP (our board has no on-board USB-UART bridge)? Happy to provide full logs, oscilloscope captures, or anything else useful on request. Protocol: BLE -> connectivity Protocol: Thread Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Thank you for the quick follow-up! To clarify, we tested with both probes, each with its own appropriate tool — not mixing LinkServer with the J-Link probe: NXP MCU-Link Pro, accessed through LinkServer 25.12.83, via the MCUXpresso for VS Code debug/flash integration (which launches LinkServer's gdbserver/flash-programmer under the hood). This is our normal day-to-day setup. Result: Wire Ack Fault - target connected? / Ed:02: Failed on connect: Ee(42). No connection to chip's debug port, including when LinkServer automatically runs its MCXW7XX-specific pre-connect script (LS_preconnect_MCXW7XX.scp, which issues a Debug Session Request). A separate, genuine SEGGER J-Link Plus (firmware V11.00) + J-Link Adapter CortexM (20-pin → 10-pin 0.05"), accessed through J-Link Commander V9.74 directly (not through LinkServer). Result: ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF on connect, with VTref correctly read at 3.025 V. We ran this second test specifically to rule out any LinkServer/MCU-Link-specific issue. Using this exact same J-Link Plus + adapter + cable + lab power supply setup, swapping only the target board for our MCXW716C variant (identical PCB, only the MCU differs), J-Link Commander connects successfully and identifies the Cortex-M33 core — so the probe, cable, adapter, and tool are confirmed working correctly; the failure appears specific to the MCXW727C part/board. We have not yet tried J-Flash or LinkFlash specifically, only J-Link Commander (connect) and LinkServer's built-in "debug" and "resurrect" flash-programmer modes — happy to try either of those if it would help narrow this down further. Let us know if there's any additional information or logs that would be useful. Best regards! Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, hope you are doing well. In order to better understand the behavior you are observing, would you please confirm if for each case you are using an external J-Link debugger? Or have you tried also with an MCU-Link Pro? Additionally, please provide which tool (LinkFlash, J-Flash, J-Link Commander) you are using to access through SWD, as Linkserver is a utility for launching and managing GDB servers for NXP debug probes (e.g. MCU-Link Pro), therefore it is expected that a J-Link probe will not be detected by Linkserver. While the J-Link Plus probe will only be detected and usable along J-Link Commander/J-Flash tools. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, thank you for providing additional information. I noticed that you mentioned that your Reset_b signal was reading 0V, this means that the device is in a constant reset state. Given this, I will ask some questions that will help to further analyze the observed behavior: Would you please clarify if there is any connected hardware/circuitry to the PTD0/RESET_b pin of the MCU? Is it floating? Is the VDD_IO_D rail measuring the proper voltage? Since this power domain drives voltage on the reset system. You may refer to AN14742 for reference on the power management hardware recommendations. Are you able to measure any resistance at RESET_b pin? If so, please provide the measured value. When you performed the forced reset externally, did you connect the external voltage directly to the reset pin? Please let me know the requested information. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, thank you for the information. In order to better analyze the observed measurements, would you please share the schematic of your board? Additionally, given that the measured resistance had a low value, would you please try adding an external pull-up resistor of a value between 10kΩ-100kΩ? As recommended in the following community post: Design Considerations for Debug. Also, would you please share an oscilloscope capture of the observed reset signal at the RESET_b pin? Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @RomanVR, Thank you for your support. Here are the measurements and details regarding our hardware setup: Circuitry on PTD0/RESET_b: The PTD0/RESET_b pin (pin 23) is routed directly to pin 10 of our 10-pin SWD debug header (FTSH-105). There are no external pull-up resistors or decoupling capacitors on this net on the PCB; it relies entirely on the MCU's internal pull-up. VDD_IO_D Rail Voltage: The rail measures 3.28V directly at the pin, which is well within the expected nominal voltage per AN14742. Resistance at RESET_b pin: With the board unpowered, I measured an abnormally low resistance of 38 Ohms to GND on the RESET pin. External reset test: I added an external 4.7 kOhm pull-up resistor to 3.3V on the reset line to test if it would bring the pin high. However, it had no effect and the SWD connection still fails, which aligns with the 38 Ohms impedance to GND completely overpowering the pull-up resistor. Given that this exact 38 Ohms near-short to GND is present on both of our factory-blank MCXW727CMFTBT units—whereas our MCXW716C variant works out of the box on the same PCB layout—could this indicate a silicon/fabrication defect on this lot (lot PF2R73.00), or is there an internal hardware condition that would pull this line low? Best regards, Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello again, Follow-up with the requested tests, all performed on our third, genuinely virgin unit (never powered/touched before this): External pull-up (10 kΩ, within your requested 10kΩ–100kΩ range): RESET_b, unpowered, with 10 kΩ pull-up in place: 16 kΩ (healthy — consistent with the internal ~313 kΩ measured in isolation, in parallel with our external 10 kΩ) RESET_b, as soon as the board is powered, same 10 kΩ pull-up still in place: collapses to 0.013 V SWD connect attempt (same setup): still fails identically — ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF Oscilloscope on RESET_b (PTD0) at power-up: not a hard flat line as we initially reported — closer inspection (1ms/div, 500mV/div) shows a genuine transient: the pin rises to approximately 1V (not 3.3V), holds that partial level for ~1ms with a slight upward ramp, then drops sharply back down and stays low. This same transient shape is present both with and without the external 10 kΩ pull-up, and was confirmed probing directly at the MCU pin (not just at the debug connector) — so it's a genuine signal at the pin, not a cable/connector artifact. Widening the timebase to 100ms/div and then 1s/div confirms this is a single, one-time event — no retries, no repeating cycle. This looks like the MCU making one failed/partial attempt to release RESET_b, then permanently stalling, rather than a repeating brownout/watchdog loop or the pin being held at a hard 0V from the very first instant. Oscilloscope on OSC1 output (pin 3, SIT8918BA active oscillator): clean 32.000 MHz square wave confirmed present and stable — so the main system clock reaching EXTAL is ruled out as a cause. Additional data point — official FRDM-MCXW72 board: using this exact same probe, we successfully connected to and flashed a genuine NXP FRDM-MCXW72 evaluation board without any issue. The MCU marking on this board reads: MCXW72 / 7CMFTB / 3P57K / S1953603 — confirming it's the same part number (MCXW727CMFTB) and same mask set (3P57K) as our failing custom-board units, just a different lot/date code (S1953603 vs. our PF2R73.00). This strongly confirms the probe/cable/tooling are not at fault, and points to something specific to lot PF2R73.00 rather than the part number or mask set in general. Summary: RESET_b is electrically healthy pre-power (313 kΩ isolated / 16 kΩ with external pull-up), the 32 MHz oscillator is running correctly, yet RESET_b collapses to near-0V the instant power is applied and stays there — even against a 10 kΩ external pull-up — with SWD permanently unable to connect, including with reset held (r/h/connect). This points to the MCU itself actively driving/holding RESET_b low very early in its boot sequence and never releasing it, rather than a passive/external electrical issue. Reproducible on a completely untouched unit, with a working FRDM-MCXW72 (same probe) as a positive control. Schematic excerpt (RESET_b / SWD header net, clock section) attached. Let us know what would help most next — happy to try SWDCLK/SWDIO scope captures during a connect attempt, or any other test. Best regards! Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, thanks for performing the requested tests Would you please share detailed pictures of your IC's? From both your custom boards and the used FRDM board. Additionally, about your schematic, I'd suggest referring to AN14802 - Migration Guide from MCX W71 to MCX W72 and AN14742 - Power Management Hardware for the MCX W72 in order to ensure that proper power supply configurations were taken (e.g. rule out unsupported power mode implementations or power misconfigurations) and narrow down the observed behavior. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, Could you please confirm which power configuration approach have you implemented in your design? The previous question provides important context, given that, if you are using the "low-cost/bypass" supply configuration, it is recommended to leave DCDC_LX pin floating as stated in AN14742, if you have not implemented this supply configuration, the pin must not be left floating. Related to this topic, I'd suggest referring to Table 58. Recommended connection for unused interfaces of the MCXW72 Datasheet to ensure having a proper pin connection for your unused interfaces depending on your supply configuration. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello, Went through AN14802/AN14742 against our schematic — one question before the IC pictures. DCDC_LX: left floating on our board (no external inductor), matching AN14742's "low-cost" config. But disabling the DC-DC requires a software write, which never happens on our blank/never-programmed units — so DC-DC stays at its hardware-default-enabled state with LX floating. Same exact layout is used on our working MCXW716C boards though. Could this (DC-DC enabled, LX floating) realistically block boot/SWD on a blank MCXW727C before any code runs? Would temporarily tying DCDC_LX to GND be a safe test, or should we avoid it (internal switch node, no inductor/snubbing)? IC pictures attached (custom board + FRDM board, chip markings). Best regards! Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello, To confirm: our board uses the "low-cost/bypass" supply configuration — no external DC-DC inductor, DCDC_LX left floating. We cross-checked against Table 58 (Datasheet) as suggested. Our layout matches the recommendations there for the DC-DC related pins: DCDC_LX: floating ✓ (matches "Float" recommendation) VSS_DCDC: tied to GND ✓ (matches "Always connect to VSS" recommendation) We didn't find a discrepancy on this specific section of the schematic. Let us know if there's another pin/area from Table 58 you'd like us to specifically re-check, or if you have another angle to investigate next. Best regards! Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, thanks for cross-checking with the shared documentation. Could you please share oscilloscope measurements of the signals at VDD_CORE/VOUT_CORE pins and at VDD_LDO_CORE pin? Additionally, if you cannot share your full schematic, would you please refer to the following community post: The best way to build a PCB first time right with KW47 (Automotive) or MCX W72 (IoT/Industrial)? At the end of the post, the following two files are shared: KW47 MCXW72 Design In checklist V3.xlsx: Checklist to determine if the design fully complies with the proper characteristics for the W72. KW45 - MCX W71 - KW47 - MCX W72 Minimum BoM Presentation Customers May26.pdf: Guidance on the recommended external components and connections for your configuration (LDO Mode). Please perform a crosscheck within the two specified files and let me know your findings. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello, We found it — thank you for the guidance that led us there! Root cause: VOUT_SYS/VDD_SYS (pin 22) had no decoupling capacitor at all on our custom board — completely floating, no connection whatsoever. Comparing against the official FRDM-MCXW72 schematic you pointed us to, that board decouples this pin with 4.7µF + 1.5µF + 0.1µF in parallel (R36/LDO_SYS_BYPASS is DNP there too, so VDD_SYS is purely internally-generated, just heavily decoupled). We added a single 4.7µF capacitor between VDD_SYS and GND on our third (previously untouched) unit — SWD connects immediately and flashing works. Interestingly, the exact same floating VDD_SYS (no cap at all) is present on our MCXW716C boards and those work fine — so this appears to be a real behavioral difference between the W71 and W72 power management block (possibly related to the new DC-DC ramp control feature mentioned in AN14664, which W71 doesn't have), rather than a documentation gap — Table 58 does list VDD_SYS as "floating except the decoupling capacitor," but doesn't specify a minimum value, and it's easy to miss how critical it apparently is on the W72 specifically. We'll add proper decoupling (matching your reference value) to VDD_SYS on our next board revision, and will also check our other two units (which additionally had a self-inflicted RESET_b anomaly from earlier testing, unrelated to this). Thank you very much for staying with us through this — the Table 58 / minimum BOM cross-check suggestion was exactly what we needed. Really appreciate the support. Best regards!

FlexIO BiSS-C 主设备：MA 时钟计数无法适应 ACK 周期，CRC 在 2.5 MHz 时校验失败 我正在使用 MIMXRT1186 和 SDK 的flexio_biss_polling_transfer示例与 BiSS-C 绝对编码器（24 位 ST + 16 位 MT）进行通信。 问题： 在500 kHz时，CRC 校验通过，位置数据正确。 在2.5 MHz 频率下，CRC 校验总是失败。编码器的 ACK 周期约为11.8 µs ，这在 2.5 MHz 频率下大约相当于30 个 MA 时钟周期。 示波器观察显示，FlexIO 主设备从帧的开头就发送固定数量的 MA 时钟，而没有根据 ACK 周期进行调整。这 30 个 ACK 低电平位被采样到 64 位接收移位器中，从而将实际的 START + SCD 数据推出了移位窗口。FLEXIO_BISS_CalFrameHeadLen()返回值介于 12 和 34 之间，并且BISS_VerifyFrame()校准失败。 我对BiSS-C的理解是： 该协议要求 MA 在 ACK 期间继续运行，因为编码器需要这些时钟来推进其内部状态机，最终结束 ACK 并发送 START 位。因此，正确的主控行为是： MA 从帧的开始就持续发送时钟信号，包括在 ACK 期间。 主监视器 SL。 主控器持续统计已发送的 MA 时钟数。当 SL 变为高电平（ACK 结束，START 位到达）时，主设备会记录 ACK 消耗了多少个时钟周期，然后计算完成帧还需要多少个时钟周期。 我的问题： FlexIO 的定时器使用固定的timerCompare值一次性发送预定义数量的时钟信号。FlexIO 是否有任何机制支持上述自适应行为，即根据帧期间的 SL 边沿动态调整剩余的 MA 时钟信号数量？ 具体来说： FlexIO 的定时器能否使用 SL 边沿作为触发信号来停止、RESET 或重新加载定时器，以便主设备能够确定 ACK 何时结束，然后发送剩余的时钟信号？ 如果 FlexIO 无法做到这一点，NXP 建议采用什么方案来实现支持长 ACK 周期的 BiSS-C 主设备（例如，eFlexPWM、LPSPI 或基于 FPGA 的解决方案）？ 设置： MCUXpresso SDK for MIMXRT1186 驱动程序： fsl_flexio_biss.c / .h 示波器监测 MA (D02) 和 SL (D00) 谢谢您的指导。

OTP_CFG_ASIL.WD_DIS = 1 の場合、FS85 が INIT_FS で永久に停止してしまうのですが、これは想定される動作でしょうか？ こんにちは、 FS85(フェイルセーフSBC)を搭載したボードを起動しており、フェイルセーフの状態マシンは決してINIT_FSを離れません(FS_STATES)。FSM_STATEは6/INIT_FSのままで、MCUが設定されたウィンドウ期間に連続的なウォッチドッグリフレッシュを送信します。 データシート（Rev 9、§14.3、p.18）によると、 「最初の正常なウォッチドッグ更新でINIT_FSが閉じられます。」弊社側では、OTP_CFG_ASIL.WD_DIS = 1（OTPによってウォッチドッグ監視が無効になっている）となっています。 スタック状態にある間もレジスタ読み取りをサポートする（ウォッチドッグ評価ロジックがそもそも実行されないことと完全に一致する）： FS_I_WD_CFG.WD_ERR_CNT = 0、 WD_RFR_CNT = 0（決して動かない） FS_DIAG_SAFETY.BAD_WD_DATA = 0、 WDタイミング不良 = 0 (ラッチしない) FS_STATES.REG_CORRUPT = 0、 OTP_破損 = 0（INIT_FSレジスタ/register_NOTの不一致を除外） 質問: WD_DIS = 1が構造的にINIT_FSを離れられないのは予想・文書化されているのでしょうか(WDがOTP無効になっていると閉じる「良いウォッチドッグ更新」イベントがINIT_FS生成されないため)?あるいは、OTPによってウォッチドッグが無効になっている場合に、INIT_FSを閉じてNORMAL_FSにアクセスするための、文書化された別の手順はありますか？ データシート セクション 14.1/14.3VALID_WD = 0 は OTP によって WD が無効になっているときに発生すると記述されていますが、INIT_FS -> WAIT_ABIST2 遷移の結果については明示的に述べられていません。何かご説明や、関連するアプリケーションノートの参考になることを教えていただけると助かります。 ありがとう、ソフィー FS85&FS84

S32K344 Kicad symbols and footprints Hello, Is there a KiCad library available for the S32K344 MCU family, including schematic symbols, footprints and 3D models (STEP)? Thank you. Re: S32K344 Kicad symbols and footprints Thanks. So I figure that I have to design the kicad symbol, footprint and 3D models by myself. Re: S32K344 Kicad symbols and footprints Hi @manu_fenixecu  In case of S32K3, we provide 3D STEP files and symbols and footprints for CADENCE Allegro. It can be found in Hardware Design Package: https://www.nxp.com/webapp/Download?colCode=S32K3_HW-DesignPackage Regards, Lukas

T1042 DDR4初期化失敗 私は64ビットインターフェースでDDR4に接続したT1042デザインを持っています。インターフェースの最上位バイトのニブル間で不適切なビットスワップの問題が既に見つかりましたが、これはSW設定では補正できないことがわかっています。PWBの改訂版で修正を実施する予定です。しかし、他のビットは正しく、スワッピングもリファレンスマニュアルで許可されている範囲に入っているため、代わりに32ビットモードで動作させて、SWや他の設計を引き続き表示できるようにしたいと考えています。QCVS DDRの検証ツールを使って試しましたが、メモリの初期化ができません。デバイスのパラメータを入力し、DQのマッピング値を自分のデザイン通りに設定しましたが、ERR_DETECTレジスタでビットACE= 1が出続けています。プロセッサはSPIインターフェース経由でRCWを取得し、DDR周波数は800MHzに設定されています。CodeWarrior/QCVSを使用して、正しいRCW値が受信されたことを確認する方法はありますか？32ビットモードの動作で考慮すべき他の設定は何でしょうか?なぜ動作しないのか説明がつきます。どんなサポートでも大変ありがたいです。ありがとう。 QorIQ T1デバイス Re: T1042 DDR4 Initialization Failure CodeWarrior/QCVSを使用して、正しいRCW値が受信されたことを確認する方法はありますか？ [A] はい、可能です。CCSを接続して、DCFG_CCSR_RCWSR1-DCFG_CCSR_RCWSR16を読み取って、SPIフラッシュのRCWと比較できます。 32ビットモードの動作で考慮すべき他の設定は何でしょうか?なぜ動作しないのか説明がつきます。 [A]これはディスクリートDDR4ですか？一般的なルールについては、 QCVS_DDR_User_Guideを参照してください。 ハードウェア設計については、 AN5097、DDR4 SDRAMメモリインターフェースのハードウェアおよびレイアウト**デザイン**の考慮事項 よろしくお願いします。 Re: T1042 DDR4 Initialization Failure こんにちは、ジューンさん。 ご返信ありがとうございます。CCSを使用してRCWステータスレジスタを読み取り、RCWが想定どおりにプログラムされていることを確認できました。 私はディスクリートDDR4を使っており、ユーザーガイドやレイアウトの考慮事項も確認済みです。 32ビットインターフェース使用に関するエラッタA-007864を満たすため、1300MT/sで動作するための650MHzクロックがあることを確認しました。同僚が、チップセレクトがトグルしているかどうか確認するように提案した。QCVSツールがプロセッサに設定を送信し始めると、CS0信号は十分に低く保たれることがわかりました。プログラミングが完了し、検証ルーチンを実行しようとすると、CS0信号が完全にアサートされなくなる。JTAGの境界スキャンツールを独自に使い、信号が期待通りに接続されていること、そしてT1042のI/Oが正味を十分に低くしてDDR4メモリデバイスのVILを満たすことができるかを確認しました。信号の整合性に関するルーティングの面でも、ネットワークが良好であり、どこにも短絡していないことも確認しました。どうやらメモリコントローラの設定に何か問題があり、チップセレクト信号が正しく機能しないようです。他に何かアイデアはありますか?ありがとう。 Re: T1042 DDR4 Initialization Failure 説明中のCS0がD1_MCS0_Bを指しているのか確認していただけますか? ご使用のCCSでコマンドを実行し、CCSのログ全体を更新してください。 (bin) % ccs::reset_to_debug よろしくお願いします。 Re: T1042 DDR4 Initialization Failure その通りです。私が言及しているのはD1_MCS0_Bのことです。 コマンドを実行すると (bin) % ccs::reset_to_debug 「ライブラリが見つかりません」というメッセージが表示されます。 Re: T1042 DDR4 Initialization Failure メモリコントローラは650MHzまたは1300MT/sの動作に設定されています。結果は同じだった。64ビットインターフェースのバイト8で意図しないビットスワップ(ニブル間の誤スワップ)が発生しているため、DDR4で32ビットモードを使おうとしています。設計は64ビット+ECCを想定していましたが、一時的な回避策として32ビット+ECCを運用しようとしています。つまり、現在5台の16ビットチップが接続されていますが、そのうち3台だけで動作させることを目指しています。 様々な設定の組み合わせを試してみましたが、QCVSツールの動作に変化は見られません。少し奇妙なのは、QCVSと同様の値をスタートアップスクリプトに設定したGreenHillsエミュレーターを使ってみたところ、DDR_SDRAM_CFG_2[D_INIT]がクリアされるまでの待機ループを通過できたことです。これは初期化が完了していることを示唆しています。そして、初期書き込み/読み出し検証で全て0x00となり失敗します。これは、最適ではない書き込みレベル設定値を使用しているため当然の結果です。QCVSツールだけ動作が異なる理由が分かりません。 Re: T1042 DDR4 Initialization Failure RCWステータスレジスタを読み出した後、コマンドを入力してください。 コマンド「ccs::reset_to_debug」の結果ではなく、完全なccsログを共有してください。 「ライブラリが見つかりません」というメッセージが表示されます。 完全なログは、ccs を使用した最初のコマンドから始まります。 よろしくお願いします。 Re: T1042 DDR4 Initialization Failure ACEエラーは、メモリコントローラがトレーニングシーケンス中にエラーを検出した場合に設定される自動キャリブレーションエラーです。では、クロック速度を800MHzから下げた場合、トレーニング結果はどうでしょうか? 一方、DDR4では64ビットまたは32ビットのバス幅のどちらが採用されるのでしょうか？T1042にはDDR4が何個接続される予定ですか？ Re: T1042 DDR4 Initialization Failure 添付ファイルは.txtファイルです。RCW出力による。最後に指定したコマンド「ccs::reset_to_debug」を実行しましたが、「ライブラリが見つかりません」というメッセージは表示されませんでしたが、その他の情報も表示されませんでした。 DDR構成レジスタについても同様のキャプチャを行い、添付しました。問題は見つかりません。実際、GreenHillsプローブで使用したこれらの値は正常に動作し、D_INITもクリアされるようですが、同じ値をQCVSツールで使用した場合はD_INITがクリアされません。GHプローブとCWTAPの違いがよく分かりません。何かアイデアがあれば教えてください。 Re: T1042 DDR4 Initialization Failure 現在、調達部門と協力してNDAを成立させ、完全な訂正書を作成できるようにしています。しかし、コンポーネントT1042NXE7MQBを使っていて、GoogleやNXPフォーラム検索ではエラッタA009942適用されるようです。 参照された「Optimization.zip」を教えていただけますか?どこにも添付されていないようです。 Re: T1042 DDR4 Initialization Failure 「ccs::reset_to_debug」は正しく動作します。 errata_A009942 が必要かどうか確認してください。必要な場合は、添付のホットフィックス Optimization.zip を解凍して、CodeWarrior PA インストールフォルダ内の既存の Optimization フォルダを上書きしてください。C:\Freescale\CW_PA_v10.5.1\eclipse\Optimization\resources\QorIQ\DDR\templates\init\errata_A009942.py が存在します。 以下の一般的なガイドラインをご確認ください。 新しいQCVSプロジェクトを作成する - 「自動設定」と「離散DRAM」を選択する - DRAM速度定格 = 最大速度 (例: 最大3200 MT/s、データシートを参照) - 「出力データレート」で「xxx MT/s」を選択してください（現在の動作速度、例： 1300MT /s。このデータレートはRCWイメージで設定されているDRAM速度と一致している必要があります）。   - 「ランク/チップ選択」で「x」を選択                   (シングルCSまたはデュアルCS)   - 「tCL」は「xx」を選択します（DRAMデータシートの速度ビン表に従って）。   - 「デバイスごとのDRAM構成」で「xx」を選択してください（DRAMデータシートを参照）。   - 適切な CLK-to-QDS スキューを埋める               (EDA ツールを使用して CLK 信号と DQS 信号の長さを測定します。CLK の長さ - DQS の長さ) CLKの長さからDQSの長さを引いた値。例： CLK-DRAM0間の長さ = 100 mm CLK-DRAM1間の長さ = 101 mm DQS[0]の長さ = 75 mm DQS[1]の長さ = 110 mm CLK-to-DQS[0]のスキュー = 100 mm - 75 mm = 25 mm CLK-to-DQS[1]のスキュー = 101 mm - 110 mm = -9 mm - CLK配線の長さは、DQS配線の長さと10インチ以内で等しいか、それ以上でなければなりません。 - MCKの配線長がDQSの配線長より短い場合、その差は2.0インチ以内でなければなりません。 DQマッピング - コントローラピン: 実際のボードでDQビットスワッピングが使われている場合、ユーザーはQCVSで実際のPCBレイアウトに合わせて設定する必要があります。 タイミングCFG_1と3: - tCL/tRCD/rRP/tRAS この値は、現在の動作速度に合わせるためにDRAMデータシートを参照します。      - tWR (書き込み回復時間、プリチャージの最小間隔となる最後のデータ)。この値はDRAMデータシートを参照してください。          - tRRD（アクティブ化間隔）この値はDRAMデータシートを参照します。     タイミングCFG_2:   - tFAW（4つのアクティブウィンドウ）、この値はDRAMデータシートを参照します。 ユーザーは、これらのボード固有の構成やDRAM固有の構成が実際のハードウェアと一致していることを確認する必要があります。 その他のほとんどのオプションについては、QCVSのデフォルト値を使用してください。 よろしくお願いします。 Re: T1042 DDR4 Initialization Failure 添付ファイルが見当たらなくて申し訳ありません。 Re: T1042 DDR4 Initialization Failure こんにちは、ジューンさん。 ファイルの提供と継続的なサポートに感謝します。QCVS DDRvツールの設定に関するガイドラインに従い、本日、エラータ#A009942の回避策を試してみましたが、効果は見られませんでした。スクリプト自体を調べてみたところ、667MHzと800MHzという特定の周波数に対してのみ回避策が適用されているようです。現在、訂誤#007864により、幅32ビット以下の800MHzで動作するとDDRインターフェースに問題がある可能性があるとされ、現在650MHzで動作しています。650MHzの場合、設定する必要のあるデバッグレジスタ値はありますか？ この設計は単一の100MHzクロックソースを使用しているため、DDR周波数の選択肢はDDR4用に650MHz、700MHz、750MHz、800MHzしかないように思えます。32ビットモードの場合、650MHz以外の周波数を使用すべきでしょうか？ 私は依然としてDQマップの値に疑念を抱いています。数ヶ月前の別の投稿で、 T1042 DDR4 DQ MAPレジスタ設定の値を確認するのを手伝っていただきました。 これは、当サイトで動作しているT1042 DDR4の他の例とこの設計との違いが顕著です。彼らは64ビットを使用し、最上位バイトでわずかなビットスワップを行っただけだった。64ビットインターフェースのMSBで既知の悪いビットスワップがあり、そのため32ビットモードを回避策として試みています。動作設計よりも多くのスワップがあり、1バイトレーン内での完全なニブルスワップも含まれますが、インターフェースの32ビットLSBはT1042コントローラーで許可されているルールに従っているようです。DQマップの入れ替えに関する様々な組み合わせが機能することが知られていますか？検証に使っている値をもう一度見ていただけますか?便宜上、レジスタ値と回路図のキャプチャを添付しています。DDR4デバイスのもう一方の端は直接1:1のマッピングなので、スワッピングはT1042側にのみ表示されています。 改めて、サポートありがとうございます。

QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Application Hello, We are working with a QorIQ T1022 design and have completed DDR bring-up and validation using the NXP DDR Validation Suite. The results are encouraging: All DDR validation tests pass successfully. We have achieved good timing margins across the tested conditions. No errors are reported by the validation suite during stress testing. However, when we load and run our main application, we begin to observe what appear to be memory-related issues/corruption. These issues are not reproducible using the DDR validation tests alone. This has raised the question of whether there are additional mechanisms or test methodologies we should be using to detect issues that may only appear under real application workloads. We are interested in understanding: What types of DDR or memory subsystem issues can escape the standard DDR Validation Suite tests on the T1022? Are there known application-level scenarios that can expose problems not detected during DDR training and validation? Are there additional stress tests, performance monitors, error counters, or debugging techniques available on the T1022 that could help identify the root cause? Has anyone encountered a situation where DDR validation showed excellent margins, yet memory corruption or instability was later observed in a production application? Any guidance on additional diagnostics, hardware checks, or software debugging approaches would be greatly appreciated. Thank you. QorIQ T1 Devices Re: QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Applicat Hello, The QCVS DDRv tool tests DDR timing margins (write leveling, read/write centering, clock adjustment) using sequential, deterministic access patterns from a single core via JTAG. It does not exercise: Multi-master / multi-core concurrent access — The T1022 has two e5500 cores plus the DPAA (Data Path Acceleration Architecture) with frame managers, queue managers, and DMA engines all competing for the DDR bus simultaneously. Contention-induced timing violations only appear under real traffic. Cache coherency stress — Application workloads involving cache flushes, invalidations, and coherent DMA transfers create access patterns the validation suite never generates. Thermal and power-supply variation — DDR margins measured at room temperature under light load can degrade significantly when the SoC is at full utilization and the AVDD_DDR supply droops under load. DQ mapping errors — If the DQ_MAPn registers are incorrect, the controller may still pass validation (which uses known training patterns) but corrupt data under real application traffic. This is a documented T1022-specific issue. Marginal single-bit ECC errors — The validation suite may not accumulate enough transactions to trigger SBE threshold reporting, while a real application running for hours will accumulate them silently. DQ Mapping Misconfiguration The DQ_MAPn registers provide the mapping of DRAM DQ signals to the controller. If these are wrong, the controller cannot correctly interpret training patterns, and data corruption occurs under real workloads. NXP has confirmed this on T1022 designs: clearing all DQn_MAP registers (setting to 0 for 1:1 mapping) is a recommended diagnostic step. Memory Ordering / Pipeline Effects (PowerPC e5500) The e5500 core has well-documented memory ordering subtleties. Writes may not be fully committed to DDR before subsequent reads, especially without explicit msync/isync barriers. NXP's apps team has confirmed: "The write may not be fully committed to memory before the error injection is disabled. The subsequent read may hit a cache or pipeline, not triggering the ECC logic immediately."In application code, missing barriers around DMA setup or shared-memory structures can cause apparent corruption that is actually a coherency ordering issue. ECC Single-Bit Error Accumulation The T1022 DDR controller supports ECC. Single-bit errors (SBEs) are silently corrected by the hardware but counted in ERR_SBE[SBEC]. If the SBE counter crosses the threshold ERR_SBE[SBET], a critical interrupt is generated. Under light validation traffic, this threshold is never reached. Under a real application, accumulated SBEs can eventually become uncorrectable multi-bit errors (MBEs), which are fatal — data cannot be recovered. Multi-Bit ECC Errors Manifesting as Application Crashes NXP has documented cases on QorIQ platforms (P2020, T1042) where application crashes (e.g., a lwz instruction faulting on a valid-looking address) were traced to MBE events in DDR. The crash is not a software bug — it is the e5500 core receiving corrupted data from the DDR controller and raising an IVOR1 Machine Check Exception. Importantly, the MCSR register shows 0xA000 (uncorrectable L1 cache/tag error) even when the memory region is cache-inhibited, because the DDR controller asserts a corrupted-data signal that the core registers as an L1 error Cross-check your board design against: AN3940 — Hardware and Layout Design Considerations for DDR3 SDRAM Memory Interfaces AN5097 — Hardware and Layout Design Considerations for DDR4 SDRAM Memory Interfaces AN4039 — PowerQUICC and QorIQ DDR3 SDRAM Controller Register Setting Considerations Pay particular attention to: AVDD_DDR power supply noise and decoupling, DDR reset signal routing (HRESET_B to DRAM RESET), and termination resistor values. Regards Re: QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Applicat Hi, Analysis of the Two Results Figure 1 (QCVS Tool 😞 The tool results show the "Centering the clock" validation stage. The optimal CLK_ADJ is highlighted in bright yellow/green at 1/8, with the corresponding WRLVL_START determined as 1/2 clocks showing 8/8 passes. The WRLVL margin per byte lane also shows a good wide green band. Figure 2 (Your own measurements 😞 Your board-level test sweeps CLK_ADJ across all values while keeping the WRLVL register (0x8655F606U, WRLVL_START = 3/4) fixed. The results show that only a narrow band of CLK_ADJ values (approximately 1/4 to 1/2 range) pass, and a large portion of the sweep fails. The blue-highlighted original CLK_ADJ appears to be at 9/16, which is at or near the edge of the passing window. Possible Causes for the Discrepancy 1. WRLVL_START Values Are Not Being Recalculated When CLK_ADJ Changes This is the most likely root cause. The QCVS tool correctly recalculates WRLVL register values for each CLK_ADJ value it tests. When you sweep CLK_ADJ in your own test while keeping the WRLVL_CNTL register value fixed at 0x8655F606U (WRLVL_START = 3/4), you are testing an invalid combination for most CLK_ADJ settings — the write leveling start delay must be appropriate for the specific CLK_ADJ phase chosen. In the QCVS tool, after "Centering the clock" completes, if you click on any other passing CLK_ADJ cell, it generates updated WRLVL register values in the "Updated Configuration Registers" window corresponding to that specific CLK_ADJ. This is the correct way to evaluate margin at alternative CLK_ADJ settings. 2. QCVS Uses Write-Read-Compare; Your Test May Use BIST or a Different Algorithm The QCVS "Centering the clock" scenario uses the Write-Read-Compare (WRC) algorithm, which performs a proper margin sweep and optimization of CLK_ADJ and WRLVL simultaneously. If your own testing uses BIST-based patterns, it is important to note that BIST tests do NOT retrain or tune any PHY timing — they only validate functionality using existing settings, and do not measure margin. 3. Signal Integrity / Board-Level Factors The QCVS tool operates under its own controlled test sequence and does not account for board-specific factors such as PCB trace length skew, temperature variation, or supply voltage margins. Board-level measurements can reveal a narrower effective timing window, which is expected for a custom board versus the reference design assumptions built into QCVS. Regarding the Blue-Highlighted Original CLK_ADJ Setting Your original CLK_ADJ setting (highlighted in blue, at 9/16) falls at or beyond the edge of the passing window in your board-level tests. This indicates it is operating with insufficient margin. The QCVS tool selected 1/8 as the optimum — a significantly different value — which implies the WRLVL_START register values used with your original 9/16 setting may not be appropriately matched to that CLK_ADJ, further reducing the effective margin. Recommended Margin Requirements The QCVS tool considers the bright green cell as the optimal setting and the passing window (green cells) around it as the margin indicator. The generally accepted NXP recommendation is: A minimum of 2–3 passing green cells on each side of the selected operating point is considered adequate margin. Only 1 passing cell on either side is considered insufficient/marginal and should not be used for production. The operating point should be centered within the passing window — not at an edge. Recommended Next Steps Use the QCVS tool's optimal CLK_ADJ of 1/8 and extract the corresponding WRLVL_CNTL register values from the "Updated Configuration Registers" window. Do not manually sweep CLK_ADJ while keeping WRLVL fixed. Re-run the full "Centering the clock" validation using the Write-Read-Compare test (not BIST) to ensure both CLK_ADJ and WRLVL_START are co-optimized. Verify the CLK-to-DQS skew input in QCVS is correctly set based on your PCB trace length measurements (CLK length minus DQS length from your EDA tool), as this directly seeds the initial WRLVL_START values. If you wish to evaluate the margin at your preferred CLK_ADJ, click that cell in the QCVS tool after the "Centering the clock" run so the tool recalculates the correct WRLVL values, then run the WRLVL margin scenario with those updated registers Regards Re: QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Applicat Hi, Thank you for the detailed response. Since then, we have carried out some additional investigation. Figure 1 shows the data extracted from the QorIQ validation tool. Based on these results, it appeared that we had sufficient margin available, and when we reviewed our register settings, they were within the values reported by the tool. Because of this, we initially did not make any changes to the register settings, as the validation results did not indicate that there was an issue. Figure 2 shows the results from our own testing. As you can see, these results do not appear to correlate with what the validation tool is reporting. From our measurements, the available margin seems to be significantly lower than that indicated by the tool. Is there anything we may be missing, or are there any additional factors that could explain the discrepancy between the validation tool results and our measurements? Please also note that the value highlighted in blue was our original CLK_ADJ setting. Could you also clarify what would be considered a sufficient margin in this case? The tool appears to indicate that having one green value on either side of the optimum setting is acceptable, but we would appreciate confirmation of the recommended margin requirements. figure 1) Are testing carried out on QorIQ DDR Validation tool. figure 2) Actual results when adjusting the CLK ADJ values with our own software.