MCUXpresso SDKにおけるEzurio Sona NX611のサポート こんにちは、 Ezurio Sona NX611ワイヤレスカードはMCUXpresso SDK FreeRTOSでサポートされていますか?NXP IW611無線モジュールをベースにしているので、サポートされているはずですよね？ Re: Ezurio Sona NX611 support in MCUXpresso SDK こんにちは、 あなたの調子が良いといいのですが。サポートされているSDKsのモジュールの設定を直接確認することをお勧めします。 例えば、iMX RT1170のwifi_cliには以下のモジュールが見られます:   他のモジュールをお探しの場合は、IW61xの利用可能なイネーブルメントを基盤に、独自のサポートを追加する必要があります。 よろしくお願いいたします。 リカルド Re: Ezurio Sona NX611 support in MCUXpresso SDK ありがとう。モジュールの具体的なサポートをどうやって追加すればいいですか?mcuxsdk/components/wifi_bt_module/ /tx_pwr_limits には、各モジュール固有の設定があることがわかります。また、mcuxsdk/middleware/wifi_nxp/incl/など、例えばwifi_cal_data_override.h には「お客様はext_cal_data[]のデータを選択して特定のアンテナ校正データを設定できる」というテキストがあります。 新しいモジュールに対して、これらの設定（電力制限と校正データ）を正しく行うにはどうすればよいですか？ 新しいワイヤレスモジュールのサポートを追加するための包括的なマニュアルはありますか?私のはIW611をベースにしているので、NXPのIW611-MURATA-2DL-M2を参考にできるかもしれませんが、値を変更する必要があるかどうかはどうやって判断すればいいのでしょうか?   Re: Ezurio Sona NX611 support in MCUXpresso SDK @Ricardo_Zamora さん、ありがとうございます。 Ezurio Sona NX611は同じチップ（IW611）を使用しているため、NXP-IW611-MURATA-2DL-M2カードを選択しました。これで動作するはずだと思ったからです。しかし、SDKコードがワイヤレスカードにファームウェアをダウンロードしようとすると、次のような反応が出ます: 09/07/2026 13:04:32.589 [RX] - [FW Download] Start to download firmware from 0x60143230: 727 09/07/2026 13:04:38.560 [RX] - [wifi_io] Error: SDIO - FW Ready Registers not set [wifi] Error: sd_wifi_init failed. status code -1 [wlcm] Error: wifi init/reinit failed. status code -1 [!] WPL_Init: Failed, error: 1 Sona NX611はサポートモジュールリストに含まれていないと理解していますが、対応基板の一つとワイヤレスチップモデルのIW611を共有していることから、まだ動作するはずだという印象がありました。 Re: Ezurio Sona NX611 support in MCUXpresso SDK こんにちは、 モジュールの特定のサポートとしてはEzurioをおすすめします。実装方法はモジュールパートナーによって異なる場合があります。 よろしくお願いいたします。 リカルド

i.MX8MPLUS uSDHC HS400 mode with enhanced strobe Is there a recommended procedure to activate the enhanced strobe in HS400? Is it sufficient to set the EN_HS400_MODE in the MIX_CTRL register or does it need some additional modifications in the STROBE_DLL_CTRL register? Regards, Stefan Re: i.MX8MPLUS uSDHC HS400 mode with enhanced strobe Hi @Stefan_CIT  The HS400ES requires simultaneous configuration on both the eMMC and host sides. Setting EN_HS400_MODE alone is only part of the host-side configuration and is not sufficient to enable the HS400 Enhanced Strobe feature. If you are using Linux BSP, the driver automatically completes the DLL and tuning configurations. Best Regards, Zhiming Re: i.MX8MPLUS uSDHC HS400 mode with enhanced strobe Hi @Zhiming_Liu Thanks for the reply. We use the #I.MX8MPLUS with INTEGRITY OS and maintain the uSDHC-driver by ourselves. So, I'll try to transfer the process from the Linux-Driver Best regards, Stefan Re: i.MX8MPLUS uSDHC HS400 mode with enhanced strobe There is a better documentation about the Strobe-DLL and the switching to the enhanced strobe mode In those ReferenceManuals. https://www.nxp.com/docs/en/reference-manual/IMX93RM.pdf I guess the i.MX9 processors still have the same uSDHC-IP. Regards, Stefan

s32k144 - 设备已安全 大家好， 我正在参与S32K114 (AN12323)项目。最初，我在禁用 CSEC 的情况下烧录了网关项目，并且编程成功了。 之后，我尝试刷写CAN 示例应用程序，但遇到了以下错误： “设备当前安全，擦除后将变为不安全状态。” 为了解决这个问题，我还尝试使用“紧急 Kinetis 设备恢复”选项，但没有成功。 请问如何恢复设备或移除安全状态，以便我可以刷写 CAN 示例程序？ Re: s32k144 - Device is secured 嗨@Senlent ， 在哪些情况下 RESET 信号周期约为 118 µs？在我的情况下，哪些因素会导致 RESET 信号周期增加到约 475 µs？     谢谢。 Re: s32k144 - Device is secured 您好@ Pranathi06 如果复位信号周期不是~118µs，而是大于200µs，例如500µs甚至更长， 使用批量擦除命令，无法通过 SWD/JTAG 调试接口解密和恢复 MCU。 Re: s32k144 - Device is secured 嗨@Senlent 我用示波器测量了 RESET_b 引脚的波形。 RESET_b 信号持续切换。 脉冲重复时间似乎约为400–500 µs （光标显示 Δt ≈ 475 µs）。 峰值约为5V ，这表明您可能正在探测外部复位电路，而不是直接测量 3.3V MCU 引脚，或者 RESET 上有一个 5V 的上拉电阻。 The RESET activity is continuous and regular.   谢谢！         Re: s32k144 - Device is secured 您好@Pranathi06 “S32K144_FOTA_GATEWAY”命令不涉及任何CSEc或闪存网络安全相关操作，因此我不确定你对MCU做了什么。 你可以测量 RESET 引脚的波形，告诉我它的复位周期。 复位周期可以用来判断芯片是否能够恢复正常工作。 Re: s32k144 - Device is secured 嗨@Senlent ， 是的，已成功刷入“S32K144_FOTA_Gateway”，当我尝试刷入Can_example项目时，出现“设备已保护”的提示，之后就无法刷入任何软件了。 谢谢！ Re: s32k144 - Device is secured 您好@ Pranathi06 您的问题是在下载“S32K144_FOTA_Gateway”程序时出现，还是您已经成功刷写了“S32K144_FOTA_Gateway”？ Re: s32k144 - Device is secured 嗨@Senlent     我刷入了 AN5401_S32K144_CSEc_Resetting_Flash_to_Factory_State 来清除按键。之后，我只刷写了 GATEWAY_PROJECT 项目；我没有刷写 Memory_Partition 项目。 谢谢。   Re: s32k144 - Device is secured 您好@ Pranathi06 在刷写我的 GATEWAY_PROJECT 之前，我已经刷写了“重置闪存状态” 我不明白你的意思。 AN12323SW 没有“将闪存重置到状态”程序。 根据你的描述，你修改了“S32K144_FOTA_Gateway”？ 您只需要检查您的程序是否已启用 CSEc 模块并分配了密钥，以及您是否考虑过在应用程序中将 CSEc 模块恢复到出厂状态。 否则，这种情况就无法挽回了。 Re: s32k144 - Device is secured 嗨@Senlent 我没有刷写 Memory_partition 项目。 在刷写我的 GATEWAY_PROJECT 之前，我已经刷写了“重置闪存状态” 有什么办法可以恢复吗？ 谢谢。 Re: s32k144 - Device is secured 您好@ Pranathi06 这个问题与“S32K144_FOTA_Gateway”中是否启用“CSEC”无关，因为在测试 AN12323SW 时，第一步应该是下载并运行“S32K144_Memory_Partition”来执行分区，这默认情况下已经启用了 CSEC 并分配了一个密钥。 AN12130： 这就是MCU被锁定的原因； 由于该解决方案没有提供重置 CSEC 操作，因此无法恢复。 下次记得修改“S32K144_Memory_Partition”使其仅进行分区，而不启用 CSEC 或密钥。 Re: s32k144 - Device is secured 您好@ Pranathi06 这是根据经验得出的结论，你的情况与此非常相似：CSEc 硬件加密模块已启用，阻止了 CSEc 加密密钥的批量擦除，从而导致了问题。 虽然芯片已死锁，MCU 无法再下载程序或进行调试，但只要芯片的电源正常，仍然可以使用 J-LINK 调试器通过 SWD/JTAG 调试接口连接到 S32K1xx 系列 MCU ARM Cortex M4F/M0+ 的 CoreSight DAP 调试访问接口，读取 MDM-AP 状态寄存器。 因此，您可以根据读取 MDM-AP 状态寄存器值来确定芯片死锁的根本原因。 如果您需要我帮助您找出死锁的原因，您可以尝试使用J-LINK读取MDM-AP 状态寄存器。

Utilize pipe for logging Hi community, I am trying to integrate freemaster pipes for logging (and maybe use more of its functionality later on). As I am running linux I tried to go the freemaster light + python path. I can properly connect but when trying to open the pipeline and print my piped log messages I am not receiving any data via the rpc server. To verify the target implementation I also checked via the Windows GUI which could read the pipe properly, so the issue seems to be on the PC side. See attached example python script. Any hints welcome. best regards Re: Utilize pipe for logging Never mind, seems I have to explicitly call PipeFlush on the receiver side. Did not expect that. Attached the working example as reference.

imx8mp の libcamera こんにちは、NXP FAE の皆さん: 現在、NXP が imx8mp プラットフォームで libcamera をサポートしているかどうかを知りたいです。 https://libcamera.org/getting-started.html をご覧ください。 yocoto kirkstone bsp を見ると、レシピ libcamera は meta-openembedded/meta-multimedia/recipes-multimedia/libcamera/libcamera.bb の下にあるようです。ターゲット libcamera をイメージに追加して imx8mp-evk ボードで実行すると、libcamera はキャプチャ デバイスの検出時に何も報告しません。gst-launch を実行しても結果は同じです。 LIBCAMERA_LOG_LEVELS=*:DEBUG gst-device-monitor-1.0 Video IPAModule ipa_module.cpp:329 ipa_vimc.so: IPA module /usr/lib/libcamera/ipa_vimc.so is signed IPAManager ipa_manager.cpp:240 Loaded IPA module '/usr/lib/libcamera/ipa_vimc.so' Camera camera_manager.cpp:293 libcamera v0.0.0 Camera camera_manager.cpp:106 Starting camera manager DeviceEnumerator device_enumerator.cpp:224 New media device "mxc-md" created from /dev/media0 DeviceEnumerator device_enumerator_udev.cpp:95 Defer media device /dev/media0 due to 1 missing dependencies DeviceEnumerator device_enumerator_udev.cpp:320 All dependencies for media device /dev/media0 found DeviceEnumerator device_enumerator.cpp:252 Added device /dev/media0: mxc-md Camera camera_manager.cpp:149 Found registered pipeline handler 'PipelineHandlerUVC' Camera camera_manager.cpp:149 Found registered pipeline handler 'SimplePipelineHandler' Camera camera_manager.cpp:149 Found registered pipeline handler 'PipelineHandlerVimc' libcamera コードを読み返すと、libcamera が使用する前にカメラを登録する必要があることがわかります。 bool PipelineHandlerRPi::match(DeviceEnumerator *enumerator) { DeviceMatch unicam("unicam"); MediaDevice *unicamDevice = acquireMediaDevice(enumerator, unicam); if (!unicamDevice) { LOG(RPI, Debug) << "Unable to acquire a Unicam instance"; return false; } DeviceMatch isp("bcm2835-isp"); MediaDevice *ispDevice = acquireMediaDevice(enumerator, isp); if (!ispDevice) { LOG(RPI, Debug) << "Unable to acquire ISP instance"; return false; } int ret = registerCamera(unicamDevice, ispDevice); if (ret) { LOG(RPI, Error) << "Failed to register camera: " << ret; return false; } return true; } SO、以下の質問があります。 1.NXP bsp は現在、カメラ デバイス ov5640 などの libcamera をサポートしていますか? 2.そうでない場合、NXP は libcamera をサポートする予定がありますか、またはそのための提案/リファレンス デザイン/ガイド/パッチはありますか? 3.libcamera で新しいカメラにサポートを追加するのはどれくらい複雑ですか? 私は libcamera の初心者なので、あなたの助け/ガイド/情報を期待しています。 よろしくお願いします。 ジョンソン Re: libcamera on imx8mp VSI SDKにも興味があります。外部カメラからキャプチャしたフレームにVivante ISP8000の3Aアルゴリズムを使用できれば非常に便利です。 Re: libcamera on imx8mp こんにちは、サンケト・パレックさん。 情報ありがとうございます。あなたの情報に基づいてさらに調べてみます。 よろしくお願いします。 ジョンソン Re: libcamera on imx8mp こんにちは@Sanket_Parekhさん、 vsi SDK とは何ですか? また、どのようにアクセスするのですか? よろしくお願いいたします。 カン Re: libcamera on imx8mp こんにちは@zhangjunsheng お元気でお過ごしでしょうか。 お客様が3Aや他のモジュール用のアルゴリズムを持っていない場合、lib-cameraの使用はお勧めしません。 VSI SDK は良い選択です。今後はvsi SDKをサポートする予定です。 お客様が lib-camera に興味があり、ISP の専門家である場合は、GitLab にオープンソースがあります(https://gitlab.com/ideasonboard/nxp/libcamera)。 ありがとう、よろしく。 サンケト・パレック Re: libcamera on imx8mp こんにちは@zhangjunshengさん このリポジトリを見つけました: https://gitlab.com/ideasonboard/nxp/libcamera Re: libcamera on imx8mp ここで強調しておきたいのは、はい、i.MX8MPはlibcameraで非常によくサポートされているのですが、Linuxカーネルで正しいカーネルドライバーを有効にする必要があります。 libcameraはLinuxカーネルで一見名前のRKISP1ドライバーを使っていますが、ISPは共通の遺産を共有しているためです。しかしプラットフォーム自体は非常に強力なサポートがあり、商用製品に搭載されており、多くのユースケースやカスタマイズを簡単にサポートできます。 ライセンス契約に署名する必要がなく、ソースコード全体を入手できるというメリットもあります！(すべてhttps://gitlab.freedesktop.org/camera/libcameraで公開されています)）

当 VPWR 为 24 V 时，MC34GD3000 的门驱动器输出电压等级 NXP社区的各位朋友，大家好！ 我计划使用 MC34GD3000 来驱动一台 24V、26W 的电机。 在许多参考电路和示例中，MC34GD3000 的 VPWR 电源似乎连接到与电机电源相同的电源电压。在我的应用中，电机供电电压为 24V，因此 MC34GD3000 的 VPWR 也将为 24V。 我想澄清一下MC34GD3000的栅极驱动输出电压等级。 在数据手册的绝对最大额定值表中，我发现了如下数值： - PX_HS_G 至 PX_HS_S：3.0 V 至 16.5 V - PX_LS_G 至 PX_LS_S：3.0 V 至 16.5 V - PX_BOOT 至 PX_HS_S：3.0 V 至 16.5 V 我的问题是： 当 VPWR 为 24 V 时，MC34GD3000 的实际 PWM 门驱动器输出电压等级是多少？ 栅极驱动输出是否因为 VPWR 为 24 V 而变为 24 V，还是栅极驱动输出相对于每个 MOSFET 源极节点最大限制在约 16.5 V？ 例如，对于低侧 MOSFET，我是否应该理解为 PX_LS_G 到 PX_LS_S 的驱动电压约为 15 V，而不是 24 V？ 对于高侧 MOSFET，我的理解是 PX_HS_G 的驱动电压高于相位节点，但栅源电压 PX_HS_G 到 PX_HS_S 仍然限制在 15 V 左右吗？ 希望您能确认一下。 谢谢！ BLDC驱动器 Re: MC34GD3000 gate drive output voltage level when VPWR is 24 V 你好， 是的，你的理解是正确的。即使 VPWR 连接到 24 V 电机电源，MC34GD3000 也不会将 MOSFET 的栅极驱动到相对于其源极的 24 V。该设备产生内部栅极驱动电源（VLS），其电压稳定在约 15 V。 因此： 对于低侧 MOSFET，PX_LS_G 的电压比 PX_LS_S 的电压高约 15 V。 对于高侧 MOSFET，PX_HS_G 通过自举电路被驱动到相位节点以上，但栅源电压 PX_HS_G − PX_HS_S 仍保持在约 15 V。 数据表中所示的限值（PX_HS_G 至 PX_HS_S 和 PX_LS_G 至 PX_LS_S）表示有效的栅源驱动电压，表明门驱动器不等于 24 V VPWR 电源电压。 希望这能帮到你！

Request to Extend License for S32 Design Studio for ARM 2018.R1 We are currently using S32 Design Studio for ARM 2018.R1 (Windows) for one of our products. The license has recently expired, and we are unable to activate the software. When we attempt to generate an activation key using our activation code, the generated key is also reported as expired, preventing us from using the IDE. Our activation code is: Activation Code: FF6A-EDA4-CDF0-7186 Could you please extend or renew the license associated with this activation code, or advise us on the appropriate steps to regain access to the software? Your assistance would be greatly appreciated, as this project depends on this development environment. Thank you.

gPTPレイヤ2パケットがS上のGMAC0を介して最高優先度で送信されるようにする方法 こんにちは S32G399のGMAC0を介してgPTPレイヤ2パケットが最高優先度で送信されるようにするにはどうすればよいですか？ Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t gPTPフレームがQ4に入力されていることを確認してください。 これをどう実装すればいいのでしょうか? Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t こんにちは、ジジエ ご返信と情報提供ありがとうございます。 この機能を実装するには、以下の図のようにBSPユーザーマニュアルを参照してみることができます。Q4には別の時間枠を設定し、より高い優先度を持たせることも検討できます。さらに、gPTPフレームがQ4に入ることを確認してください。レイヤー2のタイムウィンドウ設定に関する以下のコマンドを参考にできます: tc qdisc add dev eth0 root taprio \ num_tc 5 \ マップ 0 1 2 3 4 \ キュー 1@0 1@1 1@2 1@3 1@4 \ ベースタイム 0 \ スケジュールエントリ S 10 50000 \ スケジュールエントリ S 0f 450000 \ スケジュールエントリ S 1f 96 \ フラグ 0x2 この情報があなたの助けになれば幸いです。 BR ジョーイ Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t MコアまたはAコアでGMAC0を使用してgPTPを利用していますか？ A: Aコアについて 現在、GMACのTSN機能を利用していますか?VLANは使用されましたか？ A: GMACのTSN機能を利用すること:gptp;gptpパケットにはVLANがありません。 GMACコントローラは5つのTx/Rxキューを提供します。 すべてのgPTPトラフィックを最も優先度の高いTx/Rxキュー(q4)にルーティングする必要があります。 対応するレジスタの設定やコード実装方法、そしてLInuxでの設定方法(例えば:tc、ip)についてアドバイスいただけますか? Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t こんにちは、ジジエ お問い合わせいただきありがとうございます。もう少し詳しい情報を教えてもらえますか? MコアまたはAコアでGMAC0を使用してgPTPを利用していますか？ 現在、GMACのTSN機能を利用していますか?VLANは使用されましたか？ BR ジョーイ Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t こんにちは、ジジエ ご返信よろしくお願いします。 デバイスツリーのgmac0セクションでキュー情報の設定を試してみてください。 arch\arm64\boot\dts\freescale\s32cc.dtsi というファイルが含まれています。         gmac0 : ethernet@4033c000 { ステータス = "無効" ; compatible = "nxp,s32cc-dwmac" ; mtl_rx_setup_gmac0 : rx-queues-config { snps、使用する受信キュー = < 5 >; #address-cells = < 1 >; #size-cells = < 0 >;                 queue@0 { };                 queue@1 { };                 queue@2 { };                 queue@3 { };                 queue@4 { }; };             mtl_tx_setup_gmac0 : tx-queues-config { snps、使用するtx-queues-to-use = < 5 >; #address-cells = < 1 >; #size-cells = < 0 >;                 queue@0 { };                 queue@1 { };                 queue@2 { };                 queue@3 { };                 queue@4 { }; }; また、GMACドライバでRXキューパケットのルーティング設定を見つけられます。Q4のノードを「snps,route-ptp」として設定してみてください。 ご質問があればいつでもご連絡ください。   BR ジョーイ

USB HS PLL not Locking on LPC55S69 I am working on my first USB enabled product with an LPC series microcontroller, and it is the first time that I have worked with the PHY directly. This is on a custom board, using the USB1 high-speed USB connection. I am currently trying to get the dev_cdc_vcom_bm SDK example working on my device (after testing it on the LPCXpresso55S69 dev board). The obvious difference on my custom board is that it has a 20MHz crystal mounted rather than 16MHz.  I have tracked down, as my first problem, that the PLL_SIC register is showing PLL_LOCK as 0, so the PLL is not locking. USB clock, USB PLL power, and USB PLL enable are enabled. The clock divisor is set for divide by 24 (value4) for the 20MHz clock. PLL_PREDIV = 0. USB1_3V3 is reading a solid 3.299v, so the input voltage seems fine. One other potential issue is that I'm using a 20MHz oscillator and not a 20MHz crystal. I saw another thread where that was the issue, but it was on a Kinetis part, and I'm not sure it's the same IP. Even if it is, I wouldn't be surprised if that was a red herring. Attached is the schematic of the device, though that shouldn't be the issue in this case. Any thoughts about where to look next as far as getting the PLL to lock?  LPC55xx Re: USB HS PLL not Locking on LPC55S69 Hi @martinjaymckee  Looking at your schematic, the LPC55S69 XTAL32M_P pin is driven from an ECS-2520MVLC-200-CN oscillator output, while XTAL32M_N is left unconnected. The USB HS PLL on LPC55S69 derives its reference from the system oscillator block. The SDK examples typically assume a crystal connected between XTAL32M_P and XTAL32M_N. When using an external clock source instead of a crystal, the oscillator block should be configured differently. BR Harry Re: USB HS PLL not Locking on LPC55S69 Okay, that's fair. I do have XO32M configured to use use the buffer bypass. And I have verified that the main clock PLL is using the correct oscillator input. Are there other configurations that I need too change on the XO32M clock block to make the USB PLL work?

S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault Hello NXP team,   We are using S32K328 with RTD 7.x.   Software setup: - CM7_0 runs a bootloader. - CM7_1 is used by a second application. - CM7_2 is not intended to execute application code. - We are evaluating whether CM7_0 can use CM7_2 DTCM as system memory through the TCM backdoor/AHBS path.   Reference Manual context: Chapter “Memory Map” says ITCM/DTCM can be accessed through the 32-bit AHBS interface by other masters, including other Cortex-M7 cores and eDMA. The “TCM as system memory” section says an enabled core can use TCM of a disabled/waiting core after: 1. Enabling the target core TCM controller clock:    MC_ME PRTN2_COFB2_CLKEN[REQ64] for Cortex-M7_2 2. Setting target core CPUWAIT:    DCM_GPR DCMRWF4[CM7_2_CPUWAIT] 3. Enabling target core clock/access path:    MC_ME PRTN0_CORE4_PCONF[CCE]   What we tried: 1. Set DCM_GPR DCMRWF4[CM7_2_CPUWAIT]. 2. Set MC_ME PRTN2_COFB2_CLKEN[REQ64]. 3. Set MC_ME PRTN2_PUPD[PCUD]. 4. Applied MC_ME CTL_KEY sequence. 5. Waited for PRTN2_PUPD[PCUD] to clear. 6. Read PRTN2_COFB2_STAT and observed bit0/BLOCK64 active. 7. Set MC_ME PRTN0_CORE4_PCONF[CCE]. 8. Set MC_ME PRTN0_CORE4_PUPD[CCUPD]. 9. Applied MC_ME CTL_KEY sequence. 10. Waited for PRTN0_CORE4_STAT[CCS] to become 1. 11. Disabled MPU temporarily for the experiment. 12. Tried a single 32-bit write to the CM7_2 DTCM backdoor address.   Observed result: - PRTN2_COFB2_STAT indicates the TCM controller clock request is active. - PRTN0_CORE4_STAT[CCS] becomes 1. - The first 32-bit write to the CM7_2 DTCM backdoor region causes an imprecise BusFault escalated to HardFault.   Questions: 1. For S32K328, what is the correct CM7_2 DTCM backdoor/system address range accessible from CM7_0? 2. Is CM7_2 DTCM backdoor access from CM7_0 supported while CM7_2 remains in CPUWAIT? 3. Besides MC_ME and DCM_GPR setup, is any XRDC configuration required to allow CM7_0 to write to CM7_2 DTCM backdoor? 4. Is any MPU region required even if MPU is temporarily disabled for the test? 5. Is any MSCM/MCM/XBIC/ENEDC setting required before using the TCM backdoor path? 6. Is PRTN2_COFB2_STAT[BLOCK64] the correct status bit to confirm CM7_2 TCM controller clock is active? 7. Is PRTN0_CORE4_STAT[CCS] the correct status bit to confirm CM7_2 clock/access path is active? 8. For DTCM ECC initialization through backdoor access, is a 32-bit write from CM7_0 sufficient? 9. If the first backdoor write causes an imprecise BusFault, which fault/XRDC registers should be checked to identify whether the failure is due to XRDC, interconnect, or unmapped address?   Current goal: We only want to validate a minimal smoke test: - one 32-bit write to CM7_2 DTCM backdoor, - then readback, - before considering any production use.   Thank you. Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault Hello @krishna_Bugudi, 1. Refer to the S32K3xx_memory_map.xlsx, DTCM_2 backdoor at 0x21800000 2. Yes 3. No 4. No 5. No 6. Yes, refer to RM, Section 3.4 TCM as system memory 7. Yes 8. Yes, refer to RM, Table 102. Memory ECC initialization summary 9. You wrote that XRDC is disabled. So, it won't be reported by XRDC.  What address do you write? Regards, Daniel Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault Hello Daniel,   Thank you for the confirmation.   We updated the test to follow the RM/NXP sequence exactly and are still seeing the store hang.   Confirmed address: We are writing to:   0x21800000   This matches S32K3xx_memory_map.xlsx:   DTCM_2 Backdoor: - Start address: 0x21800000 - End address:   0x2181FFFF - S32K328 implemented size: 128 KB   The memory map also shows PRAM2_TCM_XBIC is present on S32K328 at: 0x40408000 - 0x4040BFFF   and describes it as: "Crossbar Integrity Checker (PRAM2 & TCM backdoor AHB Splitter"   while TCM_XBIC at 0x40400000 is marked Reserved for S32K328.   Latest test sequence:   1. Set MC_ME PRTN2_COFB2_CLKEN[REQ64]. 2. Set MC_ME PRTN2_PUPD[PCUD]. 3. Apply MC_ME CTL_KEY sequence. 4. Wait for PRTN2_PUPD[PCUD] to clear. 5. Read PRTN2_COFB2_STAT.   Observed: PRTN2_COFB2_STAT = 0x00000039   6. Set DCM_GPR DCMRWF4[CM7_2_CPUWAIT].    Readback confirms:    DCMRWF4 = 0x00080000   7. Set MC_ME PRTN0_CORE4_ADDR to a safe loop address.    Readback:    PRTN0_CORE4_ADDR = 0x00402408   8. Set MC_ME PRTN0_CORE4_PCONF[CCE]. 9. Set MC_ME PRTN0_CORE4_PUPD[CCUPD]. 10. Apply MC_ME CTL_KEY sequence. 11. Wait for PRTN0_CORE4_STAT[CCS] to become 1.   Observed: PRTN0_CORE4_STAT = 0x00000001   12. Disable CM7_0 MPU temporarily for isolation.    MPU_CTRL before disable = 0x00000003   13. Attempt one single 32-bit write:      *(volatile uint32_t *)0x21800000 = 0u;   Latest breadcrumb log:   [CORE2_DTCM_SMOKE] S4B: WORD0 WRITE START addr=0x21800000   The next breadcrumb after the store is not reached:   [CORE2_DTCM_SMOKE] S4B1: WORD0 STORE ISSUED BEFORE DSB   So the store itself appears to stall or not complete before reaching the following instruction. The DSB is not reached in this latest test.   Question: Since you confirmed that: - 0x21800000 is the correct DTCM_2 Backdoor address, - CM7_0 access is supported while CM7_2 is in CPUWAIT, - no additional XRDC/MPU/MSCM/MCM/XBIC/ENEDC setup is required, - PRTN2_COFB2_STAT[BLOCK64] is the correct status bit, - PRTN0_CORE4_STAT[CCS] is the correct status bit, - 32-bit writes are valid for DTCM ECC initialization,   what could cause the first 32-bit store to 0x21800000 to stall before completion?   Should we inspect PRAM2_TCM_XBIC at 0x40408000 for TCM backdoor AHB splitter errors on S32K328?   If yes, could you please point us to: 1. The PRAM2_TCM_XBIC status/error registers to read. 2. The expected error indication for a failed DTCM_2 backdoor transaction. 3. Whether any error-clear sequence is required before retrying the access. 4. Any other MC_ME/DCM/MSCM/XBIC/fault registers that should be captured when the store does not complete.   Regards, Krishna Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault Hi Krishna,  Copilot said: I have tested it and was able to reproduce this error only when the default MPU is enabled in the project (configured in system.c generated by the S32DS RTD project). Could you dump the MPU registers to verify whether the MPU is disabled in your project? Regards, Daniel

How to evaluate NPU tflite model on large dataset on MIMRT700 board? My question is as my tittle. I have tflite model, I converted to NPU tflite model. I checked that predictions from tflite model and NPU tflite model are different in some cases (not much). So I want to run evaluation NPU tflite model on the large dataset. Currently, I follow the sample tflm_cifar10_cm33_core0 to run inference NPU tflite model on  MIMRT700 and it works. But in this sample, we fixed image_data.h for static image (I do not use camera). I want to modify this sample for my new case "run evaluation NPU tflite model on the large dataset." I intend to use SD cards to save image and load it when inference as image_data.h. But I do not know where I can start I saw that MIMRT700 has 3 micro USB port: debug, eUSB and USB-OTG If you have any recommedation and suggestions, please share with me. If I manually run each image (build + flash), it will take much time. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? @EdwinHz  Thank you for supporting me. The method with SD card is good. I am not good at hardware, so as my teamate's suggestion. How about this method that I mentioned above? Currently I follow step by steps to run inference with the sample tflm_cifar10_cm33_core0: - Copy image_data.h to sample - Click Build button - Click debug button, and click continue button to run inference. I discussed with my teammates and if I can run above via command line (build, and run inference) by using commands, so it is very good. Because if it works, I can create script to change image_data.h each time, build and run inference and get inference results back to PC. Do you have any comment on that? I mean that if NXP have guideline to build, flash and run sample tflm_cifar10_cm33_core0, I can customize easier. I am not good at hardware, so that I like this method (If NXP support this methods, I can create Python script to creata image_data.h each time, build, flash, run and get result back to PC, save to .csv file, e.t.c). I see other many vendors which support this method (build, flash and run, get result back to PC via command line). I think that NXP also supports this method. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? Hi @nnxxpp, The example uses the static-header approach, as you mentioned. However, establishing a pipeline that leverages mounting images via an SD card would be much more suitable for large datasets: Have the images pre-loaded on the SD card, then mount the SD card, open the image list, and for each image: - Read into an input buffer - Run NPU inference - Write result on a "results.csv" file We currently do not have a sample code that exemplifies this, but you can refer to both the tflm_cifar10_cm33_core0 that you are using, as well as sdcard_fatfs example from the SDK, which already handles the initialization and card mounting, and has all the available APIs for SD card usage. I suggest you run and understand the sdcard example, and test reading a binary image file. Then, add the sd card components to the tflm example and import the SD card initialization and FatFs code, and finally replace the static image_data.h input with a buffer containing image info read using f_read() from the SD card. Having the images already stored in the tensor format would ease the process and prevent the use of JPEG/PNG decoding. BR, Edwin. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? I want to add more information. Currently I follow step by steps to run inference with the sample tflm_cifar10_cm33_core0: - Copy image_data.h to sample - Click Build button - Click debug button, and click continue button to run inference. I discussed with my teammates and if I can run above via command line (build, and run inference) by using commands, so it is very good. Because if it works, I can create script to change image_data.h each time, build and run inference and get inference results back to PC. Do you have any comment on that? Thank you so much. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? I also saw that MIMRT700 has SD card, if I can easily locate images on SDcard on load image to tflm_cifar10_cm33_core0 and save inference results on SD card, so it is very good. But to be honest, I do know how to start. I am not good at hardware. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? Hi @nnxxpp, I understand. You can run MCUXpresso SDK projects from command line and automate the process using a script. Our SDK command-line flow uses west build, and flashing can be done with west flash -r linkserver. AN14700 specifically uses CLI to compile the project as described on part 8 of section "7.3 Run the converted model". So, a general application of a script to automate this process could: 1. copy new image_data.h 2.  build using west build 3. program using west flash 4. capture UART log Although not the "conventionally recommended method", this would definitely work as well for your application. BR, Edwin.

S32 Design Studio for Power Architecture ® 2017.R1 - 许可证激活问题 你好， 我想请求协助办理我的驾照激活手续。 我之前的请求已处理完毕，但激活的版本有误。我现在可以使用 S32 Design Studio for Power Architecture v2.1，但我目前的项目实际上需要使用 S32 Design Studio for Power Architecture 2017.R1 (S32DS-PA v2.0)。 请您更正激活信息并恢复正确的许可证版本。 非常感谢您的支持。 此致， 亚历山德罗 Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue 你好， 我已经替你申请了。 完成后我会通知你。 顺祝商祺！ Peter Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue 你好，彼得， 感谢您的帮助。 我只是想告知您，我尚未收到任何更新，我的许可证仍然过期。因此，我目前无法使用 S32 Design Studio for Power Architecture 2017.R1 (v2.0)，也无法继续我的工作。 顺祝商祺！ 亚历山德罗 Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue 你好， 此时一切都应该准备就绪了。 顺祝商祺！ Peter Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue 非常感谢， 亚历山德罗

S32K144EVB-Q100 Rev D Schematic Hi. I'm looking for the schematic for S32K144EVB-Q100 Rev D. I cannot seem to make the board send any CAN messages. Is there sample code available to send message on CAN 0 on that board? I was able to use SPI and confirm the CAN transceiver is in forced normal mode so CAN should be working. Re: S32K144EVB-Q100 Rev D Schematic You may check the sample code at S32DS for S32K144EVB... Please share if any since i can not found it...

s32k144 - デバイスは保護されています チームの皆さん、こんにちは。 私はS32K114（AN12323）プロジェクトに取り組んでいます。最初は、 CSECを無効にした状態でGatewayプロジェクトをフラッシュしたところ、プログラミングは成功しました。 その後、 CANの例アプリケーションをフラッシュしようとしましたが、以下のエラーに遭遇しました: 「デバイスは安全です。データを消去して安全性を解除してください。」 問題を解決するために 「緊急Kinetisデバイス回復」 オプションも試しましたが、効果がありませんでした。 CANの例をフラッシュするために、デバイスの復元方法やセキュア状態を解除する方法を教えていただけますか? Re: s32k144 - Device is secured こんにちは、 @Senlent さん。 どのようなシナリオでリセット信号周期が約118μsになるのか、また私の場合、どのような要因で約475μsまで増加するのでしょうか?     ありがとうございます。 Re: s32k144 - Device is secured こんにちは、@ Pranathi06 リセット信号周期が約118µsではなく、200µsより長く、例えば500µsまたはそれ以上の場合、 MCUはSWD/JTAGデバッグインターフェースのマスイレーズコマンドによる復号・復号はできません。 Re: s32k144 - Device is secured こんにちは、 @Senlentさん 私はオシロスコープを使ってRESET_bピンの波形を測定しました。 RESET_b信号は連続的にトグルしています。 パルスの繰り返し周期はおよそ400～500µsのようです（カーソルはΔt ≈ 475µsを示しています）。 ピークレベルは約 5Vで、3.3V MCUピンを直接測定するのではなく外部リセット回路を探っている可能性や、RESET時に5Vへのプルアップがある可能性を示唆しています。 リセット活動は継続的かつ定期的に行われる。   よろしくお願いします。         Re: s32k144 - Device is secured こんにちは、@Pranathi06 「S32K144_FOTA_GATEWAY」コマンドはCSEcやフラッシュのセキュリティ操作を含んでいないので、あなたがMCUに何をしたのかはわかりません。 リセットピンの波形を測定してリセットサイクルを教えてもらえます。 リセットサイクルはチップが正常動作に復旧できるかどうかを判断するために使えます。 Re: s32k144 - Device is secured こんにちは、 @Senlent さん。 はい、「S32K144_FOTA_Gateway」は正常にフラッシュしましたが、その時にプロジェクトをフラッシュしようとしたとき、「デバイスは保護済み」Can_example、その後はどのソフトウェアもフラッシュできなくなりました。 よろしくお願いします。 Re: s32k144 - Device is secured こんにちは、@ Pranathi06 問題は「S32K144_FOTA_Gateway」プログラムのダウンロード中に発生していますか、それとも既に「S32K144_FOTA_Gateway」の書き込みに成功していますか？ Re: s32k144 - Device is secured こんにちは、 @Senlentさん     キーを消去するために、AN5401_S32K144_CSEc_Resetting_Flash_to_Factory_State をフラッシュしました。その後、GATEWAY_PROJECTのみをフラッシュし、Memory_Partitionプロジェクトはフラッシュしませんでした。 ありがとうございます。   Re: s32k144 - Device is secured こんにちは、@ Pranathi06 「GATEWAY_PROJECTをフラッシュする前に、「フラッシュを状態にリセット」をフラッシュしました」 あなたの言っている意味が分かりません。 AN12323SWには「フラッシュを状態にリセットする」プログラムがありません。 あなたの話からすると、「S32K144_FOTA_Gateway」を変更したということですか？ プログラムがCSEcモジュールを有効にしてキーを割り当てているか、そしてアプリケーション内でCSEcモジュールを工場出荷時の状態に戻すことを検討しているかを確認する必要があります。 そうでなければ、この状況は回復不可能となる。 Re: s32k144 - Device is secured こんにちは、 @Senlentさん Memory_partitionプロジェクトをフラッシュしませんでした。 GATEWAY_PROJECTをフラッシュする前に、「フラッシュを状態にリセット」をフラッシュしました。 復旧するための解決策はありますか？ ありがとうございます。 Re: s32k144 - Device is secured こんにちは、@ Pranathi06 この問題は、「S32K144_FOTA_Gateway」で「CSEC」が有効になっているかどうかとは関係ありません。AN12323SWをテストする場合、最初のステップとして「S32K144_Memory_Partition」をダウンロードして実行し、パーティショニングを実行する必要があります。このツールはデフォルトでCSECを有効にし、キーを割り当てます。 AN12130: これがMCUがロックされている理由です。 解はリセットCSEC操作を提供しないため、復元できません。 次回は、「S32K144_Memory_Partition」をパーティション分割のみに変更し、CSECやキーを有効にしないようにしてください。 Re: s32k144 - Device is secured こんにちは、@ Pranathi06 これは経験に基づいたもので、あなたの状況も非常によく似ています。CSEcハードウェア暗号化モジュールが有効になっていたため、CSEc暗号化キーの一括消去が妨げられ、それが問題の原因となったのです。 チップはデッドロックされており、MCUはプログラムのダウンロードやデバッグができなくなりますが、チップの電源が正常であれば、J-LINKデバッガを使ってS32K1xxシリーズMCU ARM Cortex M4F/M0+のCoreSight DAPデバッグアクセスインターフェースに接続し、SWD/JTAGデバッグインターフェースを介してMDM-APステータスレジスタを読み取ることができます。 したがって、MDM-APの状態レジスタの読み取り値に基づいてチップデッドロックの根本原因を特定できます。 もしデッドロックの原因を特定する手助けが必要なら、 J-LINK を使って MDM-APステータスレジスタを読み取ってみるといいですよ。

Ezurio Sona NX611 support in MCUXpresso SDK Hello, Is Ezurio Sona NX611 wireless card supported in MCUXpresso SDK FreeRTOS? As it's using base NXP IW611 radio, I think it should be supported, right? Re: Ezurio Sona NX611 support in MCUXpresso SDK Hello, Hope you are doing well. I would recommend checking directly on the configuration of any of our SDK examples, the supported modules. For example, in the wifi_cli for iMX RT1170, you can find these modules:   If you are looking for any other module, you would need to add the specific support at your own, taking as a base the available enablement for IW61x. Best Regards, Ricardo Re: Ezurio Sona NX611 support in MCUXpresso SDK Thank you. How do I add the specific support for the module? I see there are specific settings for each module in mcuxsdk/components/wifi_bt_module/ /tx_pwr_limits . Also there are multiple calibration data headers in mcuxsdk/middleware/wifi_nxp/incl/, for example, wifi_cal_data_override.h which has the following text: "Customer can override the data of ext_cal_data[] to set specific antenna calibration data". How do I set these (power limits and calibration data) correctly for a new module? Is there a comprehensive manual for adding support for a new wireless module? Mine is based on IW611, so I guess I can take NXP IW611-MURATA-2DL-M2 as a reference but how do I know if I need to change any values?   Re: Ezurio Sona NX611 support in MCUXpresso SDK Thank you @Ricardo_Zamora . I selected NXP-IW611-MURATA-2DL-M2 card, as Ezurio Sona NX611 uses the same chip (IW611) and I thought it should work. However, when the SDK code tries to download the firmware to the wireless card, I get: 09/07/2026 13:04:32.589 [RX] - [FW Download] Start to download firmware from 0x60143230: 727 09/07/2026 13:04:38.560 [RX] - [wifi_io] Error: SDIO - FW Ready Registers not set [wifi] Error: sd_wifi_init failed. status code -1 [wlcm] Error: wifi init/reinit failed. status code -1 [!] WPL_Init: Failed, error: 1 I understand that Sona NX611 is not in the list of supported modules but I had the impression that it should still work given that it shares the wireless chip model, IW611, with one of the supported boards. Re: Ezurio Sona NX611 support in MCUXpresso SDK Hello, I would recommend going with Ezurio for specific support for their module. Implementation may vary from module partners. Regards, Ricardo

ログ記録にパイプを利用する こんにちは、コミュニティの皆さん、 ログ記録のためにfreemasterパイプを統合しようとしています（そして、将来的にはその他の機能も利用したいと思っています）。 Linuxを使っているので、FreeMaster Light + Pythonの道を試しました。 正常に接続はできますが、パイプラインを開いてパイプログメッセージを印刷しようとすると、rpcサーバー経由でデータが一切届きません。 ターゲット実装を確認するために、Windows GUIでパイプを正しく読み取れるか確認したので、問題はPC側にあるようです。 添付のPythonスクリプトの例を参照してください。どんなヒントでも歓迎です。 よろしくお願いいたします Re: Utilize pipe for logging まあいいや、レシーバでPipeFlushを明示的に呼ぶ必要があるようだ。それは予想外だった。参考として、動作例を添付しました。

LPC18xxのウォッチドッグリセットを検出できません ウォッチドッグリセットが発生したことを検出する際に問題が発生しています。現在、ユーザーガイドに記載されている手順に従っています。 ウォッチドッグのタイムアウトフラグ(WDTOF)を調べることで、ウォッチドッグがリセット状態を引き起こしているかどうかを判断できます。WDTOFフラグはソフトウェアによってクリアされなければなりません。 デバイスのリセットは正しく行われるものの、その後フラグが設定されていないようです。 LPC4357で似たような問題に関する古い投稿(解決済み:LPC4357:ウォッチドッグリセットを検出できない - NXPコミュニティ)を見かけましたが、LPC18xxのエラッタには何も記載されていませんでした。 LPC18xxも上記と同じ問題を抱えているかどうか確認していただけますか? lpc18xx Re: Cannot detect watchdog reset for LPC18xx こんにちは@ejg 投稿ありがとうございます！ どのLPC18xxを使っているのか、具体的に教えていただけますか? また、国旗をレビューしたのはいつですか？ lpc18xx_wwdt.hからWWDT_Init関数を呼び出すと割り込みフラグが消去されるため、WDTOFを読み込む必要があります。

IMX219（RPi Cam v2）在 FRDM-IMX93 上使用原装 imx93-11x11-frdm-imx219 芯片时，可以探测但无法传输数据流。 环境 - 电路板：FRDM-IMX93 (i.MX93 11x11) - 电路板支持包：Yocto Scarthgap，linux-imx-6.6.36-2.1.0（内核提交 20d9f5efabdd）， MACHINE=imx93frdm，DISTRO=fsl-imx-xwayland - 传感器：树莓派摄像头模块 v2（索尼 IMX219），位于 P6 MIPI-CSI 连接器上 - 设备树：stock arch/arm64/boot/dts/freescale/imx93-11x11-frdm-imx219.dtso 概括 该电路板支持包。包含一个适用于此板的IMX219设备树覆盖层，以及传感器。 上电后，I2C 检测到芯片 ID 为 0x10 的芯片 ID 读取为 0x0219。然而， V4L2 捕获管道从未交付过帧。追溯下去，似乎有 下游分阶段摄像机驱动程序中存在三个独立问题。主线 sony,imx219 驱动程序遵循现代 V4L2 子设备模型，而 NXP staging CSI/ISI 协议栈仍然采用较旧的 ov5640 型模型。 问题 1 — 媒体图拆卸（“传感器注册失败”） drivers/staging/media/imx/imx8-media-dev.c: mxc_md_create_links() 调用 media_entity_call(sensor, link_setup, ...).主线 imx219 驱动程序不 实现 .link_setup，因此，该调用返回 -ENOIOCTLCMD (-515) 并被视为 致命的。传感器到CSI的连接从未建立，整个媒体设备被拆除： mx8-img-md：已注册传感器子设备：imx219 2-0010 (1) mx8-img-md：创建链接 [mxc_isi.0]=> [mxc_isi.0.捕获] mx8-img-md：创建链接 [mxc-mipi-csi2.0]=> [mxc_isi.0] mx8-img-md：子设备通知器完成错误退出 mxc-md 42800000.总线:camera:传感器注册失败 mxc-md：探测 42800000.总线:camera失败，错误代码 -515 （ov5640 之所以有效，是因为 ov5640.c提供空操作 .link_setup。） 问题 2 — streamon 中止（“调用子设备 s_power 失败！”） drivers/staging/media/imx/imx8-isi-cap.c: mxc_isi_cap_streamon() 调用 v4l2_subdev_call(src_sd, core, s_power, 1) 并将失败视为致命错误。imx219 使用 运行时 PM，并且未实现已弃用的 .s_power，所以呼叫返回 -ENOIOCTLCMD 和流式传输中止： mxc_isi.0：调用子设备 s_power 失败！ （ov5640 之所以有效，是因为 ov5640.c提供 .s_power。） 问题 3 — CSI 硬编码为 YUV422，无法解析 RAW10（链接已建立，但帧数为 0） drivers/staging/media/imx/dwc-mipi-csi2.c 实际上仅支持 YUV422： - dwc_csi2h_formats[] 仅列出 SBGGR Bayer 代码，不列出 SRGGB（IMX219 为 SRGGB10）。 因此 find_csi2h_format() 失败，格式默默地恢复为 YUYV。 - dwc_mipi_csi2_set_fmt() 永远不会存储 csi2h->format，因此 disp_mix_gasket_config() 看到默认的 YUYV 代码。 - dwc_mipi_csi2_param_init() 硬编码 ipi_cfg->data_type = DT_YUV422_8。 CSI随后报告了错误的数据类型，即使所有帧都已捕获，也未捕获到任何帧。 链接已启用，VIDIOC_STREAMON 返回 0： mxc-mipi-csi2.0：格式：0x2008 <- YUYV；预期为 0x300f (SRGGB10) 是什么让它对我们有效（供您验证） 在 (a) 使 imx8-media-dev / imx8-isi-cap 处理缺失的可选操作之后 （-ENOIOCTLCMD 来自 link_setup / s_power）作为非致命错误，以及（b）教学 dwc-mipi-csi2 关于 SRGGB8/10/12（存储协商格式并设置 IPI） 从中获取数据类型），管道启动正常：- mxc-mipi-csi2.0：格式：0x300f imx219 -> mxc-mipi-csi2.0 -> mxc_isi.0-> /dev/video0 约27帧/秒，实时帧捕获。 修复（a）与传感器无关，有助于此堆栈上的任何现代主线传感器； 修复 (b) 为 CSI 添加了 RAW Bayer 支持。 次要说明——模块加载顺序 在全新启动后，由于 imx8_media_dev 运行，图形也无法注册。 在 imx219 模块加载之前，异步通知器会注册视频节点。 然后注销。手册“modprobe -r imx8_media_dev imx219; modprobe imx219; modprobe imx8_media_dev”会重建它。软装卸/装载顺序提示可以实现这一点。 无需任何额外操作即可使用。 问题 1.在这个BSP中，IMX219是否是FRDM-IMX93上官方支持/验证的摄像头？ 预期/已验证的路径是 AP1302 ISP 模块吗？已发货的 imx219.dtso 这表明裸露的 IMX219 应该可以正常工作。 2. 以上三种行为是否属于您会接受修复的漏洞，还是 是否存在我们遗漏的推荐/已知良好的配置？ 3.如果需要，我很乐意将这些补丁作为干净的提交分享出来。 谢谢！ FRDM-i.MX93 #IMX219 RPI-CAM-MIPI Yocto Project Re: IMX219 (RPi Cam v2) probes but does not stream on FRDM-IMX93 with stock imx93-11x11-frdm-imx219 你好， 感谢您的联系，我会与软件团队核实，并再次确认后续的 BSP 版本中是否有针对此问题的修复，如有更新，我会尽快通知您。 此致敬礼/Saludos， 阿尔多。 Re: IMX219 (RPi Cam v2) probes but does not stream on FRDM-IMX93 with stock imx93-11x11-frdm-imx219 你好， 遗憾的是，i.MX93 FRDM 电路板支持包 直到后来才在我们的 电路板支持包 中得到正式支持。在我调查这个问题时，该图像可能是该 电路板支持包 的 beta 版本。 我们支持 FRDM 开发板 6.12.34-2.1.0 版本。对于后续版本，我非常感谢您的发现，这对任何使用板载默认镜像进行验证的人都应该很有用，我会与软件团队跟踪此事。 此致敬礼/Saludos， 阿尔多。

libcamera on imx8mp Hi NXP FAEs:      I would like to know currently if NXP have any libcamera support on imx8mp platform?       https://libcamera.org/getting-started.html.      I see in yocoto kirkstone bsp, recipe libcamera is under meta-openembedded/meta-multimedia/recipes-multimedia/libcamera/libcamera.bb. when I add target libcamera into image and run on imx8mp-evk board, libcamera reports nothing when detecting capture device. and when run gst-launch, the result is the same. LIBCAMERA_LOG_LEVELS=*:DEBUG gst-device-monitor-1.0 Video IPAModule ipa_module.cpp:329 ipa_vimc.so: IPA module /usr/lib/libcamera/ipa_vimc.so is signed IPAManager ipa_manager.cpp:240 Loaded IPA module '/usr/lib/libcamera/ipa_vimc.so' Camera camera_manager.cpp:293 libcamera v0.0.0 Camera camera_manager.cpp:106 Starting camera manager DeviceEnumerator device_enumerator.cpp:224 New media device "mxc-md" created from /dev/media0 DeviceEnumerator device_enumerator_udev.cpp:95 Defer media device /dev/media0 due to 1 missing dependencies DeviceEnumerator device_enumerator_udev.cpp:320 All dependencies for media device /dev/media0 found DeviceEnumerator device_enumerator.cpp:252 Added device /dev/media0: mxc-md Camera camera_manager.cpp:149 Found registered pipeline handler 'PipelineHandlerUVC' Camera camera_manager.cpp:149 Found registered pipeline handler 'SimplePipelineHandler' Camera camera_manager.cpp:149 Found registered pipeline handler 'PipelineHandlerVimc'       when I read back the libcamera code, I find camera need be registered before libcamera use it. bool PipelineHandlerRPi::match(DeviceEnumerator *enumerator) { DeviceMatch unicam("unicam"); MediaDevice *unicamDevice = acquireMediaDevice(enumerator, unicam); if (!unicamDevice) { LOG(RPI, Debug) << "Unable to acquire a Unicam instance"; return false; } DeviceMatch isp("bcm2835-isp"); MediaDevice *ispDevice = acquireMediaDevice(enumerator, isp); if (!ispDevice) { LOG(RPI, Debug) << "Unable to acquire ISP instance"; return false; } int ret = registerCamera(unicamDevice, ispDevice); if (ret) { LOG(RPI, Error) << "Failed to register camera: " << ret; return false; } return true; }       so, I have below questions.       1. Does NXP bsp currently support libcamera, such as for camera device ov5640?        2. If not, does NXP have any plan to support libcamera or have any suggestion/reference design/guid/patch for that?        3. How complex is it for adding suppor to a new camera in libcamera?        I am quite new for libcamera and expect your help/guid/information. best regards. Johnson Re: libcamera on imx8mp I'm also interested in the VSI SDK. It would be very useful if I could use 3A algorithms of the Vivante ISP8000 on frames captured from an external camera Re: libcamera on imx8mp Hi Sanket Parekh, Thanks for the information. I will explore more basing on your information. Best regards. Johnson Re: libcamera on imx8mp Hi @Sanket_Parekh , What is the vsi SDK and how to access it, please ? Thanks in advance and best regards, Khang Re: libcamera on imx8mp Hello @zhangjunsheng  I hope you are doing well. if the customer has not their algorithm for 3A and other modules, we don't suggest they use lib-camera, VSI sdk is good chooise. we will support vsi SDK now. if the customer has interesting in lib-camera and they are isp expert, there is an open source on GitLab  https://gitlab.com/ideasonboard/nxp/libcamera Thanks & Regards, Sanket Parekh Re: libcamera on imx8mp Hi @zhangjunsheng , I found this repository : https://gitlab.com/ideasonboard/nxp/libcamera Re: libcamera on imx8mp Just wanted to highlight in here, that - yes i.MX8MP is very well supported in libcamera, but you have to enable the correct kernel drivers on the linux kernel. libcamera uses the seemingly not-obviously named RKISP1 driver in the linux kernel because the ISP shares common heritiage, but the platform itself has really strong support, is in commercial products, and we can support many use cases, and customisations easily. All with the benefit that you don't have to sign any license agreements, and you get the full source code! (it's all publicly available upstream at https://gitlab.freedesktop.org/camera/libcamera  )

Issue with Wi Fi CLI Open Thread CLI Dear Sir, We are using FRDM MCXW72 , to configure as OT-CLI  End node. We tried the procedure as per document UG10349. We are not able to go ahed after the step 5  i.e. Run the scripts to build all examples. $ ./script/build_mcxw72 after this command. Please guide resolve. FRDM-Training Re: Issue with Wi Fi CLI Open Thread CLI Hello, Hope you are doing well. MCXW72 does not support Wi-Fi, so no Wi-Fi CLI can work on this MCU. Could you please clarify what repository and release are you using? Best Regards, Ricardo Re: Issue with Wi Fi CLI Open Thread CLI Hi, Could you please clarify what repository and release are you using? The log indicates that the build is failing because the Arm GCC compiler cannot be found. The compiler path being used by CMake appears to be invalid, which suggests a toolchain path configuration issue. Could you please verify your ARMGCC_DIR configuration and confirm that arm-none-eabi-gcc is installed and accessible from that location? Once the compiler is correctly detected, the build should proceed further. Regards, Ricardo Re: Issue with Wi Fi CLI Open Thread CLI We are trying to use FRDM MCXW72 for OT CLI. Re: Issue with Wi Fi CLI Open Thread CLI Dear Sir, We are trying  code FRDMRW612 _Wifi_IPv4_IPv6_Echo on FRDM RW612 Its working TCP server we are able to get the echo as per attached. Now we are working to modify code for LED ON connected on port  GPIO 27 on FRDM Tried to do related changes in Config Pin as well as in the file socket_task.c We found the responce  is not coming on the terminal window after reset  but  Blue LED is glowing on FRDM board. Please communicate the resolution on the issue. We are not able to send the code as code size .zip is extending limit of 50Mb. Regards Seema Joshi