GD3162 gate driver Hi NXP, Please clarify the difference between DESAT_LED (Leading edge blanking time and DESAT filter time). Is it so that the DESA_LEB refers to the programmable time after which Vds will be on? Re: GD3162 gate driver Hi Akshat, DESAT_LEB (Leading Edge Blanking Time) - This is the initial delay after the gate driver turns ON the power device, during which DESAT detection is ignored to prevent false triggering from transient spikes. The purpose is, when an IGBT or SiC MOSFET turns ON, there is a natural transient period where VCE/VDS momentarily spikes due to switching dynamics. DESAT_LEB prevents the gate driver from falsely detecting a desaturation event during this period. Think of DESAT_LEB as a "safe startup window" where DESAT protection is temporarily disabled to avoid false faults. DESAT Filter Time - This is the additional delay after DESAT_LEB before a DESAT fault is actually triggered. Even after DESAT_LEB ends, noise or transient overshoots may cause momentary high VCE/VDS readings. The DESAT filter time ensures that only sustained high VCE/VDS triggers a DESAT fault. Think of DESAT filter time as a "confirmation delay" to ensure only real desaturation events trigger a fault. BRs, Tomas

GD3162ゲートドライバADC こんにちはNXPの、 私たちのプロジェクトでは、DCバス電圧の読み取りにAMUXINを使用し、パワーデバイスの位相温度にTSENSEを使用しています。しかし、AMUXINの読み取りにはTSENSEを使用する予定です。可能ですか?ADCは、AMUXINを介して読み取られたものから異なるものをカウントしますか?明確にしてください 日時:GD3162ゲートドライバADC こんにちはアクシャット 内部構成と説明には、AMUXINはADCの主な目的でGPIとして使用でき、この接続には総誤差変動やその他の機能に対する追加の制御があると記載されています。 TSENSEには、温度検出ネットワーク用の電流ドライバが含まれています AMUXINにTSENSEを使用すると、電気的エラーが発生しない可能性がありますが、これらの変更が正しい測定に影響を与える可能性があります。 これらの接続の詳細については、公式ページ GD3160をお読みください: GD3160アドバンストIGBT / SiCゲートドライバ - データシート、このドキュメントは安全なファイルですので、この方法で共有することはできません。 この情報がお役に立てば幸いですので、他に何か助けが必要な場合はお知らせください。 素晴らしい一日を過ごし、幸運を祈ります。

RPI_CAMを使用しようとすると、FRDM im93ボードのデフォルトイメージでap1302ファームウェアを更新できません FRDM imx-93開発ボードにプリインストールされているNXP Goポイントでデモを実行しようとしています。そのために、ボードユーザーマニュアルRev.1302に記載されているように、ONSEMIのgithubリポジトリ9からap1.0ファームウェアをダウンロードしました。ファームウェアファイルの名前を変更して、/lib/firmware/imx/camera/パスにも配置しました。RPI-CAM-MIPI を接続すると、カメラとインターフェースできず、ビデオ テストやオブジェクト分類のために GoPoint デモを実行しようとするとフィードが得られません。 UMのONSEMI githubリンクで入手できる3つのファームウェアすべてを使用してみましたが、同じ結果が得られました。 $dmesgの出力 |grep ap1302は、画像として添付されています。 FRDMトレーニング ハンズオン・トレーニング Re:RPI_CAMを使用しようとすると、FRDM im93ボードのデフォルトイメージでap1302ファームウェアを再生できません こんにちは@Aditya_Vashista  この問題は解決しましたか?私も同じボードで作業しており、同じ問題に直面しています。

MW6S004NT1のAWRモデルを見つける方法は? こんにちは、私はパワーアンプの設計をしています、私はMW6S004N1モデルを使用する必要がありますが、私はウェブサイトでAWRモデルを見つけられませんでした。

RW612 - PM4 ディープ スリープが断続的に高電流を消費する 当社の製品の1つ、つまりu-blox IRIS-W10モジュールに搭載されたRW612をベースとしている製品が、表向きはディープスリープ状態に入っていますが、実際には~60mAを消費し、バッテリーを急速に消耗しているという問題に直面しています。 これが深い眠りに入ろうとしている私たちの関数です。 void PowerManager::EnterPowerDown(uint32_t duration_secs) { auto &board = Board::GetInstance(); debug_.Info(kTopicGeneral, "sleeping for %lu secs (max)", duration_secs); os_self_sleep_ms(500u); auto sleep_ticks = SecsToRtcTicks(duration_secs); PM_SetConstraints(kLowPowerMode, APP_PM_CONSTRAINTS); auto base_priority = os_enter_critical_from_isr(); board.InitPins(); PM_EnablePowerManager(true); PM_EnterLowPower(sleep_ticks); /* Should never get here, PM4 Deep Sleep requires a cold boot. */ PM_EnablePowerManager(false); os_exit_critical_from_isr(base_priority); PM_ReleaseConstraints(kLowPowerMode, APP_PM_CONSTRAINTS); } kLowPowerMode は PM_LP_STATE_PM4 として定義され、APP_PM_CONSTRAINTS は 0 です。 電源モードと制約を選択し、クリティカル セクションに入り、GPIO を既知の状態にし、電源管理ドライバーを有効にして、低電力モードを呼び出します。当社のボードは、GPIO[24]でウェイク信号が発生したとき、または1時間が経過したときにウェイクアップし、PM4 Deep Sleepに入った後に予想されるように、すぐに再起動します。 ほとんどの場合、この状態ではシステムは <1mA を消費します。しかし、断続的にこの状態になり、スリープサイクル(このアプリケーションでは最大1時間)の期間中、~60mAを消費します。言うまでもなく、これは充電間のバッテリー寿命を破壊します。(電力はデータシートによると<10uAになるはずですが、それは別の日のトピックです。 Wi-Fi ドライバーの起動と停止が複雑になるのを避けるために、スリープ状態になりたいときに NVRAM にフラグを設定し、 __NVIC_SystemReset() を呼び出してシステムを再起動し、Wi-Fi サブシステムはそのままにして低電力モードに入るようにシステムを設計しました。スリープから目覚めると、再起動し(PM4から抜け出すため)、Wi-Fiを開始し、テレメトリをクラウドにアップロードします。 あなたの "power_manager_test" SDK の例は baremetal 用に書かれました。FreeRTOS を実行するときに、PM4 に入ると本当に低電力状態になることを確認するために取るべき追加の予防措置はありますか?他にどのような条件が誤ったPM4状態を引き起こす可能性がありますか? ダナ・M Re:RW612 - PM4ディープスリープが断続的に高電流を消費する 問題を見つけたと思います。当社のシステムは、低電力モードになる直前に再起動を実行します。これにより、電源切断前にWi-Fi + TCP/IPスタックのグレースフルシャットダウンを実装する必要がなくなります。(Wi-Fi API を使用して Wi-Fi スタックをシャットダウンする最初の試みは信頼性が低かったため、再起動のアプローチに切り替えました。NVRAMのフラグを使用して、Wi-Fiを起動せず、ウェイクアップピンを正しい極性にすぐに構成して電源を切るようにシステムに信号を送ります。当社のボードは、ディープスリープ時に~1mAを消費します。 過剰な電流引き込みの原因は、メインCPU(Cortex-M33)をリセットすると、Wi-Fi CPU/無線がアクティブ状態のままになり、~56mAが消費されることがあるからだと思います。睡眠/チェックインの間隔は1時間なので、バッテリーからの消費電力は56mAhです。CPUと無線がどのようにリセットされるかについてNXPに具体的に尋ねたところ、__NVIC_SystemReset()はCortex-M33のみをリセットし、他のプロセッサはそのままにしておくことが確認されたようです。今朝、私はボードのスタートアップ関数に 2 行のコードを入れました。 /* Ensure that the radios are powered off at startup. Thus, if we go * directly into power-down, this should eliminate the possibility that * the radios are still powered and thus pulling current. */ POWER_PowerOffWlan(); POWER_PowerOffBle(); アプリケーションを再構築し、LED 懐中電灯を使用してボードがスリープ状態になるたびにウェイクアップするように、~40 分間実行しました。テスト中にユニットを約50回起こしましたが、50/50で低電力になった、つまり過度の電流を消費しませんでした。以前は、システムを高電流のスリープ状態にするのに数回の試行しか必要としませんでした。この時点で、問題は解決したと考えています。 まとめると...Wi-Fi スタックや BLE スタックが初期化されて実行されており、システムがリセットまたはウォッチドッグされている場合は、起動時に POWER_PowerOffWlan() や POWER_PowerOffBle() を呼び出して、Wi-Fi と BLE の CPU/ラジオの電源がオフになっていることを確認する必要があります。NXPスタックを使用してWi-Fiを開始する場合、最初のステップの1つはWi-Fiプロセッサの電源をオフにしてから電源を入れることです。したがって、起動時にラジオの電源を明示的にオフにしても、後でWi-Fiスタックを初期化するのを妨げません。 ダナ・M Re:RW612 - PM4ディープスリープが断続的に高電流を消費する どのSDKバージョンを使用していますか? SDK v2.16.1を使用してプロジェクトを生成しました。SDK 24.12(2025-01-15)をプルダウンしましたが、MCUXpressoがコンポーネントを追加またはアップグレードするときにプロジェクトを使用できなくするのが好きなため、このプロジェクトにはまだ適用しようとしていません。 この動作は、変更なしのSDKの例で見られますか? SDKの例で行った非常に限定的なテストでは、いいえ、発生しませんでした。 この動作を SDK の例で再現できますか? おそらくそうではないでしょう。 どのような変更を行う必要がありますか? FreeRTOS、Wi-Fi ドライバー、lwIP ネットワーク、AWS クライアントスタックを例に追加します。 この動作はFRDMで確認できますか? FRDMボードをカスタムボードと同じように機能させるにはかなりの労力がかかりますが、それは可能です。 ダナ・M

双通道摄像头的 imx8mp DTS 配置 我在 IMX8MP 的 CSI 端口 0 上有一个 2 通道 MIPI 连接。 我能够捕获数据，但是图像是垃圾，我正在尝试解决它。 我有以下 DTS 配置： &cameradev { status = "okay"; cap_device { status = "okay"; }; }; &i2c3 { status = "okay"; lvds_bridge { reg = <0x5A>; status = "okay"; compatible = "lt9211c"; #address-cells = <0x1>; #size-cells = <0x0>; port { lt9211c_ep: endpoint { data-lanes = <1 2>; clock-lanes = <0>; bus-type = <4>; clock-noncontinuous = <1>; remote-endpoint = <&mipi_csi0_ep>; clock-frequency = <74250000>; // Pixel clock in Hz (74.25 MHz) hsync-active = <0>; // Sync polarity vsync-active = <0>; pclk-sample = <1>; // Sample on rising edge }; }; }; }; &isi_0 { status = "okay"; cap_device { status = "okay"; }; m2m_device { status = "disabled"; }; }; &isi_1 { status = "disabled"; cap_device { status = "okay"; }; }; &mipi_csi_0 { status = "okay"; #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; mipi_csi0_ep: endpoint { remote-endpoint = <&lt9211c_ep>; data-lanes = <2>; csis-hs-settle = <4>; csis-clk-settle = <2>; csis-wclk; bus-type = <4>; /* 4 = MIPI CSI-2 D-PHY */ }; }; }; 现在您可以看到 mipi_csi0_ep: 端点中的 data-lanes=<2>。 CSI 驱动程序 imx8-mipi-csi2-sam.c有以下行来解析这些数据通道： of_property_read_u32(node, "data-lanes", &state->num_lanes); 因此它能够正确解析这2个数据通道。 但是我在内核日志中看到以下内容： [ 143.134848] mc: media_release: Media Release [ 149.819027] mxc-mipi-csi2.0: mipi_csis_imx8mp_phy_reset: bus fmt is 12 bit ! [ 149.843365] Parent device name: 32e00000.isi [ 149.869847] Parent device name: 32e00000.isi [ 150.889587] mxc-mipi-csi2.0: mipi_csis_imx8mp_phy_reset: bus fmt is 12 bit ! 此警告来自 CSI 驱动程序中的 phy_reset 函数（） /* temporary place */ if (state->mix_gpr) { if ((format.format.code == MEDIA_BUS_FMT_SRGGB8_1X8) || (format.format.code == MEDIA_BUS_FMT_SGRBG8_1X8) || (format.format.code == MEDIA_BUS_FMT_SGBRG8_1X8) || (format.format.code == MEDIA_BUS_FMT_SBGGR8_1X8)) { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW8); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 8 bit!\n", __func__); } else if ((format.format.code == MEDIA_BUS_FMT_SRGGB10_1X10) || (format.format.code == MEDIA_BUS_FMT_SGRBG10_1X10) || (format.format.code == MEDIA_BUS_FMT_SGBRG10_1X10) || (format.format.code == MEDIA_BUS_FMT_SBGGR10_1X10)) { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW10); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 10 bit !\n", __func__); } else { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW12); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 12 bit !\n", __func__); } goto write_regmap; } 我尝试将以下内容添加到第一个 IF 条件以强制其为 8 位，但这并没有解决我的任何问题。 (format.format.code == MEDIA_BUS_FMT_SGRBG8_1X24) || 有人可以澄清一下，这里正确的方法是什么？

RW612 - PM4 deep sleep intermittently draws high current We are encountering an issue where one of our products, based on an RW612 in a u-blox IRIS-W10 module, is ostensibly entering deep sleep but in reality is drawing ~60 mA and rapidly draining the battery. Here is our function that is entering deep sleep: void PowerManager::EnterPowerDown(uint32_t duration_secs) { auto &board = Board::GetInstance(); debug_.Info(kTopicGeneral, "sleeping for %lu secs (max)", duration_secs); os_self_sleep_ms(500u); auto sleep_ticks = SecsToRtcTicks(duration_secs); PM_SetConstraints(kLowPowerMode, APP_PM_CONSTRAINTS); auto base_priority = os_enter_critical_from_isr(); board.InitPins(); PM_EnablePowerManager(true); PM_EnterLowPower(sleep_ticks); /* Should never get here, PM4 Deep Sleep requires a cold boot. */ PM_EnablePowerManager(false); os_exit_critical_from_isr(base_priority); PM_ReleaseConstraints(kLowPowerMode, APP_PM_CONSTRAINTS); } kLowPowerMode is defined as PM_LP_STATE_PM4, and APP_PM_CONSTRAINTS is 0.  We select our power mode and constraints, enter a critical section, put our GPIO into a known state, enable the Power Management driver, and invoke low power mode.  Our board does wake up when a wake signal occurs on GPIO[24], or when one hour has elapsed, and it does immediately restart, as one would expect after entering PM4 Deep Sleep. Most of the time the system draws <1 mA in this state.  But intermittently, it enters this state and draws ~60 mA for the duration of the sleep cycle, which is a maximum of one hour in our application.  Needless to say, this destroys our battery life between charges.  (The power should be going to <10 uA per the datasheet, but that's a topic for another day.) To avoid complications with starting and stopping the Wi-Fi driver, I've engineered the system such that when we want to go to sleep, I set a flag in NVRAM, reboot the system by calling __NVIC_SystemReset(), and then enter low-power mode, while leaving the Wi-Fi subsystem untouched.  When we wake from sleep, we reboot (because we're coming out of PM4), start Wi-Fi, and upload telemetry to the cloud. Your "power_manager_test" SDK example was written for baremetal; are there additional precautions that one must take when running FreeRTOS to ensure that entering PM4 will genuinely yield a low-power state?  What other conditions could cause a false PM4 state? Dana M. Re: RW612 - PM4 deep sleep intermittently draws high current I believe I’ve found the issue.  Our system performs a reboot immediately prior to engaging low-power mode.  This removes the requirement to implement a graceful shutdown of the Wi-Fi + TCP/IP stack prior to power-down.  (My initial attempts at shutting down the Wi-Fi stack through the Wi-Fi API were unreliable, so I switched to the reboot approach.)  We use a flag in NVRAM to signal the system not to bring up Wi-Fi but instead immediately configure the wakeup pin for the correct polarity and go into power-down.  Our board pulls ~1 mA in deep sleep. I believe the cause of our excessive current draw is that sometimes when we would reset the main CPU (Cortex-M33), the Wi-Fi CPU/radio would be left in an active state, pulling ~56 mA.  Since our sleep/check-in interval is 1 hour, that’s 56 mAh of draw from the battery.  I asked NXP specifically about how the CPUs and radios are reset, and that seemed to confirm that __NVIC_SystemReset() only resets the Cortex-M33, leaving the other processors alone.  This morning, I put two lines of code into our board startup function: /* Ensure that the radios are powered off at startup. Thus, if we go * directly into power-down, this should eliminate the possibility that * the radios are still powered and thus pulling current. */ POWER_PowerOffWlan(); POWER_PowerOffBle(); I rebuilt the application and then ran it for ~40 minutes, using an LED flashlight to wake up the board every time it went to sleep.  I woke the unit up likely about 50 times during the test, and 50/50 it went into low power, i.e. it did not draw excessive current.  Previously, it would take me only a few attempts to get the system into a high-current sleep state.  At this point, I consider the issue solved. In summary… if the Wi-Fi and/or BLE stacks are initialized and running, and the system is reset or watchdogged, it is necessary to call POWER_PowerOffWlan() and/or POWER_PowerOffBle() at startup to ensure that the Wi-Fi and BLE CPUs/radios are powered off.  When starting Wi-Fi using the NXP stack, one of the first steps is powering down and then powering up the Wi-Fi processor, so explicitly powering down the radio at startup does not interfere with a later initialization of the Wi-Fi stack. Dana M. Re: RW612 - PM4 deep sleep intermittently draws high current What SDK version are you using? I generated our project using SDK v2.16.1.  I have SDK 24.12 (2025-01-15) pulled down but I have not yet attempted to apply it to this project, given how MCUXpresso likes to render projects unusable when adding or upgrading components. Are you seen this behavior with the SDK example without modifications? In the very limited testing we did with the SDK example, no, it did not occur. Can we reproduce this behavior with the SDK example? Likely not. What changes need to be done? Add FreeRTOS, Wi-Fi driver, lwIP networking, and an AWS client stack to the example. Are you able to see this behavior in our FRDM? It would take considerable effort to rig up a FRDM board to work the same as our custom board, but it could be done. Dana M. Re: RW612 - PM4 deep sleep intermittently draws high current Hello, Hope you are doing well. What SDK version are you using? Are you seen this behavior with the SDK example without modifications? Can we reproduce this behavior with the SDK example? What changes need to be done? Are you able to see this behavior in our FRDM? Best Regards, Ricardo

RW612 - PM4 深度睡眠间歇性消耗高电流 我们遇到一个问题，我们的一款基于 u-blox IRIS-W10 模块中的 RW612 的产品表面上进入了深度睡眠，但实际上消耗了约 60 mA 的电流并迅速耗尽电池电量。 这是我们正在进入深度睡眠的函数： void PowerManager::EnterPowerDown(uint32_t duration_secs) { auto &board = Board::GetInstance(); debug_.Info(kTopicGeneral, "sleeping for %lu secs (max)", duration_secs); os_self_sleep_ms(500u); auto sleep_ticks = SecsToRtcTicks(duration_secs); PM_SetConstraints(kLowPowerMode, APP_PM_CONSTRAINTS); auto base_priority = os_enter_critical_from_isr(); board.InitPins(); PM_EnablePowerManager(true); PM_EnterLowPower(sleep_ticks); /* Should never get here, PM4 Deep Sleep requires a cold boot. */ PM_EnablePowerManager(false); os_exit_critical_from_isr(base_priority); PM_ReleaseConstraints(kLowPowerMode, APP_PM_CONSTRAINTS); } kLowPowerMode定义为PM_LP_STATE_PM4 ，而APP_PM_CONSTRAINTS为 0。我们选择电源模式和约束，进入关键部分，将 GPIO 置于已知状态，启用电源管理驱动程序，并调用低功耗模式。当 GPIO[24] 上出现唤醒信号或一小时后，我们的电路板确实会被唤醒，并且会立即重新启动，就像进入 PM4 深度睡眠后所预期的那样。 大多数情况下，系统在此状态下消耗的电流小于 1 mA。但间歇性地，它会进入这种状态并在睡眠周期内消耗约 60 mA 的电流，这在我们的应用中最多为一小时。不用说，这会缩短我们充电期间电池的寿命。（根据数据表，功率应该小于 10 uA，但这是另一天的话题。） 为了避免启动和停止 Wi-Fi 驱动程序时出现复杂情况，我对系统进行了如下设计：当我们想要进入睡眠状态时，我会在 NVRAM 中设置一个标志，通过调用__NVIC_SystemReset()重新启动系统，然后进入低功耗模式，同时保持 Wi-Fi 子系统不受影响。当我们从睡眠中醒来时，我们会重新启动（因为我们是从 PM4 中出来的），启动 Wi-Fi，并将遥测数据上传到云端。 您的“power_manager_test”SDK 示例是为裸机编写的；运行 FreeRTOS 时是否必须采取额外的预防措施以确保进入 PM4 真正产生低功耗状态？还有哪些情况可能导致错误的 PM4 状态？ 达娜·M. 回复：RW612 - PM4 深度睡眠间歇性消耗高电流 我相信我已经找到问题所在了。我们的系统在进入低功耗模式之前会立即重新启动。这就消除了在断电之前正常关闭 Wi-Fi + TCP/IP 堆栈的要求。（我最初尝试通过 Wi-Fi API 关闭 Wi-Fi 堆栈，但结果不可靠，因此我改用重启方法。）我们使用 NVRAM 中的标志来向系统发出信号，不要启动 Wi-Fi，而是立即将唤醒引脚配置为正确的极性并进入关机状态。我们的电路板在深度睡眠状态下消耗约 1 mA 电流。 我认为造成电流消耗过大的原因是，有时当我们重置主 CPU（Cortex-M33）时，Wi-Fi CPU/无线电会处于活动状态，消耗约 56 mA 的电流。由于我们的睡眠/签到间隔为 1 小时，因此电池消耗 56 mAh 电量。我特别向 NXP 询问了 CPU 和无线电是如何重置的，这似乎证实了__NVIC_SystemReset()仅重置 Cortex-M33，而不会重置其他处理器。今天早上，我在我们的主板启动函数中加入了两行代码： /* Ensure that the radios are powered off at startup. Thus, if we go * directly into power-down, this should eliminate the possibility that * the radios are still powered and thus pulling current. */ POWER_PowerOffWlan(); POWER_PowerOffBle(); 我重建了应用程序，然后运行了大约 40 分钟，每次使用 LED 手电筒唤醒进入睡眠状态的电路板。我在测试期间大概唤醒了设备 50 次，其中 50% 进入低功率状态，即没有消耗过多的电流。以前，我只需要几次尝试就可以让系统进入高电流睡眠状态。至此，我认为问题已经解决了。 总之...如果 Wi-Fi 和/或 BLE 堆栈已初始化并正在运行，并且系统已重置或处于看门狗状态，则需要在启动时调用POWER_PowerOffWlan()和/或POWER_PowerOffBle()以确保 Wi-Fi 和 BLE CPU/无线电已关闭。使用 NXP 堆栈启动 Wi-Fi 时，第一步是关闭 Wi-Fi 处理器，然后打开其电源，因此在启动时明确关闭无线电不会干扰 Wi-Fi 堆栈的后续初始化。 达娜·M. 回复：RW612 - PM4 深度睡眠间歇性消耗高电流 您使用的 SDK 是什么版本？ 我使用 SDK v2.16.1 生成了我们的项目。我已经下载了 SDK 24.12（2025-01-15），但我还没有尝试将它应用到这个项目中，因为 MCUXpresso 喜欢在添加或升级组件时使项目无法使用。 您是否在未进行修改的 SDK 示例中看到过这种行为？ 在我们对 SDK 示例进行的非常有限的测试中，没有发生这种情况。 我们可以使用 SDK 示例重现此行为吗？ 可能不是。 需要做哪些改变？ 向示例中添加 FreeRTOS、Wi-Fi 驱动程序、lwIP 网络和 AWS 客户端堆栈。 您能在我们的 FRDM 中看到这种行为吗？ 安装一块 FRDM 板使其能够像我们的定制板一样工作需要付出相当大的努力，但这是可以做到的。 达娜·M.

imx8mp DTS 構成 (2 レーンカメラ用) IMX8MPのCSIポート0に2レーンのMIPI接続があります。 データをキャプチャすることはできますが、画像はゴミであり、解決しようとしています。 私は次のDTS構成を持っています: &cameradev { status = "okay"; cap_device { status = "okay"; }; }; &i2c3 { status = "okay"; lvds_bridge { reg = <0x5A>; status = "okay"; compatible = "lt9211c"; #address-cells = <0x1>; #size-cells = <0x0>; port { lt9211c_ep: endpoint { data-lanes = <1 2>; clock-lanes = <0>; bus-type = <4>; clock-noncontinuous = <1>; remote-endpoint = <&mipi_csi0_ep>; clock-frequency = <74250000>; // Pixel clock in Hz (74.25 MHz) hsync-active = <0>; // Sync polarity vsync-active = <0>; pclk-sample = <1>; // Sample on rising edge }; }; }; }; &isi_0 { status = "okay"; cap_device { status = "okay"; }; m2m_device { status = "disabled"; }; }; &isi_1 { status = "disabled"; cap_device { status = "okay"; }; }; &mipi_csi_0 { status = "okay"; #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; mipi_csi0_ep: endpoint { remote-endpoint = <&lt9211c_ep>; data-lanes = <2>; csis-hs-settle = <4>; csis-clk-settle = <2>; csis-wclk; bus-type = <4>; /* 4 = MIPI CSI-2 D-PHY */ }; }; }; これで、mipi_csi0_ep: エンドポイントで data-lanes=<2> が確認できます。 CSI ドライバ imx8-mipi-csi2-sam.cには、これらのデータレーンを解析するための次の行があります。 of_property_read_u32(node, "data-lanes", &state->num_lanes); したがって、2つのデータレーンを正しく解析できます。 ただし、カーネルログには次のように表示されます。 [ 143.134848] mc: media_release: Media Release [ 149.819027] mxc-mipi-csi2.0: mipi_csis_imx8mp_phy_reset: bus fmt is 12 bit ! [ 149.843365] Parent device name: 32e00000.isi [ 149.869847] Parent device name: 32e00000.isi [ 150.889587] mxc-mipi-csi2.0: mipi_csis_imx8mp_phy_reset: bus fmt is 12 bit ! この警告は、function() の CSI ドライバーからphy_reset /* temporary place */ if (state->mix_gpr) { if ((format.format.code == MEDIA_BUS_FMT_SRGGB8_1X8) || (format.format.code == MEDIA_BUS_FMT_SGRBG8_1X8) || (format.format.code == MEDIA_BUS_FMT_SGBRG8_1X8) || (format.format.code == MEDIA_BUS_FMT_SBGGR8_1X8)) { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW8); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 8 bit!\n", __func__); } else if ((format.format.code == MEDIA_BUS_FMT_SRGGB10_1X10) || (format.format.code == MEDIA_BUS_FMT_SGRBG10_1X10) || (format.format.code == MEDIA_BUS_FMT_SGBRG10_1X10) || (format.format.code == MEDIA_BUS_FMT_SBGGR10_1X10)) { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW10); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 10 bit !\n", __func__); } else { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW12); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 12 bit !\n", __func__); } goto write_regmap; } 最初のIF条件に以下を追加して8ビットに強制しようとしましたが、問題は解決しませんでした。 (format.format.code == MEDIA_BUS_FMT_SGRBG8_1X24) || 誰かが明確にすることができます、ここで正しい方法は何ですか?

GD3162ゲートドライバ こんにちはNXPの、 DESAT_LED(リーディングエッジブランキング時間)とDESATフィルタ時間の違いを明確にしてください。DESA_LEBがVdsがオンになるプログラム可能な時間を指すようにするためですか?

如何找到MW6S004NT1的AWR型号？ 你好，我正在做一个功率放大器的设计，需要用到MW6S004N1这个型号，但是在网站上没有找到AWR的型号。

How to find the AWR model of the MW6S004NT1? Hello, I am doing a power amplifier design, I need to use the MW6S004N1 model, but I did not find the AWR model on the website. Re: How to find the AWR model of the MW6S004NT1? HI Kostiantyn Okay, you can find the AWR models on our official website. Unfortunately, we do not have the AWR model for the device you want. It is necessary to contact an external page to access the model. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck.

尝试使用 RPI_CAM 时，无法在 FRDM im93 板的默认映像上使用 ap1302 固件 我正在尝试在 FRDM imx-93 开发板中预装的 NXP Go point 上运行演示。为此，我从 ONSEMI github repo 9 下载了 ap1302 固件，如 Board User Manual Rev. 1.0 中所述。我已将固件文件重命名并放置在 /lib/firmware/imx/camera/ 路径中。当连接 RPI-CAM-MIPI 时，我无法与相机连接，并且在尝试运行 GoPoint 演示进行视频测试或对象分类时没有收到任何反馈。 我尝试使用 UM 中 ONSEMI github 链接上提供的所有 3 个固件，但得到的结果相同。 $dmesg | grep ap1302 的输出作为图像附加。 FRDM 培训 动手实践培训 回复：尝试使用 RPI_CAM 时，无法在 FRDM im93 板的默认映像上使用 ap1302 固件 你好@Aditya_Vashista 您解决了这个问题吗？我也在同一块板上工作并面临同样的问题。

GD3162栅极驱动器 你好，恩智浦， 请澄清 DESAT_LED（前沿消隐时间和 DESAT 滤波时间）之间的区别。DESA_LEB 是否指的是 Vds 开启后的可编程时间？

How to use stdfix.h in my project(s12z series, CW 11.1) Hello all. I'm beginner with nxp s12z and CW 11.1. I want to use "stdfix.h". But there is some problem with include stdfix.h. 1. I cannot found "stdfix.h" file anywhere my directory(C:\Freescale\). 2. I downloaded "stdfix.h" and copied at "C:\Freescale\CW MCU v11.1\MCU\S12lisa_Support\s12lisac\include". And then, I can include "stdfix.h" but I cannot use library function(e. bitsr(), rbits(), ...). I can see the error messaege when I compiled my project "function has no prototype". I included the Search System Path of Access Path of S12Z Compiler,    "${MCUToolsBaseDir}/S12lisa_Support/s12lisac/include"   "${MCUToolsBaseDir}/S12lisa_Support/s12lisac/src"   "${MCUToolsBaseDir}/S12lisa_Support/s12lisac/lib_medium" Libraries of Input of S12Z Linker  "${MCUToolsBaseDir}/S12lisa_Support/s12lisac/lib_medium/ansii.lib"    Please help me to I can include/use "stdfix.h" correctly. Best Regards. Re: Hi, Re: How to use stdfix.h in my project(s12z series, CW 11.1) Thank you. I'll try it. 🙂 Hi, Re: How to use stdfix.h in my project(s12z series, CW 11.1) Hi,  unfortunately stdfix is not supported in CodeWarior. For fixed point arithmetic you can use AMMCLib which is default part of installation. AMMCLib is located in "${MCUToolsBaseDir}/S12lisa_Support/ folder. 

AMCLIB_ACIMRotFluxObsrv input parameters We have a three-phase induction machine (IM), of which we want to know the following motor parameters: Rs:            stator resistance [Ohm] Ls:             stator inductance [Henry] Lm:           magnetizing inductance [Henry] Rr:             rotor resistance [Ohm] Lr:              rotor inductance [Henry] For sensorless control of the IM, we use the AMCLIB_ACIMRotFluxObsrv and AMCLIB_ACIMSpeedMRAS. Rs and Ls are measured and verified - thus certain. However, executing the no-load and blocked-rotor test results in Lm >> Lr, Ls (magnetizing inductance greater than the product of stator- and rotor-inductance), which seems legit comparing to other papers and/or results found online. However, fltKrLsTotLeakGain from the AMCLIB_ACIMRotFluxObsrv ends up to be a negative gain in this way as the formula is: ((Lr * Ls) - Lm^2) / Lm This seems to be faulty? Because a negative gain will not work out. What could be a possible cause? We use an MKV58 on a custom PCB. So no specif MBDT.  Re: AMCLIB_ACIMRotFluxObsrv input parameters Hello, both functions (AMCLIB_ACIMRotFluxObsrv_FLT  and AMCLIB_ACIMSpeedMRAS_T_FLT ) have own P and I gains of the PI controllers that purpose is to make minimal the input errors. The P and I gains must be set by user before the function usage. In case of AMCLIB_ACIMRotFluxObsrv_FLT function there are two controllers compensating the Alpha and Beta flux components between stator and rotor model estimations. The alpha and beta controllers share the P and I gains. In case of AMCLIB_ACIMSpeedMRAS_T_FLT function there is only one PI controller for raw mechanical speed. We do not have any motor control tuning tool for ACIM, so it is necessary to tune the application manually or by the trial-and-error. For more information about ACIM tuning here are the documentation should help you. Re: AMCLIB_ACIMRotFluxObsrv input parameters Hello @pavelrech , As a follow-up question, for the AMCLIB_ACIMRotFluxObsrv_FLT the sCtrl.PGain and sCtrl.IGain as well as for the AMCLIB_ACIMSpeedMRAS_T_FLT the sCtrl.fltPGain and sCtrl.IGain are given some arbitrary relatively large value without any description in terms of where these gains are based on. Is this arbritrary trial-and-error / manual tuning or can these be properly set? Kind Regards, Re: AMCLIB_ACIMRotFluxObsrv input parameters Hello, I investigated the AMCLIB_ACIMRotFluxObsrv function calculations with negative fltKrLsTotLeakGain parameter. The AMCLIB_ACIMRotFluxObsrv will work as expected with negative fltKrLsTotLeakGain, it can change the sPsiRotSAlBe alpha and beta components. Even the documentation claims the fltKrLsTotLeakGain parameter shall be non-negative value from code perspective this parameter can be negative without function degradation (AMCLIB_ACIMRotFluxObsrv was tested with positive fltKrLsTotLeakGain only to cover most common ACIMs). Function AMCLIB_ACIMSpeedMRAS does not use the fltKrLsTotLeakGain.

MBDT Example s32k37x_s32k39x_can_receive_s32ct not working on S32K396-BGA-DC1 Evaluation Board Hello, I'm trying to receive a CAN message on S32K396-BGA-DC1 Evaluation Board. I successfully ran the s32k37x_s32k39x_can_transmit_ebt example, so I can receive CAN message from the board. Thus, i guess that my hardware setup is correct. However, running the s32k37x_s32k39x_can_receive_s32ct example, D33 LED does not turn on when I send a message to the board. I'm using two Peak PCAN USB adapters, the frame from the board is received by both my PCANs. The frame i'm sending is from a PCAN is seen by the other PCAN but not by the board. I did check configuration Rx/Tx pins are set as in the board user guide (PTC23: Rx / PTC21 : Tx) Controller is not in loopback mode I have some CanHardwareObjects set as receiver with Id filtering disabled (Filter mask 0 = accept all frames) Can someone help with this ? Thank you Best regards Vincent Re: MBDT Example s32k37x_s32k39x_can_receive_s32ct not working on S32K396-BGA-DC1 Evaluation Board Hello @Vincent_91687  MBDT integrates the RTD (Real-Time Drivers) for configuration and access to the hardware (peripherals, pins, clocks, interrupts). For more details on configuration parameters, and functions implemented by our blocks, you could check the RTD User Manual for the component you would like to use, and also the AUTOSAR driver standard (RTD MCAL layer is AUTOSAR compatible). For CAN, and other blocks as well, you could access this documentation I am referring to by clicking on the Help button of the Simulink block, and navigating to the Code Generation section, like illustrated below. For configuration examples, you could check the configuration projects that we are delivering together with our application examples.  Moreover, in case of the ADC, PWM, CAN, UART and DIO, we have also put together some articles on our MBDT NXP Community, that provide a more detailed insight into the available parameters, and settings. Maybe you would find them useful as well. Here is the link to the CAN one, but the others are available under the Beginner's Guide for Model-Based Design Toolbox section on our main page. Hope this helps you. Please let us know in case additional information is required. Thanks, Irina Re: MBDT Example s32k37x_s32k39x_can_receive_s32ct not working on S32K396-BGA-DC1 Evaluation Board Hello Irina, It works ! Thank you for the link, this is very helpful. More generaly, is there a reference document (like a PDF) describing all options and configurations available in S32 Configuration Tool for the S32K396 MCU ? I had a look on NXP web site but i didn't find it. Do I need a "granted" account for this ? Thank you very much for your help Best regards Vincent Re: MBDT Example s32k37x_s32k39x_can_receive_s32ct not working on S32K396-BGA-DC1 Evaluation Board Hi @Vincent_91687  Could you please try and send frames with EXTENDED Id option enabled inside your Can analyzer software and let us know if this works? From what I am noticing from the configuration project, all the Receive hardware objects are configured with Can ID Message Type set as EXTENDED. For being also to also receive STANDARD frames, you should change the option to STANDARD. For more details on this topic, could you please consult the following thread? A detailed explanation on the hardware objects, EXTENDED/STANDARD frame types, and the available options, is provided in this thread, which you might find helpful. https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/S32K312-CAN-configuration/m-p/2044459#M9983 Hope this helps, Irina     Re: MBDT Example s32k37x_s32k39x_can_receive_s32ct not working on S32K396-BGA-DC1 Evaluation Board Hi Irina, Thanks for your help. I confirm that i'm using the same Configuration Project Template  By the way, the s32k37x_s32k39x_can_transmit_ebt model example is also toggling D33 LED on frame transmission event. Using the same config template with this model, i can see the LED going on and off and the message is transmitted To dig a bit further, i have exported the model source code to S32 Design Studio and run the code in debug It appears that the code never enter in the "CanIf_RxIndication" function (the function setting the LED), like if the interrupt never is never fired. Call hierarchy of "CanIf_RxIndication" brings me to "Can_43_FLEXCAN_MainFunction_Read" in which we never enter either, explaining why interrupt is never fired In fact, at any time I stop the code, we are in while (runModel) { } Thanks Vincent Re: MBDT Example s32k37x_s32k39x_can_receive_s32ct not working on S32K396-BGA-DC1 Evaluation Board Hi @Vincent_91687  I have tried it on my own setup, and I managed to receive CAN messages from my CAN analyzer. Could you please check if you have selected the BGA-DC1 configuration in your model, like illustrated below? The reason why the LED is not blinking could be related to the fact that, on the BGA-DC1, the pin routed to the D33 BLUE LED is different than the one configured in the default configuration project that we provide for the S32K396 processor. Changing the Configuration Project Template to address the DC1 board might solve the issue you are currently encountering. Please let us know if this helps, Irina Re: MBDT Example s32k37x_s32k39x_can_receive_s32ct not working on S32K396-BGA-DC1 Evaluation Board Hello, Thanks for your help. Please find attached the model i'm trying to run. Model is saved in Matlab 2023b version. Best regards Vincent Re: MBDT Example s32k37x_s32k39x_can_receive_s32ct not working on S32K396-BGA-DC1 Evaluation Board Hi@Vincent_91687 Can you provide us with this routine：s32k37x_s32k39x_can_receive_s32ct (I'm sorry I don't know if we have such a routine), I will take the time to check it for you.

imx8mp DTS configuration for 2-lane camera I have a 2-lane MIPI connection on CSI port 0 of IMX8MP. I am able to capture the data, however the image is garbage and I am trying to resolve it. I have following DTS configuration: &cameradev { status = "okay"; cap_device { status = "okay"; }; }; &i2c3 { status = "okay"; lvds_bridge { reg = <0x5A>; status = "okay"; compatible = "lt9211c"; #address-cells = <0x1>; #size-cells = <0x0>; port { lt9211c_ep: endpoint { data-lanes = <1 2>; clock-lanes = <0>; bus-type = <4>; clock-noncontinuous = <1>; remote-endpoint = <&mipi_csi0_ep>; clock-frequency = <74250000>; // Pixel clock in Hz (74.25 MHz) hsync-active = <0>; // Sync polarity vsync-active = <0>; pclk-sample = <1>; // Sample on rising edge }; }; }; }; &isi_0 { status = "okay"; cap_device { status = "okay"; }; m2m_device { status = "disabled"; }; }; &isi_1 { status = "disabled"; cap_device { status = "okay"; }; }; &mipi_csi_0 { status = "okay"; #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; mipi_csi0_ep: endpoint { remote-endpoint = <&lt9211c_ep>; data-lanes = <2>; csis-hs-settle = <4>; csis-clk-settle = <2>; csis-wclk; bus-type = <4>; /* 4 = MIPI CSI-2 D-PHY */ }; }; }; Now you can see that data-lanes=<2> in mipi_csi0_ep: endpoint.  CSI driver imx8-mipi-csi2-sam.c has the following line to parse these data-lanes: of_property_read_u32(node, "data-lanes", &state->num_lanes); Thus it is able to parse the 2 data lanes correctly. However I see the following in the kernel logs: [ 143.134848] mc: media_release: Media Release [ 149.819027] mxc-mipi-csi2.0: mipi_csis_imx8mp_phy_reset: bus fmt is 12 bit ! [ 149.843365] Parent device name: 32e00000.isi [ 149.869847] Parent device name: 32e00000.isi [ 150.889587] mxc-mipi-csi2.0: mipi_csis_imx8mp_phy_reset: bus fmt is 12 bit ! This warning comes from CSI driver in phy_reset function() /* temporary place */ if (state->mix_gpr) { if ((format.format.code == MEDIA_BUS_FMT_SRGGB8_1X8) || (format.format.code == MEDIA_BUS_FMT_SGRBG8_1X8) || (format.format.code == MEDIA_BUS_FMT_SGBRG8_1X8) || (format.format.code == MEDIA_BUS_FMT_SBGGR8_1X8)) { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW8); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 8 bit!\n", __func__); } else if ((format.format.code == MEDIA_BUS_FMT_SRGGB10_1X10) || (format.format.code == MEDIA_BUS_FMT_SGRBG10_1X10) || (format.format.code == MEDIA_BUS_FMT_SGBRG10_1X10) || (format.format.code == MEDIA_BUS_FMT_SBGGR10_1X10)) { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW10); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 10 bit !\n", __func__); } else { mipi_csis_imx8mp_dewarp_ctl_data_type(state, ISP_DEWARP_CTRL_DATA_TYPE_RAW12); v4l2_dbg(1, debug, &state->sd, "%s: bus fmt is 12 bit !\n", __func__); } goto write_regmap; } I tried to add the following to the first IF condition to force it to 8-bit and it did not solve any of my problem. (format.format.code == MEDIA_BUS_FMT_SGRBG8_1X24) || Can someone please clarify, what is the right way here? Re: imx8mp DTS configuration for 2-lane camera Hello, For that issue one can try to adjust clocks clocks and HSSETTLE parameter in imx8mn-evk.dts (hs-settle) https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Setting-i-MX8M-Mini-and-Nano-MIPI-DPHY-C... For testing please use Chapter 6. Camera Examples below document https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-GStreamer-User-Guide/ta-p/1098942  regards

Unable to ap1302 firmware on default image for FRDM im93 board when trying to use RPI_CAM I am trying to run the demos on NXP Go point which comes pre-installed in the FRDM imx-93 development board. For that i have downloaded the ap1302 firmware from ONSEMI github repo 9as mentioned in Board User Manual Rev. 1.0. I have renamed and placed the firmware file in /lib/firmware/imx/camera/ path as well.  When connecting RPI-CAM-MIPI, i am not able to interface with the camera and getting no feed when trying to run GoPoint demos for video test or object classification. I have tried using all 3 firmwares, available on ONSEMI github link in UM, but getting the same results.  Output of $dmesg | grep ap1302, is attached as image. FRDM-Training Hands-On Training Re: Unable to ap1302 firmware on default image for FRDM im93 board when trying to use RPI_CAM Hi @Abisha, Yes, the solution provided resolved the issue. Re: Unable to ap1302 firmware on default image for FRDM im93 board when trying to use RPI_CAM Hi @Aditya_Vashista  Have you resolved this issue? I am also working on the same board and facing the same problem. Re: Unable to ap1302 firmware on default image for FRDM im93 board when trying to use RPI_CAM Hi @Aditya_Vashista! Thank you for contacting NXP Support! You should download the "ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin" file from the ON Semiconductor github page, rename the file to "ap1302.fw" and save the file in  "/lib/firmware/imx/camera/" After that you have to reboot your board and corroborate that the camera is working with the next command: $ gst-launch-1.0 -v v4l2src device=/dev/video0 ! "video/x-raw,format=YUY2,width=1280,height=800" ! queue ! waylandsink I have tried those steps by my side and is working  without problems. Best Regards! Chavira

Writing QSPI Flash on MCXN947 board. The other day I asked a question about writing flash to FRDM-MCXN947. Thanks to your answer, I am now able to write to FRDM-MCXN947. Thank you. This time I would like to ask a question about writing flash to another board using MCXN947. I tried to write to this board using the writing method for FRDM-MCXN947 as a reference, but an error occurred. Below is the content of the console at that time. NXP: MCXN947 DAP stride is 1024 bytes (256 words) Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI.cfx Image 'MCXN9xx_SFDP_FlexSPI Sep 19 2024 18:18:31' Opening flash driver MCXN9xx_SFDP_FlexSPI.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Driver V.2 dynamic startup failed - driver Init provided no flash parameters driver describes no sectors starting at 0x80000000 Flash Driver V.2 startup failed - rc Ef(58): Flash Driver describes no sectors at its base address chip initialization failed - Ef(58): Flash Driver describes no sectors at its base address failed to initialize flash driver MCXN9xx_SFDP_FlexSPI.cfx Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI.cfx Image 'MCXN9xx_SFDP_FlexSPI Sep 19 2024 18:18:31' Opening flash driver MCXN9xx_SFDP_FlexSPI.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Driver V.2 dynamic startup failed - driver Init provided no flash parameters driver describes no sectors starting at 0x80000000 Flash Driver V.2 startup failed - rc Ef(58): Flash Driver describes no sectors at its base address chip initialization failed - Ef(58): Flash Driver describes no sectors at its base address failed to initialize flash driver MCXN9xx_SFDP_FlexSPI.cfx Is there any setting or anything I need to do? I would appreciate your reply. MCXN Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. Understood. I have posted the question below, so please reply there. https://community.nxp.com/t5/MCX-Microcontrollers/Writing-to-the-QSPI-Flash-of-MCXN947-using-write-image-win-bat/m-p/2083513#M2906  Best regards Re: Writing QSPI Flash on MCXN947 board. Hi @takagi_y  We have already resolved the previous issue. For this question, I suggest you create a new one in the community. We will do our best to support you. Thank you for your understanding. BR Harry Re: Writing QSPI Flash on MCXN947 board. In this thread, I have asked a question about not being able to write using write_image_win.bat, but this has not yet been resolved. I would like to summarize the current situation. - When writing to a brand new board using a bat file, the process that should say "Erase memory before writing image" is displayed as "failed." - Boards that have already been written to using the SEC tool can be written to using the bat file. The following are the questions I would like to ask. 1. Why can't I write to a brand new board using a bat file? 2. Is there anything I need to do to write to a brand new board using a bat file? 3. Is there a difference between a board that has already been written to using the SEC tool and a brand new board? Please answer. Best regards Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. Using the method you taught me, I can now write from the IDE. Thank you. I have one more question. During the board manufacturing process, I would like to use write_image_win.bat to write to the flash. So I tried to write the file that I was able to write from the IDE using the SEC tool's write_image_win.bat. However, although I was able to write to the board I had been using for testing, when I tried to write to a new board, the Erase flash failed. I would also like to use write_image_win.bat to write to the flash on the i.MX RT1021 and i.MX RT1062 custom boards, but the erasure fails on new boards, just like with the MCXN947. Is there any solution, such as adding a wait time between each process? I have attached the log of when I wrote to the MCXN947. ### Parse input arguments ### ### Check connection ### blhost -t 2000 -u 0x1FC9,0x014F -j -- get-property 1 0 { "command": "get-property", "response": [ 1258488320 ], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded ### Configure FlexSPI NOR using FCB on address 0x20020000 ### blhost -t 5000 -u 0x1FC9,0x014F -j -- write-memory 0x20020000 "C:\WorkSpace\MCUX\MCUXpressoSecureProvisioningv10\NX-N947_20250410\source_images\frdmmcxn947_led_blinky.fcb.bin" { "command": "write-memory", "response": [ 512 ], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded blhost -t 5000 -u 0x1FC9,0x014F -j -- configure-memory 9 0x20020000 { "command": "configure-memory", "response": [], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded ### Erase flash ### blhost -t 50091 -u 0x1FC9,0x014F -j -- flash-erase-region 0x80000000 9132 0 { "command": "flash-erase-region", "response": [], "status": { "description": "20106 (0x4e8a) FlexSPINOR: Command Failure.", "value": 20106 } } blhost failed Best regards Re: Writing QSPI Flash on MCXN947 board. Hi @takagi_y  You can write from the SEC tool, this proves that the FCB produced by SEC is correct. So i think you can flash the correct FCB to 0x80000400. And then delete mcxn_flexspi_nor_config.c and mcxn_flexspi_nor_config.h in MCUXpresso. Because they generate the NEW FCB and flash in 0x80000400. And you can debug it. I tested, i generate the FCB.bin through the SEC tool. and flash it into 0x80000400. And i can debug it successfully. To summarize, put the correct FCB into 0x80000400, and put the correct application into 0x80001000. BR Harry Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. I can write from the SEC tool, but I cannot write from MCUXpresso IDE. I think there is some reason why I cannot write from MCUXpresso IDE, but I don't know what it is. Could you give me some advice? Best regards Re: Writing QSPI Flash on MCXN947 board. Hi @takagi_y  Yes, your analysis is correct. If writing can be done from the SEC tool. This proves that there is no issue with the hardware. Previously, you verified that your software had no issues with FRDM mcxn947, and now you have verified that your hardware has no issues with SEC tool, so can you work now? BR Harry Re: Writing QSPI Flash on MCXN947 board. I have an additional question. The PSRAM is electrically isolated, and in this state, writing can be done from the SEC tool. If writing is done from the IDE in the same state, it fails. If the PSRAM is affecting it, I think writing cannot be done with the SEC tool either. What do you think? Best regards Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. Since the CEn of the PSRAM is fixed at the H level, I believe that the DATA and CLOCK of the PSRAM do not affect the QSPI Flash. Are there any other possible causes? Best regards Re: Writing QSPI Flash on MCXN947 board. Hi @takagi_y  "As you suggested, I replaced the Flash of FRDM-MXN947 with MX25L3233 and checked. I was able to write when I used the same mcxn_flexspi_nor_config.c as the one I uploaded the other day and FlashConfig.h with CONFIG_OPTION0 set to 0xC0000101." This proves that your software configuration is fine. So I think it's still a hardware issue. Can you try connecting to Nor Flash only? Disconnect the PSRAM related electrically(including DATA CLOCK CS). BR Harry Re: Writing QSPI Flash on MCXN947 board. We have confirmed the following regarding this issue and would like to inform you of the issue. We suspected that the PSRAM may be affecting the circuit, so we opened JP1 in the circuit diagram uploaded yesterday and checked with the PSRAM electrically disconnected, but we were unable to write to the Flash. If you have any advice, including about yesterday's post, we would appreciate it. Best regards Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. As you suggested, I replaced the Flash of FRDM-MXN947 with MX25L3233 and checked. I was able to write when I used the same mcxn_flexspi_nor_config.c as the one I uploaded the other day and FlashConfig.h with CONFIG_OPTION0 set to 0xC0000101. However, I cannot write on my board even when I use the same file. On my board, I use port A in INDIVIDUAL mode, so SS0_b is connected to MX25L3233 and SS1_b is connected to PSRAM, but I wonder if PSRAM is affecting it. I have attached a circuit diagram showing the connection of Flash and PSRAM. If you have any comments, please give me some advice.   Also, I have set the Memory configuration editor as follows. The flash size is set to 0xffff000, but since I'm using a 4MByte product, I think 0x3ff000 is correct. Will this size setting affect flash writing? Best regards Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. We will consider your reply. Also, on my board, FLEXSPI0_A_SS0_b is connected to MX25L3233, but FLEXSPI0_A_SS1_b is connected to PSRAM. The same terminal is used for FLEXSPI0_A_SCLK and FLEXSPI0_A_DATA0-3 of the two chips. Do you think that this state will affect the writing of the flash? Best regards Re: Writing QSPI Flash on MCXN947 board. Hi @takagi_y  Have we considered hardware connectivity issues? Are you a custom board？ If you are a custom board, can you connect this flash to FRDM-MXN947? And try again. If the flash still cannot work when connected to FRDM-MXN947. I will buy this flash and test it. BR Harry Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. I have only modified the two files you mentioned, but the error still occurs. I will upload the files I am using and the error message. I cannot identify the reason why the Flash Driver V2 fails to start, so please give me some advice. mcxn_flexspi_nor_config.c In this file, the value of sflashA1Size has been changed from 8M to 4M. /* * Copyright 2018-2022 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ #include "mcxn_flexspi_nor_config.h" /* Component ID definition, used by tools. */ #ifndef FSL_COMPONENT_ID #define FSL_COMPONENT_ID "platform.drivers.xip_board" #endif /******************************************************************************* * Code ******************************************************************************/ #if defined(__CC_ARM) || defined(__ARMCC_VERSION) || defined(__GNUC__) __attribute__((section(".flexspi_fcb"), used)) #elif defined(__ICCARM__) #pragma location = ".flexspi_fcb" #endif #ifndef FLEXSPI_USE_CUSTOM_FCB #define FLEXSPI_USE_CUSTOM_FCB (0) #endif #if FLEXSPI_USE_CUSTOM_FCB /* FCB for W25Q64 */ const uint8_t CUSTOM_FCB[] = { 0x46, 0x43, 0x46, 0x42, 0x00, 0x04, 0x01, 0x56, 0x00, 0x00, 0x00, 0x00, 0x01, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x01, 0x04, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xeb, 0x04, 0x18, 0x0a, 0x06, 0x32, 0x04, 0x26, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x04, 0x04, 0x24, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x04, 0x18, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xd8, 0x04, 0x18, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x04, 0x18, 0x08, 0x04, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x60, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; #else /* FCB for W25Q64 */ const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad, .csHoldTime = 3u, .csSetupTime = 3u, // Enable DDR mode, Wordaddassable, Safe configuration, Differential clock .controllerMiscOption = (1u << kFlexSpiMiscOffset_SafeConfigFreqEnable), .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_75MHz, .sflashA1Size = 4u * 1024u * 1024u, .lookupTable = { // Read LUTs [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x18), [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06, READ_SDR, FLEXSPI_4PAD, 0x04), // Read Status LUTs [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), // Write Enable LUTs [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0), // Erase Sector LUTs [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x20, RADDR_SDR, FLEXSPI_1PAD, 0x18), // Erase Block LUTs [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xD8, RADDR_SDR, FLEXSPI_1PAD, 0x18), // Pape Program LUTs [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x02, RADDR_SDR, FLEXSPI_1PAD, 0x18), [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0), // Erase Chip LUTs [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x60, STOP, FLEXSPI_1PAD, 0x0), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .ipcmdSerialClkFreq = 1u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, }; #endif FlashConfig.h I created four different versions of this file with different values ​​for CONFIG_OPTION0. (0xC0000001, 0xC0000405, 0xC0000401, 0xC0000101) I have used each one to check. //***************************************************************************** // FlashConfig.h // MCUXpresso IDE Flash driver // Config file for MCXN9xx FlexSPI driver //***************************************************************************** // // Copyright 2022-2024 NXP // // SPDX-License-Identifier: BSD-3-Clause //***************************************************************************** #ifndef FLASHCONFIG_H_ #define FLASHCONFIG_H_ #include "fsl_flexspi_nor_flash.h" extern flexspi_nor_config_t flashConfig; #if defined (DEBUG) #define MCXN9xx_SFDP_FlexSPI #endif // MCX N1xNxxx Reference Manual - 15.4.2 FlexSPI NOR Configuration Option Block #if defined (MCXN9xx_SFDP_FlexSPI) || defined (MCXN9xx_SFDP_FlexSPI_S) /* * 0xC : tag * 0 : option_size (0 = option1 not specified) * 0 : device_type (0 = Read SFDP for SDR commands) * 0 : query_pads (0 = 1 data pad during query) * 0 : cmd_pads (0 = 1 data pad during flash access) * 0 : quad_mode_setting (0 = not configured) * 0 : misc_mode * 1 : max_freq (0 = Don't change FlexSPI clock setting) */ #define CONFIG_OPTION0 0xC0000001 //#define CONFIG_OPTION0 0xC0000405 //#define CONFIG_OPTION0 0xC0000401 //#define CONFIG_OPTION0 0xC0000101 /* * 0x0 : Single Flash connected to Port A */ #define CONFIG_OPTION1 0x00000000 #endif // ===================================== // Flash Base Address Information // ===================================== #if defined (MCXN9xx_SFDP_FlexSPI_S) #define USE_SECURE_FLASHADDR #define FLASH_BASE_ADDR 0x90000000 #else #define FLASH_BASE_ADDR 0x80000000 #endif #endif /* FLASHCONFIG_H_ */ When 0xC0000001 is used for CONFIG_OPTION0, the following Console A is displayed on the Console, and when not, Console B is displayed. Console A MCUXpresso IDE RedlinkMulti Driver v24.9 (Sep 19 2024 19:34:05 - crt_emu_cm_redlink build 802) Found chip XML file in C:/WorkSpace/MCUX/MCUXpressoIDE_24.9.25/NX-N947/NX-N947_ledblinky/frdmmcxn947_led_blinky/Debug_NoRAM\MCXN947.xml ( 5) Remote configuration complete Reconnected to existing LinkServer process. Probe Firmware: MCU-LINK (r0FF) CMSIS-DAP V3.153 (NXP Semiconductors) Serial Number: VUDADS0NIE0ZM VID:PID: 1FC9:0143 USB Path: 0001:0003:00 Using memory from core 0 after searching for a good core processor is in secure mode debug interface type = CoreSight DP (DAP DP ID 6BA02477) over SWD TAP 0 processor type = Cortex-M33 (CPU ID 00000D21) on DAP AP 0 number of h/w breakpoints = 8 number of flash patches = 0 number of h/w watchpoints = 4 Probe(0): Connected&Reset. DpID: 6BA02477. CpuID: 00000D21. Info: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled. Content of CoreSight Debug ROM(s): RBASE E00FE000: CID B105100D PID 0000095000 ROM (type 0x1) ROM 1 E00FF000: CID B105100D PID 04000BB4C9 ROM (type 0x1) ROM 2 E000E000: CID B105900D PID 04000BBD21 CSt ARM ARMv8-M type 0x0 Misc - Undefined ROM 2 E0001000: CID B105900D PID 04000BBD21 CSt ARM DWTv2 type 0x0 Misc - Undefined ROM 2 E0002000: CID B105900D PID 04000BBD21 CSt ARM FPBv2 type 0x0 Misc - Undefined ROM 2 E0000000: CID B105900D PID 04000BBD21 CSt ARM ITMv2 type 0x43 Trace Source - Bus ROM 2 E0041000: CID B105900D PID 04002BBD21 CSt ARM ETMv4.0 type 0x13 Trace Source - Core ROM 2 E0042000: CID B105900D PID 04000BBD21 CSt ARM CTIv2 type 0x14 Debug Control - Trigger, e.g. ECT ROM 1 E0040000: CID B105900D PID 04000BBD21 CSt type 0x11 Trace Sink - TPIU ROM 1 E0044000: CID B105900D PID 04003BB908 CSt CSTF type 0x12 Trace Link - Trace funnel/router ROM 1 E0045000: CID B105900D PID 04001BB961 CSt type 0x21 Trace Sink - ETB NXP: MCXN947 DAP stride is 1024 bytes (256 words) Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI_0xC0000001.cfx Image 'MCXN9xx_SFDP_FlexSPI Mar 21 2025 14:26:16' Opening flash driver MCXN9xx_SFDP_FlexSPI_0xC0000001.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Flash variant 'JEDEC_FlexSPI_Device' detected (0B = at 0x80000000) driver describes no sectors starting at 0x80000000 Flash Driver V.2 startup failed - rc Ef(58): Flash Driver describes no sectors at its base address chip initialization failed - Ef(58): Flash Driver describes no sectors at its base address failed to initialize flash driver MCXN9xx_SFDP_FlexSPI_0xC0000001.cfx Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI_0xC0000001.cfx Image 'MCXN9xx_SFDP_FlexSPI Mar 21 2025 14:26:16' Opening flash driver MCXN9xx_SFDP_FlexSPI_0xC0000001.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Flash variant 'JEDEC_FlexSPI_Device' detected (4MB = 64*64K at 0x80000000) Closing flash driver MCXN9xx_SFDP_FlexSPI_0xC0000001.cfx Console B MCUXpresso IDE RedlinkMulti Driver v24.9 (Sep 19 2024 19:34:05 - crt_emu_cm_redlink build 802) Found chip XML file in C:/WorkSpace/MCUX/MCUXpressoIDE_24.9.25/NX-N947/NX-N947_ledblinky/frdmmcxn947_led_blinky/Debug_NoRAM\MCXN947.xml ( 5) Remote configuration complete Reconnected to existing LinkServer process. Probe Firmware: MCU-LINK (r0FF) CMSIS-DAP V3.153 (NXP Semiconductors) Serial Number: VUDADS0NIE0ZM VID:PID: 1FC9:0143 USB Path: 0001:0003:00 Using memory from core 0 after searching for a good core processor is in secure mode debug interface type = CoreSight DP (DAP DP ID 6BA02477) over SWD TAP 0 processor type = Cortex-M33 (CPU ID 00000D21) on DAP AP 0 number of h/w breakpoints = 8 number of flash patches = 0 number of h/w watchpoints = 4 Probe(0): Connected&Reset. DpID: 6BA02477. CpuID: 00000D21. Info: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled. Content of CoreSight Debug ROM(s): RBASE E00FE000: CID B105100D PID 0000095000 ROM (type 0x1) ROM 1 E00FF000: CID B105100D PID 04000BB4C9 ROM (type 0x1) ROM 2 E000E000: CID B105900D PID 04000BBD21 CSt ARM ARMv8-M type 0x0 Misc - Undefined ROM 2 E0001000: CID B105900D PID 04000BBD21 CSt ARM DWTv2 type 0x0 Misc - Undefined ROM 2 E0002000: CID B105900D PID 04000BBD21 CSt ARM FPBv2 type 0x0 Misc - Undefined ROM 2 E0000000: CID B105900D PID 04000BBD21 CSt ARM ITMv2 type 0x43 Trace Source - Bus ROM 2 E0041000: CID B105900D PID 04002BBD21 CSt ARM ETMv4.0 type 0x13 Trace Source - Core ROM 2 E0042000: CID B105900D PID 04000BBD21 CSt ARM CTIv2 type 0x14 Debug Control - Trigger, e.g. ECT ROM 1 E0040000: CID B105900D PID 04000BBD21 CSt type 0x11 Trace Sink - TPIU ROM 1 E0044000: CID B105900D PID 04003BB908 CSt CSTF type 0x12 Trace Link - Trace funnel/router ROM 1 E0045000: CID B105900D PID 04001BB961 CSt type 0x21 Trace Sink - ETB NXP: MCXN947 DAP stride is 1024 bytes (256 words) Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Image 'MCXN9xx_SFDP_FlexSPI Mar 6 2025 18:26:01' Opening flash driver MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Driver V.2 dynamic startup failed - driver Init provided no flash parameters driver describes no sectors starting at 0x80000000 Flash Driver V.2 startup failed - rc Ef(58): Flash Driver describes no sectors at its base address chip initialization failed - Ef(58): Flash Driver describes no sectors at its base address failed to initialize flash driver MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Image 'MCXN9xx_SFDP_FlexSPI Mar 6 2025 18:26:01' Opening flash driver MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Driver V.2 dynamic startup failed - driver Init provided no flash parameters driver describes no sectors starting at 0x80000000 Flash Driver V.2 startup failed - rc Ef(58): Flash Driver describes no sectors at its base address chip initialization failed - Ef(58): Flash Driver describes no sectors at its base address failed to initialize flash driver MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Best regards Re: Writing QSPI Flash on MCXN947 board. Hi @takagi_y  Apart from MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx and  FlashConfig.h, there are no other files that need to be modified. BR Harry Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. I have checked the example you provided. The Flash I want to use is MX25L3233F. The example you provided is for MT35XU512ABA, which is a different model number. The following is an excerpt of the MX25L3233F command, which is the same as the MT35XU512ABA command. It is MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx, but do I need to make any changes other than to FlashConfig.h? Best regards Re: Writing QSPI Flash on MCXN947 board. Hi @takagi_y  Apart from MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx and mcxn_flexspi_nor_config.c, there are no other files that need to be modified. "I compared the data sheets for W25Q64JVSSIQ and MX25L3233F and confirmed that the LUT contents are the same." No, they are different. You can refer to the flexspi_polling example, it includes the LUT of W25Q64JVSSIQ and MX25L3233F. #if EXAMPLE_FLASH_TYPE == FLASH_W25Q64 /* W25Q64JVSSIQ */ const uint32_t customLUTOctalMode[CUSTOM_LUT_LENGTH] = { /* Read data */ [4 * NOR_CMD_LUT_SEQ_IDX_READ] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0xEB, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_4PAD, 0x18), [4 * NOR_CMD_LUT_SEQ_IDX_READ + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_MODE8_SDR, kFLEXSPI_4PAD, 0xF0, kFLEXSPI_Command_DUMMY_SDR, kFLEXSPI_4PAD, 0x04), [4 * NOR_CMD_LUT_SEQ_IDX_READ + 2] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_READ_SDR, kFLEXSPI_4PAD, 0x00, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Read status register */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUS] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x00), /* Write enable */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITEENABLE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x06, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Write enable */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITEENABLE_OPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x06, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Read ID */ [4 * NOR_CMD_LUT_SEQ_IDX_READID_OPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x9F, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x00), /* Sector erase */ [4 * NOR_CMD_LUT_SEQ_IDX_ERASESECTOR] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x20, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), /* Chip erase */ [4 * NOR_CMD_LUT_SEQ_IDX_CHIPERASE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x60, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Page program */ [4 * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x32, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), [4 * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_4PAD, 0x00, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Enter Quad mode */ [4 * NOR_CMD_LUT_SEQ_IDX_ENTEROPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x00), /* Dummy write, do nothing when AHB write command is triggered. */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x0, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x0), /* Read status register using Quad mode */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUS_OPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x00), }; #endif #if EXAMPLE_FLASH_TYPE == FLASH_MT35XU512 /* MT35XU512ABA1G12 */ const uint32_t customLUTOctalMode[CUSTOM_LUT_LENGTH] = { /* OPI DDR read */ [4 * NOR_CMD_LUT_SEQ_IDX_READ] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0xCC, kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0xCC), [4 * NOR_CMD_LUT_SEQ_IDX_READ + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_RADDR_DDR, kFLEXSPI_8PAD, 0x20, kFLEXSPI_Command_DUMMY_DDR, kFLEXSPI_8PAD, 0x0D), [4 * NOR_CMD_LUT_SEQ_IDX_READ + 2] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_READ_DDR, kFLEXSPI_8PAD, 0x00, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Read status register */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUS] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x00), /* Write Enable */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITEENABLE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x06, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Read ID under octal mode */ [4 * NOR_CMD_LUT_SEQ_IDX_READID_OPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x9F, kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x9F), [4 * NOR_CMD_LUT_SEQ_IDX_READID_OPI + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_DUMMY_DDR, kFLEXSPI_8PAD, 0x10, kFLEXSPI_Command_READ_DDR, kFLEXSPI_8PAD, 0x00), /* Write Enable */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITEENABLE_OPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x06, kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x06), /* Erase Sector */ [4 * NOR_CMD_LUT_SEQ_IDX_ERASESECTOR] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x20, kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x20), [4 * NOR_CMD_LUT_SEQ_IDX_ERASESECTOR + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_RADDR_DDR, kFLEXSPI_8PAD, 0x20, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Erase Chip */ [4 * NOR_CMD_LUT_SEQ_IDX_CHIPERASE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x60, kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x60), /* Program */ [4 * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x8E, kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x8E), [4 * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_RADDR_DDR, kFLEXSPI_8PAD, 0x20, kFLEXSPI_Command_WRITE_DDR, kFLEXSPI_8PAD, 0x00), /* Enter OPI mode */ [4 * NOR_CMD_LUT_SEQ_IDX_ENTEROPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x81, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), [4 * NOR_CMD_LUT_SEQ_IDX_ENTEROPI + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_1PAD, 0x00, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x00), /* Dummy write, do nothing when AHB write command is triggered. */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x0, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0x0), /* Read status register using Octal DDR read */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUS_OPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x05, kFLEXSPI_Command_DDR, kFLEXSPI_8PAD, 0x05), [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUS_OPI + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_DUMMY_DDR, kFLEXSPI_8PAD, 0x10, kFLEXSPI_Command_READ_DDR, kFLEXSPI_8PAD, 0x00), }; #endif BR Harry Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. I compared the data sheets for W25Q64JVSSIQ and MX25L3233F and confirmed that the LUT contents are the same. > So you need to change the Flash burning algorithm. > Such as MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Does the above mean that you need to change the code other than CONFIG_OPTION0 and CONFIG_OPTION1 in MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx? Or does it mean that there are other files that need to be modified besides MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx? If other files need to be modified, could you please let me know the files? Best regards Re: Writing QSPI Flash on MCXN947 board. Hi @takagi_y  On FRDM-MCXN947, the Qflash is W25Q64JVSSIQ. On your customer board, the qflash is MX25L3233F. So you need to change the Flash burning algorithm. Such as MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx And in the mcxn_flexspi_nor_config.c Change the LUT BR Harry Re: Writing QSPI Flash on MCXN947 board. Thank you for your reply. I modified the project with reference to the demo program of FRDM-MCXN947 and confirmed writing from IDE. The procedure is as written yesterday under "As additional information...". My board uses MX25L3233F for Flash, so I built an example of CMSIS-DAP Flash Drivers and checked it. First, I used the one I built without any modifications and wrote it from the IDE. (CONFIG_OPTION0=0xC0000001) As a result, the following was displayed on the console and writing was not performed. MCUXpresso IDE RedlinkMulti Driver v24.9 (Sep 19 2024 19:34:05 - crt_emu_cm_redlink build 802) Found chip XML file in C:/WorkSpace/MCUX/MCUXpressoIDE_24.9.25/NX-N947/frdmmcxn947_hello_world_qspi_xip/Debug\MCXN947.xml ( 5) Remote configuration complete Reconnected to existing LinkServer process. Probe Firmware: MCU-LINK (r0FF) CMSIS-DAP V3.153 (NXP Semiconductors) Serial Number: VUDADS0NIE0ZM VID:PID: 1FC9:0143 USB Path: 0001:0008:00 Using memory from core 0 after searching for a good core processor is in secure mode debug interface type = CoreSight DP (DAP DP ID 6BA02477) over SWD TAP 0 processor type = Cortex-M33 (CPU ID 00000D21) on DAP AP 0 number of h/w breakpoints = 8 number of flash patches = 0 number of h/w watchpoints = 4 Probe(0): Connected&Reset. DpID: 6BA02477. CpuID: 00000D21. Info: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled. Content of CoreSight Debug ROM(s): RBASE E00FE000: CID B105100D PID 0000095000 ROM (type 0x1) ROM 1 E00FF000: CID B105100D PID 04000BB4C9 ROM (type 0x1) ROM 2 E000E000: CID B105900D PID 04000BBD21 CSt ARM ARMv8-M type 0x0 Misc - Undefined ROM 2 E0001000: CID B105900D PID 04000BBD21 CSt ARM DWTv2 type 0x0 Misc - Undefined ROM 2 E0002000: CID B105900D PID 04000BBD21 CSt ARM FPBv2 type 0x0 Misc - Undefined ROM 2 E0000000: CID B105900D PID 04000BBD21 CSt ARM ITMv2 type 0x43 Trace Source - Bus ROM 2 E0041000: CID B105900D PID 04002BBD21 CSt ARM ETMv4.0 type 0x13 Trace Source - Core ROM 2 E0042000: CID B105900D PID 04000BBD21 CSt ARM CTIv2 type 0x14 Debug Control - Trigger, e.g. ECT ROM 1 E0040000: CID B105900D PID 04000BBD21 CSt type 0x11 Trace Sink - TPIU ROM 1 E0044000: CID B105900D PID 04003BB908 CSt CSTF type 0x12 Trace Link - Trace funnel/router ROM 1 E0045000: CID B105900D PID 04001BB961 CSt type 0x21 Trace Sink - ETB NXP: MCXN947 DAP stride is 1024 bytes (256 words) Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI_.cfx Image 'MCXN9xx_SFDP_FlexSPI Mar 6 2025 17:01:24' Opening flash driver MCXN9xx_SFDP_FlexSPI_.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Flash variant 'JEDEC_FlexSPI_Device' detected (0B = at 0x80000000) driver describes no sectors starting at 0x80000000 Flash Driver V.2 startup failed - rc Ef(58): Flash Driver describes no sectors at its base address chip initialization failed - Ef(58): Flash Driver describes no sectors at its base address failed to initialize flash driver MCXN9xx_SFDP_FlexSPI_.cfx Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI_.cfx Image 'MCXN9xx_SFDP_FlexSPI Mar 6 2025 17:01:24' Opening flash driver MCXN9xx_SFDP_FlexSPI_.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Flash variant 'JEDEC_FlexSPI_Device' detected (4MB = 64*64K at 0x80000000) Closing flash driver MCXN9xx_SFDP_FlexSPI_.cfx Next, I changed the setting value used in the SEC tool (CONFIG_OPTION0=0xC0000405) and checked, but writing was not performed here either. (You can write with the SEC tool.) The following is the console display at that time. MCUXpresso IDE RedlinkMulti Driver v24.9 (Sep 19 2024 19:34:05 - crt_emu_cm_redlink build 802) Found chip XML file in C:/WorkSpace/MCUX/MCUXpressoIDE_24.9.25/NX-N947/NX-N947_ledblinky/frdmmcxn947_led_blinky/Debug_NoRAM\MCXN947.xml ( 5) Remote configuration complete Reconnected to existing LinkServer process. Probe Firmware: MCU-LINK (r0FF) CMSIS-DAP V3.153 (NXP Semiconductors) Serial Number: VUDADS0NIE0ZM VID:PID: 1FC9:0143 USB Path: 0001:0008:00 Using memory from core 0 after searching for a good core ( 30) Emulator Connected processor is in secure mode debug interface type = CoreSight DP (DAP DP ID 6BA02477) over SWD TAP 0 processor type = Cortex-M33 (CPU ID 00000D21) on DAP AP 0 number of h/w breakpoints = 8 number of flash patches = 0 number of h/w watchpoints = 4 Probe(0): Connected&Reset. DpID: 6BA02477. CpuID: 00000D21. Info: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled. Content of CoreSight Debug ROM(s): RBASE E00FE000: CID B105100D PID 0000095000 ROM (type 0x1) ROM 1 E00FF000: CID B105100D PID 04000BB4C9 ROM (type 0x1) ROM 2 E000E000: CID B105900D PID 04000BBD21 CSt ARM ARMv8-M type 0x0 Misc - Undefined ROM 2 E0001000: CID B105900D PID 04000BBD21 CSt ARM DWTv2 type 0x0 Misc - Undefined ROM 2 E0002000: CID B105900D PID 04000BBD21 CSt ARM FPBv2 type 0x0 Misc - Undefined ROM 2 E0000000: CID B105900D PID 04000BBD21 CSt ARM ITMv2 type 0x43 Trace Source - Bus ROM 2 E0041000: CID B105900D PID 04002BBD21 CSt ARM ETMv4.0 type 0x13 Trace Source - Core ROM 2 E0042000: CID B105900D PID 04000BBD21 CSt ARM CTIv2 type 0x14 Debug Control - Trigger, e.g. ECT ROM 1 E0040000: CID B105900D PID 04000BBD21 CSt type 0x11 Trace Sink - TPIU ROM 1 E0044000: CID B105900D PID 04003BB908 CSt CSTF type 0x12 Trace Link - Trace funnel/router ROM 1 E0045000: CID B105900D PID 04001BB961 CSt type 0x21 Trace Sink - ETB NXP: MCXN947 DAP stride is 1024 bytes (256 words) Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Image 'MCXN9xx_SFDP_FlexSPI Mar 6 2025 18:26:01' Opening flash driver MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Driver V.2 dynamic startup failed - driver Init provided no flash parameters driver describes no sectors starting at 0x80000000 Flash Driver V.2 startup failed - rc Ef(58): Flash Driver describes no sectors at its base address chip initialization failed - Ef(58): Flash Driver describes no sectors at its base address failed to initialize flash driver MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Image 'MCXN9xx_SFDP_FlexSPI Mar 6 2025 18:26:01' Opening flash driver MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Driver V.2 dynamic startup failed - driver Init provided no flash parameters driver describes no sectors starting at 0x80000000 Flash Driver V.2 startup failed - rc Ef(58): Flash Driver describes no sectors at its base address chip initialization failed - Ef(58): Flash Driver describes no sectors at its base address failed to initialize flash driver MCXN9xx_SFDP_FlexSPI_0xC0000405.cfx Is it necessary to change anything other than CONFIG_OPTION0 for MX25L3233F? Best regards Re: Writing QSPI Flash on MCXN947 board. HI @takagi_y  "I tried to write to this board using the writing method for FRDM-MCXN947 as a reference, but an error occurred." You change to another board. Did you try the same method but not succeed？ BR Harry Re: Writing QSPI Flash on MCXN947 board. As additional information, we would like to inform you of what we did to implement XIP processing from the demo project you contacted us about to the project for this board. - Copy the following files.   source\mcxn_flexspi_nor_config.c   source\mcxn_flexspi_nor_config.h   linkscripts\rodata.ldt   linkscripts\text.ldt - Rewrite to "bootfromflexspi.bin" using blhost. - Change the settings of the Memory Configuration editor. I would appreciate your reply. Best regards