how i can build FCB data from MCUXpresso Secure Provisioning Tool Hello. I am currently testing OTFAD configuration on an RT1010 EVK board. I would like to configure OTFAD using MCUXpresso Secure Provisioning Tool 26.03 and build the project to generate binary files. The build results are: MIMXRT1011_Project.bin MIMXRT1011_Project_hab.bin otfad_keyblobs.bin unsigned_MIMXRT1010_flashloader.bin These are the four files. When I perform a write operation using MCUXpresso Secure Provisioning Tool 26.03 and read the flash memory, the program includes data presumed to be FCB at the 0x0400 region. However, it appears that there is no file corresponding to the FCB among the built files. Is it possible to generate a file containing FCB information during the build process? i.MXRT 101x Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool Thank you for your reply. I created the FCB by referring to the link you provided. I have one more question. In which document can I find the explanation regarding the key data for Region 0 info in the OTFAD settings? The parts I am curious about are the User key data and counter data sections. Could you please explain it to me? Thank you. TnseoRnr_0-1785208042935.png Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool Hi @TnseoRnr, Please see the following link from the SPT Documentation, which specifies the process to create a complete FCB from the simplified configuration: https://mcuxpresso.nxp.com/secure/26.03/05_user_interface.html#spi-nor It also mentions that the FCB can be generated from MCUXpresso via the Peripherals tool if you prefer to do so. One last note, keep in mind that there is a newer version of SPT available (v26.06), so I would suggest you continue development on the latest version. BR, Edwin. Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool Hi @TnseoRnr, If you mean how these fields would be used on the OTFAD configuration you are creating, perhaps this link might help: https://mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#booting-otfad-encrypted-image-unsigned-with-user-keys That said, if you are looking for the inner workings or a more in-depth explanation of how these keys are used, you would need to request access to the RT1010 secure files, and look in the Security Reference Manual, which precisely explains the security features of the RT1010 in detail. You will be prompted to download this file, or request access if needed, by clicking on the "Secure" checkbox of the documentation section of the RT1010 product page: https://www.nxp.com/products/i.MX-RT1010#documentation BR, Edwin.

KW45B41Z EVK 无法通过板载调试器 MCU Link 进行编程。 你好， 我正在尝试使用kw45b41zevk_hello_world SDK 示例代码对KW45B41Z-EVK进行编程。开始调试时，板载调试器被检测到，但随后出现以下错误： 未检测到可用短波除尘设备。 连接设备后再试一次。 我已将 USB 电缆连接到J14 ，并将JP22 保持开路状态（以便使用板载调试器本身进行编程）。此外，如KW45UM中所述， JP28 引脚 1 和 2 短路了。然而，即使那样，我仍然无法对示例进行编程和调试。 我也尝试过kw45b41zevk_led_blinky SDK 示例，但它的表现也一样。 我还尝试使用外部调试器通过短接JP22来调试电路板，正如KW45UM中所述，但我遇到了同样的问题。 我附上了遇到的问题的截图。 我还尝试使用安全配置工具擦除闪存并写入映像。首先，我短接JP25以启用SW4 ，进入 ISP 模式，然后长按SW4和RESET (SW3) 。测试连接通过后，我成功擦除了闪存（位置0x00000000 ，大小0x100000 ）。然后我使用了以下图片： ${SPT_INSTALL_BIN} \data\sample_data\targets\KW45B41Z8\source_images\kw45b41zevk_led_blinky.s19 我已经成功构建并编程了图像，并且预期的RGB LED1也闪烁，表明 KW45B41Z 微控制器工作正常。然而，即使这样，我仍然无法对电路板进行编程或调试。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. 你好， @kaif1 你使用的是哪个集成开发环境（IDE）？ MCUXpresso IDE 还是 MCUXpresso for VS Code？ 让我先试一下，然后告诉你默认的跳线设置。 顺祝商祺！ Christine。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. 你好， @kaif1 请参考我的跳线设置，我在本地验证过，可以成功地将 hello_world 示例烧录到板上。 我使用的是 MCUXpresso IDE，SDK 版本为 25.12.00。 请尝试一下我的跳线设置，然后告诉我是否有效。 顺祝商祺！ Christine。

IMX95 Aquila ISP の使用状況 こんにちは、 私はAquila IMX95評価キット2を2つのov5640センサ(https://www.toradex.com/cart)搭載で購入しました。 センサのドライバは持っています。基板は正しくフラッシュされ、ISPモジュールもアクティブになっています。 root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 カメラはlibcameraに表示されています。 root@imx95-1:~# libcamera -sh: libcamera: command not found root@imx95-1:~# cam -l [17:17:31.010001558] [2747] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) [17:17:31.044088474] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 4-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.044159391] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 4-003c': The sensor kernel driver needs to be fixed [17:17:31.044178224] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 4-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.044882558] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 4-003c': Failed to retrieve the camera location [17:17:31.044918891] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 4-003c': Rotation control not available, default to 0 degrees [17:17:31.045722599] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 3-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.045762974] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 3-003c': The sensor kernel driver needs to be fixed [17:17:31.045783849] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 3-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.046362016] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 3-003c': Failed to retrieve the camera location [17:17:31.046388308] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 3-003c': Rotation control not available, default to 0 degrees [17:17:31.048068724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048640224] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048904099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049145974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049451724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049694683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049937141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050184266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050477516] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050720433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050962433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051201724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051441724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051683308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051925308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052259141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052510099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061185308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061469974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061736058] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061988683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062242933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062489474] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062733266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062980349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063228266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063470391] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063712849] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063953933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064216891] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064463349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064706683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064958766] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.065200974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 Available cameras: 1: 'ov5640' (/base/soc/bus@42000000/i2c@42540000/camera@3c) 2: 'ov5640' (/base/soc/bus@42000000/i2c@426e0000/camera@3c) MIPが正常に動作しているかどうかを確認するために、GStreamerパイプラインを起動したところ、両方のカメラで安定した30fpsのストリームを取得することができました。v4l2-ctlを使ってスナップショットを撮ることにも成功しました。 今、AquilaのISPをカメラでテストしてみたいと思っています。 https://www.nxp.com/docs/en/user-guide/UG10215.pdfに従って環境変数を追加しました。 root@imx95-1:~# export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' しかし、そうするとlibcameraにカメラが検出されなくなり、なぜかはわかりません: root@imx95-1:~# cam -l [17:36:38.947430563] [2788] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) Available cameras: root@imx95-1:~# お返事ありがとうございます ！ 敬具 Re: IMX95 Aquila ISP usage ログを見たところ、問題はMIPIインターフェースやOV5640ドライバ自体には関係ないと思います。 事実： 両方のOV5640カメラはlibcameraによって検出されます GStreamer は30fpsでストリーミング可能です V4L2-CTLは画像を撮影できます センサードライバー、I2C通信、  CSI-2  links、メディアトポロジーがすべて正常に動作していることを示します。 重要な点は、NXP Neo ISPパイプラインがRAWのBayerセンサー入力を想定していることです。 OV5640は独自の内部画像処理パイプラインを持つSoCイメージセンサーであり、NXP BSPでは通常、RAWバイヤーセンサーとしてではなくYUV出力モード(例:YUV422)で使用されます。このような構成では、カメラは標準のV4L2/libcameraパイプラインを通じて使用できますが、Neo ISPパイプラインの要件には合致しません。 これは以下の理由を説明するだろう。 `cam -l` はデフォルトで両方の OV5640 カメラを表示します 設定後 export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' カメラは検出されなくなりました カメラはシステム内に存在しますが、NEOパイプラインハンドラーは互換性のあるカメラトポロジーを見つけられず、そのためlibcameraにはカメラが0台も露出します。 実際のセンサー出力フォーマットを確認するために、以下の出力を教えていただけますか: 「バッシュ」 media-ctl -p V4L2-ctl --list-formats-ext 特に、センサーが以下のようなRAWバイヤーフォーマットを露出しているかどうかに関心があります: SBGGR8 SBGGR10 SRGGB10 RG10 BA10 YUVフォーマット(例:YUYV/UYVY)のみが利用可能な場合、カメラはRAWモードで動作せず、Neo ISPパイプラインで処理できません。 OV5640ハードウェアはRAWバイヤー出力に対応していますが、BSPカメラドライバーではRAWサポートは一般的に有効ではなく、NXP Neo ISPスタックもセンサー固有のチューニングデータに依存しています。RAW出力が有効であっても、専用のOV5640チューニングプロファイルがないため、ISPの適切な動作(AE/AWB/画像品質チューニング)が妨げられる可能性があります。 もしNeo ISPフレームワーク自体を評価するのが目的なら、NXP ISPスタックで動作することが知られているセンサを使う方が簡単かもしれません。一般的な候補としては、以下のようなものがあります。 OS08A20 OX03C10 OX05B1S AR0521 AR1335（追加の調整作業が必要になる場合があります） 上記のコマンドの出力を教えてもらえますか?これにより、現在のOV5640の設定がRAWベイヤーフォーマットをシステムに公開しているかどうかを確認できます。 よろしくお願いします、 Re: IMX95 Aquila ISP usage ご返信ありがとうございます。 追加の確認を行いました。 おっしゃる通り、OV5640は最初は UYVYモードで動作していましたが、手動で1つのセンサーを RAWのBayer(SRGGB8)に切り替えました。 media-ctl -p は現在次のように表示します:   root@imx95-1:~# media-ctl -p Media controller API version 6.12.55 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.55 Device topology - entity 1: crossbar (13 pads, 11 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 3/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 3/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 3/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 3/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "4ac10000.syscon:formatter@120":1 [ENABLED,IMMUTABLE] pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video8 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video9 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@120 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "csidev-4ad40000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "crossbar":3 [ENABLED,IMMUTABLE] - entity 115: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 120: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] <- "ov5640 4-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 125: csidev-4ad40000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev12 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "ov5640 3-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "4ac10000.syscon:formatter@120":0 [ENABLED,IMMUTABLE] - entity 130: ov5640 4-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080@1/30 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad30000.csi":0 [ENABLED] - entity 134: ov5640 3-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev14 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad40000.csi":0 [ENABLED] （比較のため、2台目のOV5640はUYVYモードのままです） SO : OV5640 -> SRGGB8 CSI -> SRGGB8 フォーマッター -> SRGGB8 クロスバー -> SRGGB8 => RAWバイエルはセンサ、CSI、フォーマタを通じて正常に伝播されています。 neoispカーネルモジュールがロードされました。 root@imx95-1:~# modprobe neoisp root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 実行中のデバイスツリーにISPノードが存在します。   /sys/firmware/devicetree/base/soc/isp@4ae00000   => しかし、CSI/Formatter/ISIパイプラインを公開しているメディアデバイス(/dev/media0)は1台だけです。メディアグラフにはneoispのエンティティは現れません。メディアのグラフにneoispの存在は見当たりませんし、これが予想されるものなのかも分かりません。 => cam -l (libcamera) を実行しても、利用可能なカメラは返されません。 現時点ではRAWのBayerパスは機能しているようですが、Neo ISPがどこでアクティブなパイプラインの一部になるのかは特定できません。   ストリームが実際にNeo ISPによって処理されているか、単にCSI -> Formatter -> ISI経路をたどるのではなく、どうやって確認できますか?   また、 https://www.nxp.com/docs/en/user-guide/UG10215.pdf も参照してください。この構成に関する推奨ガイドはまだありますか？それとも、i.MX95 上で OV5640 + Neo ISP を使用するためのより具体的な参考資料はありますか？       敬具 Re: IMX95 Aquila ISP usage 現時点で私が疑っているのは、以下のいずれかが起こっているということです。 OV5640はRAWベイヤーモードではなく、YUVモードで動作している可能性が高い。 カメラのDTオーバーレイは、ISP対応バージョンではありません。 Neo IPA/キャリブレーションコンポーネントがルートファイルシステムに存在しません。 Neoパイプラインで見られるメディアトポロジーは、期待されるi.MX95のISPグラフと一致しません。 media-ctl -pの出力は通常、どちらが実際の問題かを特定します。 Re: IMX95 Aquila ISP usage こんにちは！ 出力結果は以下のとおりです。 root@imx95-1:~# v4l2-ctl --list-formats-ext -d /dev/video2 ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'YUYV' (YUYV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [1]: 'YUVA' (32-bit YUVA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [2]: 'NV12' (Y/UV 4:2:0, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [3]: 'NM12' (Y/UV 4:2:0 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [4]: 'NV16' (Y/UV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [5]: 'NM16' (Y/UV 4:2:2 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [6]: 'YM24' (Planar YUV 4:4:4 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [7]: 'RGBP' (16-bit RGB 5-6-5, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [8]: 'RGB3' (24-bit RGB 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [9]: 'BGR3' (24-bit BGR 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [10]: 'XR24' (32-bit BGRX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [11]: 'AR24' (32-bit BGRA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [12]: 'RA24' (32-bit ABGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [13]: 'AB24' (32-bit RGBA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [14]: 'RX24' (32-bit XBGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [15]: 'XB24' (32-bit RGBX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [16]: 'AR30' (32-bit ARGB 2-10-10-10, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [17]: 'GREY' (8-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [18]: 'Y10 ' (10-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [19]: 'Y12 ' (12-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [20]: 'Y14 ' (14-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [21]: 'BA81' (8-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [22]: 'GBRG' (8-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [23]: 'GRBG' (8-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [24]: 'RGGB' (8-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [25]: 'BG10' (10-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [26]: 'GB10' (10-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [27]: 'BA10' (10-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [28]: 'RG10' (10-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [29]: 'BG12' (12-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [30]: 'GB12' (12-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [31]: 'BA12' (12-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [32]: 'RG12' (12-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [33]: 'BG14' (14-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [34]: 'GB14' (14-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [35]: 'GR14' (14-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [36]: 'RG14' (14-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [37]: 'BYR2' (16-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [38]: 'GB16' (16-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [39]: 'GR16' (16-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [40]: 'RG16' (16-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [41]: 'MJPG' (Motion-JPEG, compressed, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 私の理解が正しければ、このカメラはRAWベイヤー形式で撮影できるはずなので、私もそのように設定しました（正しく設定できていればいいのですが）。 別のイメージを使って再度フラッシュしてみて、問題がそのあたりにあるかどうか確認してみます。 敬具 Re: IMX95 Aquila ISP usage 最新情報のご提供ありがとうございます。The  v4l2-ctl  outputはISIキャプチャノードがRAWバイエルフォーマットをサポートしていることを確認しており、前のメッセージの  media-ctl -p  outputはすでにRAWバイエルパスがパイプライン内で正しく伝播していることを示しています: OV5640 (SRGGB8) -> CSI (SRGGB8) -> フォーマッタ (SRGGB8) -> クロスバー (SRGGB8) つまり、センサー側の構成は正しいように見えます。 現在の核心的な問題は、  neoisp  モジュールが読み込まれているものの、プレスリリース、製品ニュースグラフに表示されず、  /dev/media1  が作成されていないことです。これは通常、  neoisp  ドライバがカーネルモジュールとしては正常にロードされたが、デバイスプローブ中に失敗し、プレスリリース、製品ニュースデバイスの登録ができなくなることを意味します。 以下の診断情報を教えていただけますか? # Neoispプローブの状態を 確認 dmesg |grep -i neoisp dmesg |grep -i "isp@4ae" DMESG |grep -i 「プローブ失敗」 DMESG |grep -i "4ae00000" # 利用可能なプレスリリース、製品ニュース機器を ls -la /dev/プレスリリース、製品ニュース* # sysfs の neoisp ステータスを確認してください ls /sys/bus/プラットフォーム/ドライバ/nxp-neoisp/ cat /sys/firmware/devicetree/base/soc/isp@4ae00000/status 並行してお聞きしたいのですが、NXP Neo ISPスタックで公式にサポートされている以下のセンサのいずれかに、完全なチューニングプロファイルでアクセスできますか? OS08A20 OX03C10 OX05B1S これらのセンサのいずれかでテストすることで、Neo ISPドライバ自体が環境で正しく動作しているかを迅速に確認でき、問題がドライバや環境に関係するのか、OV5640特有のものかを特定するのに役立ちます。 OV5640はRAWのBayer出力が可能ですが、公式のNXP Neo ISPチューニングプロファイルは持っておらず、パイプラインが正しくコネクテッドされていてもAE/AWBや画像品質チューニングは利用できません。 Re: IMX95 Aquila ISP usage 最新情報： 社内で調査した結果、OV5640とi.MX95 NeoのISPパイプラインに関して以下の所見をお伝えしたいと思います。 OV5640はRAWのバイエルデータの出力が可能ですが、以下の理由から一般的にOV5640+Neo ISPの組み合わせは新しいデザインに推奨しません。 OV5640はすでに寿命切れ(EOL)センサです。 RAW出力はサポートされていますが、センサ自体は最新のRAWセンサに比べて調整可能なコントロールが限られています。 NXPのi.MX95リファレンスカメラソリューションは、すでにNeo ISPソフトウェアフレームワーク内でサポート・検証されているOS08A20などのRAWセンサに基づいています。 したがって、弊社の推奨案は以下のいずれかとなります。 OV5640を既存の画像プロセッシングパスと併用してください(Neo ISP AE/AWBチューニング機能に依存しません)。 Neo ISPのフル機能が必要な場合は、NXP対応のRAWセンサー(OS08A20など)を使用してください。 もしOV5640をNeo ISPパイプラインで使用する必要がある場合は、追加のソフトウェアエンイネーブルメント作業が必要となります。 OV5640 + Neo ISP方式の場合、libcamera CameraHelperを実装する必要があります。以下のファイルが開始参照として使用できます: camera_helper_ov5640.cpp https://github.com/nxp-imx/libcamera/blob/lf-6.6.52_2.2.0/src/ipa/nxp/cam_helper/camera_helper_ov5640.cpp このCameraHelperの実装は、あくまでも第一歩に過ぎないことにご注意ください。主な目的は、libcameraがOV5640センサーを認識し識別できるようにすることです。追加のセンサー特有の適応は依然として必要です。 例えば、Neo ISP 車載 Exposure(AE)が動作すると予想される場合、センサの利得変換関数などのAPIを実装する必要があります。IMX219 CameraHelperの実装に簡単な例があります: https://github.com/nxp-imx/libcamera/blob/lf-6.18.20_2.0.0/src/ipa/nxp/cam_helper/camera_helper_imx219.cpp 特に、顧客は以下の間のマッピングを決定し実装する必要があります: センサーゲインコード 実アナログゲイン乗算器(ゲイン値) これにより、Neo ISP AEアルゴリズムがセンサの露出と利得を正しく制御できるようにしています。 CameraHelperの開発の詳細については、カメラ移植ガイドをご参照ください: セクション5.3 – 「新しいセンサのためのlibcamera CameraHelperの実装」 OV5640の特別な考慮点の一つは、すでに独自のAE機能を備えています。したがって、Neo ISP AEアルゴリズムの代わりにセンサ内部AEを継続使用する意図がある場合、gainCodeToGain()やgainToGainCode()などの実装は必ずしも必要とは限りません。この場合、センサ検出専用の基本的なCameraHelperでパイプラインを起動するのに十分かもしれません。 しかし、画像品質の調整は評価と調整が必要です。OV5640は元々Neo ISP基準センサとして特性評価・調整されていなかったため、最適な画像品質を得るために追加のISPチューニング作業が必要になる場合があります。 全体として、OV5640のRAW出力はi.MX95 Neo ISPパイプラインに接続可能ですが、センサー固有のlibcameraやISP統合作業が期待されています。新しい開発については、可能な限りNeo ISP認証済みRAWセンサー(OS08A20など)を使用することを推奨します。 Re: IMX95 Aquila ISP usage 前回の議論に続き、Neo ISPパイプラインがOV5640センサーを認識できない根本原因を調査しました。 問題は、NXP Neo IPA(Image プロセッシング Algorithm)フレームワークがa  CameraHelper  factoryを使って、カーネルのV4L2サブ開発モデル文字列を照合してセンサ固有のゲイン/露出アルゴリズムを調べていることです。 CameraHelper "ov5640" に登録されていなかったため、工場出荷時は nullptr が戻り、ISPパイプラインはこのセンサに設定できませんでした。 これに対処するため、  CameraHelper  をOV5640センサ用にNXPカーネルドライバ( drivers/media/i2c/ov5640.c )に基づく実装しました😞 ゲインレジスタのマッピング: 登録する：  OV5640_REG_AEC_PK_REAL_GAIN  ( 0x350a )、10ビット値 形式: Q6.4 固定小数点、ユニティゲイン = 16 gainCode(g) = round(g * 16) ゲイン(コード) = コード / 16.0 2つのファイルが変更されました。 camera_helper_ov5640.cpp – OV5640用の新しいCameraHelper実装で、カーネルのサブ開発モデル文字列に合わせて "ov5640 " として登録 メソンビルド  - 追加した  camera_helper_ov5640.cpp  ビルドソースリストへ これらの2つのファイルを使用してlibcameraを再構築し、再度試してください。  LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 。Neo ISPパイプラインは今後OV5640センサーを見つけて設定できるようになるはずです。 なお、これによりゲイン／露出制御パスは有効になりますが、OV5640用の完全なISPチューニングプロファイル（AE／AWBパラメータ）はまだ利用できません。画像品質調整にはさらなる作業が必要かもしれません。 再建後の結果をお知らせください。

如何从 MCUXpresso 安全配置工具构建 FCB 数据 您好。 我目前正在RT1010 EVK板上测试OTFAD配置。 我想使用 MCUXpresso Secure Provisioning Tool 26.03 配置 OTFAD 并构建项目以生成二进制文件。 版本结果如下： MIMXRT1011_Project.bin MIMXRT1011_Project_hab.bin otfad_keyblobs.bin unsigned_MIMXRT1010_flashloader.bin 这是四个文件。 当我使用 MCUXpresso Secure Provisioning Tool 26.03 执行写入操作并读取闪存时，程序在 0x0400 区域包含被认为是 FCB 的数据。 然而，在版本文件中，似乎没有与 FCB 对应的文件。 是否可以在版本过程中生成包含 FCB 信息的文件？ i.MX RT101x Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool 感谢您的回复。 我参考您提供的链接创建了 FCB。 我还有一个问题。 我可以在哪个文档中找到有关 OTFAD 设置中 Region 0 信息关键数据的说明？ 我感兴趣的部分是用户密钥数据和计数器数据部分。 你能给我解释一下吗？ 谢谢！ TnseoRnr_0-1785208042935.png Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool 嗨@TnseoRnr ， 请参阅 SPT 文档中的以下链接，其中详细说明了如何从简化配置创建完整的 FCB： https://mcuxpresso.nxp.com/secure/26.03/05_user_interface.html#spi-nor 它还提到，如果您愿意，也可以通过 MCUXpresso 的外设工具生成 FCB。 最后提醒一下，SPT 有更新的版本（v26.06），所以我建议您继续使用最新版本进行开发。 BR， 埃德温。 Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool 嗨@TnseoRnr ， 如果您指的是这些字段将如何在您创建的 OTFAD 配置中使用，或许以下链接会有所帮助： https://mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#booting-otfad-encrypted-image-unsigned-with-user-keys 也就是说，如果您正在寻找有关这些密钥的内部运作或更深入的解释，您需要请求访问 RT1010 安全文件，并查看网络安全参考手册，其中详细解释了 RT1010 的网络安全功能。 系统会提示您下载此文件，或者在需要时请求访问权限，方法是单击 RT1010 产品页面文档部分的“安全”复选框： https://www.nxp.com/products/i.MX-RT1010#documentation BR， 埃德温。

frdm-imx93 not booting even with demo images from NXP I am trying to bring up the frdm-imx93 from the SD Card. It works just fine from the emmc.  I downlowaded ZIPRev 4.0Jun 25, 20252.45 MBLF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 from the NXP site link. THen I did the following: zstd -d imx-image-full-imx93frdm.rootfs.wic.zst sudo dd if=imx-image-full-imx93frdm.rootfs.wic of=/dev/sdc bs=1M status=progress && sync sudo dd if=imx-boot-imx93frdm-sd.bin-flash_singleboot of=/dev/sdc bs=1k seek=32 status=progress Then I put the sdcard in the slot and tried to boot, after setting SW1[3:0]=0011. However the boot does not progress beyond this point: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok Someone please help asap... Thanks in advance! Re: frdm-imx93 not booting even with demo images from NXP I see the same thing in the serial port, i have tried with multiple cables Re: frdm-imx93 not booting even with demo images from NXP Hello, When you are following this procedure, what error do you see in board serial port? If it cannot go to fast-boot mode, please try with another USB cable. Best regards. Re: frdm-imx93 not booting even with demo images from NXP I got a bit ahead, but not yet into the OS. I think the issue is with the contents of my boot drive, as well as the singleboot binary itself.  Again I need someone knowledgeable about the board to help me with this. Re: frdm-imx93 not booting even with demo images from NXP Hi, having the same problem. Tried different images on both windows and Linux, and on different Linux distros. Both EMMC and SD-card is not working Did you ever figure it out?  Re: frdm-imx93 not booting even with demo images from NXP Hello This is what I did: root@debian:/mnt/host/LF_v6.6.36-2.1.0_images_FRDM_3.0_i.MX93# uuu -V -b sd_all imx-boot-imx93frdm-sd.bin-flash_singleboot imx-image-full-imx93frdm.rootfs.wic.zst uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-5-g124d086   Build in config: Pctl Chip Vid Pid BcdVersion Serial_No ================================================== SDPS: MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS: MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS: MX8DXL 0x1fc9 0x0147 SDPS: MX28 0x15a2 0x004f SDPS: MX815 0x1fc9 0x013e SDPS: MX865 0x1fc9 0x0146 SDPS: MX8ULP 0x1fc9 0x014a SDPS: MX8ULP 0x1fc9 0x014b SDPS: MX93 0x1fc9 0x014e SDPS: MX91 0x1fc9 0x0159 SDPS: MX95 0x1fc9 0x015d SDPS: MX95 0x1fc9 0x015c SDPS: MX943 0x1fc9 0x0027 SDPS: MX952 0x1fc9 0x0028 SDP: MX7D 0x15a2 0x0076 SDP: MX6Q 0x15a2 0x0054 SDP: MX6D 0x15a2 0x0061 SDP: MX6SL 0x15a2 0x0063 SDP: MX6SX 0x15a2 0x0071 SDP: MX6UL 0x15a2 0x007d SDP: MX6ULL 0x15a2 0x0080 SDP: MX6SLL 0x1fc9 0x0128 SDP: MX7ULP 0x1fc9 0x0126 SDP: MXRT106X 0x1fc9 0x0135 SDP: MX8MM 0x1fc9 0x0134 SDP: MX8MQ 0x1fc9 0x012b SDPU: SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV: SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV: SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU: SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU: SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV: SPL1 0x3016 0x1001 [0x0500..0x9998] FBK: 0x066f 0x9afe FBK: 0x066f 0x9bff FBK: 0x1fc9 0x0153 FB: 0x0525 0xa4a5 FB: 0x18d1 0x0d02 FB: 0x3016 0x0001 FB: 0x1fc9 0x0152 FB: 0x0483 0x0afb FB: 0x1d6b 0x0104   Run built-in script:   uuu_version 1.4.149   # @_flash.bin            | bootloader, which can extract from wic image # @_image   [_flash.bin] | wic image burn to emmc.     # This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ SDP: boot -f imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000   # This command will be run when ROM support stream mode # i.MX8QXP, i.MX8QM SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000   # These commands will be run when use SPL and will be skipped if no spl # SDPU will be deprecated. please use SDPV instead of SDPU # { SDPU: delay 1000 SDPU: write -f imx-boot-imx93frdm-sd.bin-flash_singleboot -offset 0x57c00 -scanlimited 0x800000 SDPU: jump -scanlimited 0x800000 # }   # These commands will be run when use SPL and will be skipped if no spl # if (SPL support SDPV) # { SDPV: delay 1000 SDPV: write -f imx-boot-imx93frdm-sd.bin-flash_singleboot -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 # }   FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${sd_dev} FB: ucmd mmc dev ${sd_dev} FB: flash -raw2sparse all imx-image-full-imx93frdm.rootfs.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader imx-boot-imx93frdm-sd.bin-flash_singleboot FB: done     Wait for Known USB Device Appear... New USB Device Attached at 1:2- 1:2->Start Cmd:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 1:2->Fail HID(W): LIBUSB_ERROR_TIMEOUT (-7)(20.02s)     Best regards Re: frdm-imx93 not booting even with demo images from NXP Hello, Which command did you use? I'm not able to reproduce it. Best regards. Re: frdm-imx93 not booting even with demo images from NXP Hi! I did, yes. It always times out on both windows as well as linux, and on Linux I get a segmentation fault.  Re: frdm-imx93 not booting even with demo images from NXP Hello, Did you try to flash it with UUU? Best regards. Re: frdm-imx93 not booting even with demo images from NXP Hello, What do yo see in serial port? Is able to inter in fast-boot mode? Did you try with another BSP, version. I'm still unable to reproduce the issue in my side. Best regards. Re: frdm-imx93 not booting even with demo images from NXP Hello, On the serial port I only see SPL output. It never reaches full U-Boot, so I cannot enter the U-Boot prompt or fastboot mode. Serial output with the official Rev 4.0 image: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok Then there is no further output. I also tested a rebuilt Flexbuild/U-Boot 2025.04 boot image written to the SD card at 32 KiB offset. The board executes the new SPL, but it stops at the same point: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok So I cannot enter fastboot mode because it does not reach full U-Boot. I tested these BSP/images: 1. Official FRDM-i.MX93 Rev 4.0 image: LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 2. My own Yocto build for MACHINE=imx93frdm 3. Rebuilt Flexbuild/U-Boot 2025.04 SPL/container The official Rev 4.0 and my Yocto build use this boot image hash: 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot UUU also fails before flashing. The board is detected: MX93 SDPS 0x1FC9:0x014E but SDPS: boot times out: Start Cmd:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 Fail HID(W):LIBUSB_ERROR_TIMEOUT This happens on both Linux and Windows, and also after trying another laptop. I also verified SD boot mode selection: with SD boot mode selected and no SD card inserted, there is no serial output. With the SD card inserted, SPL starts and stops after M33 prepare ok. So currently the board never reaches U-Boot/fastboot. Re: frdm-imx93 not booting even with demo images from NXP I am too facing the same issues, I tried with all the 4 revisions available on the i.mx93 frdm portal, UUU always throws Fail HID(W): LIBUSB_ERROR_TIMEOUT (-7)(20.02s) for flashing into emmc as well as in sd. Re: frdm-imx93 not booting even with demo images from NXP I finally managed to get something working.  Used a 32GB SD Card as per spec Cloned the code from the NXP Yocto link, built the code and flashed in as mentioned in the documentation Flash it into the card, and boot up as mentioned. This worked for me. I think the problem was the uboot binary in the earlier attempt was meant for the evm and not the frdm. Re: frdm-imx93 not booting even with demo images from NXP did you solved it? I got same issue Re: frdm-imx93 not booting even with demo images from NXP Hi All,  I got the boards working, apparently there has been a Hardware change made on the FRDM-i.MX93 boards, and if you have an outdated U-boot bootloader (before 2025) then you are going to see this issue. You can check the U-Boot version in the serial monitor when you either try to boot or flash in the Serial Downloader mode. Example of old U-Boot version: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) Try with this Bootloader, with the below command, it should work for you 🙂 imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot  UUU command : uuu -b sd_all imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot  .wic.zst If the above bootloader did work for you then this is the current yocto i.MX BSP repo with the changes:  GitHub - nxp-imx/meta-imx: i.MX Yocto Project i.MX BSP Layer · GitHub Re: frdm-imx93 not booting even with demo images from NXP Your U-Boot looks old, apparently there has been a hardware change and and only the version after 2025 will support FRDM-IMX93. Please refer my above post, to flash the bootloader along with your image. Hope it works for you 🙂 Re: frdm-imx93 not booting even with demo images from NXP Hi @jventura, @qingyu, @ssb1, @skrimby123  Please try this out. Re: frdm-imx93 not booting even with demo images from NXP I´m having the exactly same issue too. Maybe its a board defect in newer boards? 😞 Re: frdm-imx93 not booting even with demo images from NXP I have solved this from support.nxp. In Demo Image Download page, chose version 1.0 insted 4.0, and then using latest uuu to download image to borad Re: frdm-imx93 not booting even with demo images from NXP I'm getting same error and UART DEBUG output this: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok Re: frdm-imx93 not booting even with demo images from NXP Sorry I am late. Yes, that´s probably it. My Uboot version: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) But the link to the right bootload in the post is broken, I can´t download it 😞 Re: frdm-imx93 not booting even with demo images from NXP Link for the bootloader is not working Re: frdm-imx93 not booting even with demo images from NXP Please update the download link for the bootloader. This is still an ongoing issue for many of us and no soultion was found yet.

Parallel RGB LCD interface pins question on RT1064 Hello, Correct me if I am wrong but it seems to me that the RT1064 features 2 LCD interfaces: - one located on the GPIO bus with CLK/HSYNC/VSYNC + up to 24 bits data signals and - another one for 8/16-bit MPU/8080 interface located on the SEMC bus I am using a LCD module having a ILI9341 controller. My plan is to display text and icons, I will not perform video/animation at all. I am not using any external memory on this design, SEMC bus is therefore available. Q1. Which inteface is best for my application ? Q2. On the SEMC bus, where are located the following pins that are needed to interface the ILI9341 in parallel mode : - D/CX - WRX - RDX i.MXRT 106x Re: Parallel RGB LCD interface pins question on RT1064 Hi @batmat, The LCD module that you are referring to as the one based on the GPIO bus is the Enhanced LCD Interface (eLCDIF) module, which is designed specifically for driving displays. The other module would be the Smart External Memory Controller (SEMC) module which can definitely be used to drive certain types of displays, but its design is more specifically for driving of external memories, although most 8080-based displays also fit the SEMC capabilities when this module is combined with the capabilities of the FlexIO pins. The following application describes this functionality: https://mcuxpresso.nxp.com/appcodehub?search=an-flexio_8080_rt1050 From a quick look at the ILI9341 datasheet, I believe this driver supports several types of interfaces, including the RGB interface that is compatible with the eLCDIF module, the 8080 interface which is compatible with the SEMC module, and even 3/4-line SPI interface, that could be implemented using the LPSPI module. That said, the best recommendation would be whatever fits your performance requirements, and available pinouts. With respect to the SEMC signals, the WRX (write signal) and RDX (read signal) are both defined on specific FlexIO pins. In the case of the aforementioned Application Note, these would be FlexIO2_00 and FlexIO2_01 respectively. The D/CX signal is equivalent to the Register Select (RS) signal to determine if the data lines will send data or command information. BR, Edwin.

SVD files for S32K3 - license question I would like to release some software which is derived from the S32K388 and S32K344 SVD files. But the SVD files have the following text: Copyright 2016-2024 NXP NXP Confidential and Proprietary. This software is owned or controlled by NXP and may only be used strictly in accordance with the applicable license terms. By expressly accepting such terms or by downloading, installing, activating and/or otherwise using the software, you are agreeing that you have read, and that you agree to comply with and are bound by, such license terms. If you do not agree to be bound by the applicable license terms, then you may not retain, install, activate or otherwise use the software. Is there some way I can put this code into a public repository? Or will I have to put guidance in the repository telling people to download the S32DS and extract the SVD files themselves? Re: SVD files for S32K3 - license question Thank you for your question. Unfortunately, the S32K3 SVD files (S32K344.svd, S32K388.svd) carry an "NXP Confidential and Proprietary" license that does not permit redistribution or publishing of derived works in a public repository. We recommend the following approach: Do not include the SVD-derived code directly in a public repo, as this would likely violate the license terms. Instead, provide build scripts/tooling in your repository and instruct users to download S32DS themselves and extract the SVD files, then run the code generation step locally. If you need explicit permission to publish derived code publicly, please contact your NXP sales representative to request a formal licensing exception. This is the safest path until NXP clarifies or updates the SVD file licensing terms.

对基于SoM设计的iMX95 PMIC输出存在疑问 我想制作一个基于 iMX95 的定制 PCB，我以 iMX95 SoM 原理图作为参考，引用原理图。 据我了解，PF09 将是主电源管理芯片，它将产生除 SoC 和 ARM 内核电压之外的所有电压，这些内核电压由 pf530x 产生。 我的疑问是： 1.在 PF09 的参考原理图中，LDO3 也构成了 VDD_SoC 电压线，这是为什么呢？ 2. 数据显示它只能提供最高 200mA 的电流，但 SoC 的电流需求远高于此，如果 PF09 和 PF530x 都输出相同的电压，那就相当于电源线短路了，在这种情况下，PF09 的引脚会吸收电流并导致问题吗？ 3. 我是否可以移除 Pf09 低压差线性稳压器\(LDO\) 的电源输出，只使用另一个低压差线性稳压器\(LDO\)，这样可以吗？（请就“我是否应该删除”或“我是否可以删除”给出明确的建议） 下面附上图片供参考。 PF09 输出 PF530x 用于 VDD_SOC 生成

mcxn947 dma传输开启后没有进入回调 #include "fsl_debug_console.h" #include "pin_mux.h" #include "clock_config.h" #include "board.h" #include "app.h" #include "fsl_flexio_spi_edma.h" #include "board.h" //#include "app.h" #include "fsl_debug_console.h" void BOARD_InitHardware(void); #include "fsl_debug_console.h" #include "fsl_flexio.h" #include "fsl_edma.h" #include "fsl_inputmux.h" #include "fsl_common.h" /* 硬件常数定义 */ #define DEMO_FLEXIO_BASE FLEXIO0 #define DEMO_DMA_BASE    DMA0 #define DEMO_DMA_CH      0  /* 使用 DMA 通道 61 */ #define CHANNEL_COUNT    20  /* 20路并行引脚 */ #define BIT_DEPTH        24  /* 24位深度 */ #define SHIFTERS_USED    8   /* 每次 DMA 填充 8 个 Shifter */ /* 数据缓冲区：必须对齐以优化 DMA 性能 */ SDK_ALIGN(uint32_t g_dac_buffer[BIT_DEPTH], 32); edma_handle_t g_edma_handle; volatile bool g_transfer_done = false; /* DMA 完成回调 */ void EDMA_Callback(edma_handle_t *handle, void *param, bool transferDone, uint32_t tcds) {    if (transferDone)    {        /* 确保 FlexIO 最后一组数据已从移位寄存器彻底发出 */        while (!(FLEXIO_GetShifterStatusFlags(DEMO_FLEXIO_BASE) & 0x01U));        /* 立即关闭 DMA 请求，防止产生虚假触发 */        FLEXIO_EnableShifterStatusDMA(DEMO_FLEXIO_BASE, 1 << 0, false);        g_transfer_done = true;    } } void Init_FlexIO_DAC(void) {    flexio_config_t fxioConfig;    flexio_shifter_config_t shConfig = {0};    flexio_timer_config_t timConfig = {0};    FLEXIO_GetDefaultConfig(&fxioConfig);    FLEXIO_Init(DEMO_FLEXIO_BASE, &fxioConfig);    FLEXIO_Reset(DEMO_FLEXIO_BASE);    /* 配置 8 个 Shifter 并行输出 */    for (uint8_t i = 0; i < SHIFTERS_USED; i++)    {        shConfig.timerSelect   = 0;        shConfig.timerPolarity = kFLEXIO_ShifterTimerPolarityOnPositive;        shConfig.pinConfig     = kFLEXIO_PinConfigOutput;        shConfig.pinSelect     = 0;  /* 引脚从 D0 开始 */        shConfig.pinPolarity   = kFLEXIO_PinActiveHigh;        shConfig.shifterMode   = kFLEXIO_ShifterModeTransmit;        shConfig.inputSource   = kFLEXIO_ShifterInputFromPin;        shConfig.shifterStop   = kFLEXIO_ShifterStopBitDisable;        shConfig.shifterStart  = kFLEXIO_ShifterStartBitDisabledLoadDataOnEnable;        shConfig.parallelWidth = CHANNEL_COUNT - 1U; /* 20路并行宽度 */        FLEXIO_SetShifterConfig(DEMO_FLEXIO_BASE, i, &shConfig);    }    /* 配置 Timer 0 作为 SCLK 时钟源 */    timConfig.triggerSelect   = FLEXIO_TIMER_TRIGGER_SEL_SHIFTnSTAT(0);    timConfig.triggerPolarity = kFLEXIO_TimerTriggerPolarityActiveLow;    timConfig.triggerSource   = kFLEXIO_TimerTriggerSourceInternal;    timConfig.pinConfig       = kFLEXIO_PinConfigOutput;    timConfig.pinSelect       = 20; /* 时钟信号输出在 D20 */    timConfig.timerMode       = kFLEXIO_TimerModeDual8BitBaudBit;    timConfig.timerDisable    = kFLEXIO_TimerDisableOnTimerCompare;    timConfig.timerEnable     = kFLEXIO_TimerEnableOnTriggerHigh;    /* 8个位 = 16个边沿 (15), 频率分频 = 10 */    timConfig.timerCompare    = (15U << 8U) | 10U;    FLEXIO_SetTimerConfig(DEMO_FLEXIO_BASE, 0, &timConfig); } void Init_DMA_DAC(void) {    edma_config_t edmaConfig;    /* 修正后的 MCXN947 InputMux 连接 */    /* 如果 kINPUTMUX_Flexio0Shift0ToDma0Ch61Ena 依然报错，       请尝试 kINPUTMUX_Flexio0Request0ToDma0Ch61Ena */    INPUTMUX_Init(INPUTMUX0);    //INPUTMUX_EnableSignal(INPUTMUX0, kINPUTMUX_Flexio0Shift0ToDma0Ch61Ena, true);    INPUTMUX_EnableSignal(INPUTMUX0, kINPUTMUX_FlexIO0ShiftRegister0RequestToDma0Ch61Ena, true);    EDMA_GetDefaultConfig(&edmaConfig);    EDMA_Init(DEMO_DMA_BASE, &edmaConfig);    EDMA_CreateHandle(&g_edma_handle, DEMO_DMA_BASE, DEMO_DMA_CH);    EDMA_SetCallback(&g_edma_handle, EDMA_Callback, NULL); } void DAC_Transmit(void) {    edma_transfer_config_t xferConfig;    edma_minor_offset_config_t offsetConfig;    g_transfer_done = false;    /*       参数修正说明：       1. bytesEachRequest = 32  (每次触发搬运 8 个 Shifter，每个 4 字节)       2. transferBytes = 96     (总共 24 位数据，每位 4 字节，24 * 4 = 96)       这样 96 % 32 == 0，断言即可通过。    */    EDMA_PrepareTransferConfig(&xferConfig,                               (void *)g_dac_buffer,                /* srcAddr */                               4,                                   /* srcWidth: 4字节 */                               4,                                   /* srcOffset: 4 */                               (void *)&(DEMO_FLEXIO_BASE->SHIFTBUF[0]), /* destAddr */                               4,                                   /* destWidth: 4字节 */                               4,                                   /* destOffset: 4 */                               32,                                  /* bytesEachRequest: 32 */                               96                                   /* transferBytes: 96 (！！！修正点) */                               );    /* 提交配置 */    EDMA_SubmitTransfer(&g_edma_handle, &xferConfig);    /* 配置地址回退：Minor Loop 结束后，目的地址减去 32 字节回到 SHIFTBUF[0] */    offsetConfig.enableSrcMinorOffset  = false;    offsetConfig.enableDestMinorOffset = true;    offsetConfig.minorOffset           = -32;    EDMA_SetMinorOffsetConfig(DEMO_DMA_BASE, DEMO_DMA_CH, &offsetConfig);    /* 启动 DMA 和 FlexIO 请求 */    EDMA_StartTransfer(&g_edma_handle);    FLEXIO_EnableShifterStatusDMA(DEMO_FLEXIO_BASE, 1 << 0, true); } int main(void) {    /* 基础硬件初始化 (时钟/引脚) */    BOARD_InitHardware();    Init_FlexIO_DAC();    Init_DMA_DAC();    /* 示例数据填充 */    for(int i=0; i<BIT_DEPTH; i++) g_dac_buffer[i] = 0xAAAAA;    while (1)    {        DAC_Transmit();        /* 等待回调执行 */        while(!g_transfer_done);        /* 间隔 */        SDK_DelayAtLeastUs(1000, SystemCoreClock);    } }     程序卡死在    while(!g_transfer_done);  没有往下走 。 请问哪里出了问题 Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Re: mcxn947 dma传输开启后没有进入回调 The callback was not executed. Which channel should be used for DMA here? Channel 61 won't pass the assertion; it cannot exceed 16. If the DMA channel is set to 0, the DMA callback will not be entered at all. Re: mcxn947 dma传输开启后没有进入回调 Hi @justdomyself 1) Set breakpoints for debugging and check if the eDMA interrupt and callback functions have been entered. 2) Confirm which eDMA channel is being used. #define DEMO_DMA_CH      / * Using DMA channel 61 */ It seems that channel 0 is being used here. INPUTMUX_EnableSignal(INPUTMUX0, kINPUTMUX_FlexIO0ShiftRegister0RequestToDma0Ch61Ena, true); However, judging from the comments and this line of code, it seems to be using Chaanel 61. BR Alice

imx95 + la12xx hi NXP Problem Description: I'm currently using an IMX95 and a LA1234 connected via PCIe. I've compiled the kernel driver for hostsw_la12xx and loaded yami.ko, but I can't detect the LA1234 device using LSPCI. 1. I don't have a program for burning into my LA1234. Do I need to burn the program before I can view it via LSPCI? How do I burn the program? Re: imx95 + la12xx Based on the observed phenomena, the current problem is most likely not caused by the yami.ko compilation or loading process on the host side. lspci The premise for seeing LA1234 is that LA1234 has already started normally as a PCIe Endpoint and the PCIe link has been successfully trained. If no programs have been flashed/booted on the LA1234, it's reasonable that the i.MX95 side cannot see the LA1234 via lspci . The LA1234 needs to boot from a supported boot source to run the LA12xx BSP/FreeRTOS/PCIe EP firmware, completing the PCIe Endpoint initialization, before the i.MX95, as the Root Complex, can enumerate the device. hostsw_la12xx/kernel_driver/yami.ko This is the host Linux-side LA12xx PCIe driver. It typically handles further LA12xx initialization after the PCIe device has been enumerated by the host, such as PCIe inbound/outbound windows, e200 OS boot, VSPA image boot, IPC/RFIC, etc. It cannot allow the device to appear directly in lspci if the PCIe EP is not fully enabled on the LA1234 side. We recommend checking in the following directions first: Verify that the LA1234 boot mode/boot source is correct, and that the LA1234 has started the LA12xx BSP/FreeRTOS image containing the PCIe Endpoint driver. Confirm that the LA1234 PCIe controller is configured as EP, and the i.MX95 side is configured as RC. Check if PCIe REFCLK, PERST#, power sequence, SerDes lane settings, and lane width/speed are matched. The i.MX95 side first executes dmesg | grep -i pcie , echo 1 > /sys/bus/pci/rescan , and lspci -nn -vv to check if there are any endpoint enumerations. If there is still no device, it is recommended to first connect to the i.MX95 with a known working PCIe endpoint to confirm that the i.MX95 RC side hardware and device tree/kernel configuration are correct; then go back to the LA1234 side to check EP boot and hardware connection. To program the LA1234, you need to use the LA1234/LA12xx board boot image and corresponding programming process provided in the LA12xx SDK/BSP. The publicly available hostsw_la12xx repository mainly contains host-side software; the FreeRTOS side code is not in this repository. Therefore, you need to refer to the sections on LA12xx board boot and image programming in the LA12xx SDK User Guide / BSP release package.

LPC54S018をSPI-MRAM（MR25H40）から起動します。 私はLPC54S018を搭載したEVB LPC54S018M-EVKを購入し、それにSPI-MRAMチップ=MR25H40を接続します。 SPI-MRAM（MR25H40）からLPC54S018にファームウェアをロードする必要があります。MRAMをFLEXCOMM9に接続しました。ファームウェアからこのMRAMへのデータの読み書きは正常にできますが、問題ありません。でもMCUを起動できません。 オシログラムでは(RESET後に)マイクロコントローラのブートROMコードがMRAMと通信し始めるのがデフォルト速度=12 MHz(起動ROMがウェイクアップコマンド(opcode = 0xAB)を送信し、その後「read JEDEC-ID」コマンドを3回送信します(opcode = 0x9F))。その後、SPI上ではそれ以上の活動は発生しない。ウェイクアップコマンドはMRAMによって正常に処理されますが、「JEDEC-ID読み取り」コマンドはメモリによってサポートされていません（MRAMのデータシートによる）。私は、ブートROMコードが「JEDEC-IDの読み取り」コマンドに対する応答を受け取らなかったため、デフォルトの速度で起動を続行するだけだと思っていました。しかし、理由は不明だが、「JEDEC-IDの読み取り」を3回試みた後、ブートプロセスがキャンセルされる。 LPC54S018のISPピンを以下の状態に設定してみました。 1) または ISP0 = high、ISP1 = high、ISP2 = high; 2) または ISP0 = high、ISP1 = low、ISP2 = high。 何も変わりません。マイクロコントローラが起動しません。 「read JEDEC-ID」コマンドへの応答を待たずに、SPIメモリからLPC54S018の起動を続行する方法はありますか？ 追伸：負荷処理のオシログラムを添付します。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). LPC540xxをSPI-MRAM（MR20H40/MR25H40）から起動することは不可能であるようです。SPI-MRAMは「read JEDEC-ID」コマンドをサポートしていないためです。 😞😞 しかし、SPI-FRAM(SPI-MARMとは異なり)は「read JEDEC-ID」コマンドをサポートしています。SPI-MRAMをSPI-FRAM（FM25V05）に交換したところ、LPC54S018の起動に成功しました！しかし、FM25V05では、ファームウェアはアドレス0x0000からではなく、0x0001から開始する必要があります。「read JEDEC-ID」コマンドの後、LPC540xxブートROMはまず24ビットアドレスを持つ読み出しコマンド0x03をSPIメモリに送信します。読み取りが失敗した場合は、32ビットのアドレスを持つ読み取りコマンド0x03を送信します。FM25V05は16ビットのアドレスを持ちます。しかし、ブートイメージをアドレス0x0001にシフトすると、LPC540xxはFM25V05からでも正常にブートします。ブートROMでは24ビットの読み取りコマンドが使われるため、最初のバイト読み込みは省略されます。 添付のオシログラムを参照してください。 後で、24ビットアドレス指定が可能なCY15B104QN（SPI-FRAM）からの起動を試してみます。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). こんにちは、 @jcxzさん ボードが正常に起動したと聞いて大変嬉しく思います。 他に何かご質問やご不明な点はありますか？ よろしくお願いします。 BR アリス Re: Boot LPC54S018 from SPI-MRAM (MR25H40). はい。次に、CY15B104QN-50SXI SPI-FRAMからの起動を試みました。機能しません 😞 CY15B104QNからは起動しません。このチップは「JEDEC-ID読み取り」コマンドに応答しますが、しかし、CY15B104QN は逆バイト順の JEDEC-ID を出力します: "00,2C,C2,7F,7F,7F,7F,7F,7F" (16 進数)。おそらくそれが、LPC54018のブートROMがそこから起動しない理由でしょう。 FM25V05は「7F,7F,7F,7F,7F,7F,C2,23,00」(16進数)の形式でJEDEC-IDを出力します。LPC54018ブートROMはこれを受け入れて起動します。しかし、FM25V05の容量は私のプロジェクトには小さすぎます。 それでは、FM25V20Aから起動してみます。そこから起動してくれるといいのですが。 PS: CY15B104QNは、新世代のSPI-FRAMチップである「EXCELON™ F-RAM」（Infineon社製）に属します。どうやらLPC54018ブートローダーはそれらをサポートしていないようです。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). FM25V20A-GからLPC54018を正常に起動できました！ LPC54018のMRAM/FRAMブート機能チェックの最終結果： 1. SPI-MRAM (MR25H40) からのブート:失敗。考えられる原因＝JEDEC-ID読み取りコマンドがサポートされていない。 2. SPI-FRAM CY15B104QN からのブート、JEDEC-ID = "00,2C,C2,7F,7F,7F,7F,7F,7F" (16 進数):失敗。考えられる原因＝ブートROMがJEDEC-IDを認識していない。 3. SPI-FRAM FM25V20A-G からブート中、JEDEC-ID = "7F,7F,7F,7F,7F,7F,C2,25,08" (16 進数):成功。考えられる理由＝ブートROMがJEDEC-IDを認識している。 4. SPI-FRAM FM25V05 からブート、JEDEC-ID = "7F,7F,7F,7F,7F,7F,C2,23,00" (16 進数):成功。考えられる理由：ブートROMがJEDEC-IDを認識している。ただし、ブートイメージはアドレス1（0ではない）に配置する必要があります。 しかし、CY15B104QNのメモリファミリは新しいです。これは旧型のFM25Vxxの後継機種です。したがって、CY15B104QNを使用したいと思います。CY15B104QNからのブートがサポートされていないのはなぜですか？また、FUTUREのLPC540xxのリビジョンでは、CY15B104QN(またはこのファミリの他のチップ)からの起動機能は追加されるのでしょうか?

SoM設計に基づくiMX95 PMIC出力に関する疑問 iMX95をベースにしたカスタムPCBを作成したかったので、iMX95 SoMの回路図をリファレンス回路図として使用しています。 私の理解では、PF09はマスターPMICとなり、SoCとARMコアの電圧を除くすべての電圧を出力します。これらのコア電圧はpf530xによって作られています。 私の疑問点は以下の通りです。 1.参照回路図では、PF09のLDO3がVDD_SoC電圧ラインも構成していますが、これはなぜでしょうか？ 2. そして、最大200mAまでしか供給できないことが示されていますが、SoCの電流要求はそれ以上で、もしPF09とPF530xの両方が同じ電圧を出しているなら、それは電源線をショートさせるようなものです。その場合、PF09のピンが電流を吸収して問題を引き起こすのでしょうか? 3. Pf09 LDOの電源出力を外して、もう一方のLDOを使うべきか、またはCANでしょうか?動作しますか?(「削除すべきか」や「CAN」など、明確な提案をしてください) 参考用の画像を下に添付します PF09の出力 VDD_SOC生成にPF530xを使用

S32K3 的 SVD 文件 - 许可证问题 我想发布一些基于 S32K388 和 S32K344 SVD 文件开发的软件。但SVD文件包含以下文本： 版权所有 2016-2024 NXP NXP 机密专有软件。本软件归 NXP 所有或受其控制。 由恩智浦半导体（NXP）所有，且仅可严格按照适用法律法规使用。 许可条款。通过明确接受这些条款或下载， 安装、激活和/或以其他方式使用该软件，即表示您同意 您同意已阅读并同意遵守本条款。 受此类许可条款的约束。如果您不同意受其约束，则表示您同意接受此类许可条款的约束。 如果违反适用的许可条款，则您不得保留、安装或激活。 或者以其他方式使用该软件。 我能否将这段代码放到一个公共代码库中？或者我需要在代码库中添加说明，告诉用户下载 S32DS 并自行提取 SVD 文件吗？ Re: SVD files for S32K3 - license question 谢谢你的提问。遗憾的是，S32K3 SVD 文件（S32K344.svd，S32K388.svd)带有“NXP 机密和专有”许可，不允许在公共存储库中重新分发或发布衍生作品。 我们建议采用以下方法： 请勿将 SVD 派生代码直接包含在公共仓库中，因为这很可能违反许可条款。 相反，请在您的存储库中提供构建脚本/工具，并指示用户自行下载 S32DS 并提取 SVD 文件，然后在本地运行代码生成步骤。 如果您需要获得明确许可才能公开发布衍生代码，请联系您的 NXP 销售代表，申请正式的许可例外。 在 NXP 澄清或更新 SVD 文件许可条款之前，这是最安全的方法。

Boot LPC54S018 from SPI-MRAM (MR25H40). I am buy EVB LPC54S018M-EVK with LPC54S018 and connect to it SPI-MRAM chip = MR25H40. I need to load the firmware into LPC54S018 from SPI-MRAM (MR25H40). I connected the MRAM to FLEXCOMM9. I can read and write of data to this MRAM from my firmware normally - it ok. But I can't boot of MCU from it. On the oscillogramm, I see that (after RESET) the microcontroller's boot-ROM code begins communicating with the MRAM at the default speed = 12 MHz (boot-ROM sending it a wake-up command (opcode = 0xAB) and then three times sending a "read JEDEC-ID" command (opcode = 0x9F)). After that, no further activity occurs on the SPI. The wake-up command is processed normally by the MRAM, but the "read JEDEC-ID" command is not supported by the memory (according to the datasheet by MRAM). I thought that the boot-ROM code, having not received a response to the "read JEDEC-ID" command, would simply continue booting at the default speed. But for unknown reason, after three attempts to "read JEDEC-ID", the boot process is cancelled. I tried setting the ISP pins of LPC54S018 to the following states: 1) or ISP0 = high, ISP1 = high, ISP2 = high; 2) or ISP0 = high, ISP1 = low, ISP2 = high. Nothing changes - the microcontroller won't boot. Is there any way to continue booting of LPC54S018 from SPI-memory without waiting for a response to the "read JEDEC-ID" command? PS: I am attaching oscillograms of the loading process. Re: Boot LPC54S018 from SPI-MRAM (MR25H40). It appears that booting the LPC540xx from SPI-MRAM (MR20H40/MR25H40) is impossible. Because SPI-MRAM does not support the "read JEDEC-ID" command.  😞😞 But SPI-FRAM (unlike SPI-MRAM) supports the "read JEDEC-ID" command. I replaced SPI-MRAM to SPI-FRAM (FM25V05) and booted my LPC54S018 successfully! However, in the FM25V05, the firmware should start from address 0x0001, not from 0x0000. After the "read JEDEC-ID" command, the LPC540xx boot-ROM sends a read command 0x03 to the SPI memory first, with a 24-bit address. If the reading is unsuccessful, it then sends a read command 0x03 with a 32-bit address. The FM25V05 has a 16-bit address. However, if the boot image is shifted to address 0x0001, the LPC540xx boots successfully even from the FM25V05. 24-bit read commands are used by boot-ROM for booting, so the first byte read is skipped. See attached oscillogram. Later I'll try booting from the CY15B104QN (SPI-FRAM), which has 24-bit addressing. Re: Boot LPC54S018 from SPI-MRAM (MR25H40). Yes. Next, I tried booting from the CY15B104QN-50SXI SPI-FRAM. Its doesn't work 😞 Doesn't boot from the CY15B104QN. Although this chip responds to the "read JEDEC-ID" command. But CY15B104QN outputs a JEDEC-ID in reverse byte order: "00,2C,C2,7F,7F,7F,7F,7F,7F" (hex). That's probably why the boot-ROM LPC54018 refuses to boot from it. The FM25V05 outputs a JEDEC-ID in the form: "7F,7F,7F,7F,7F,7F,C2,23,00" (hex) - the LPC54018 boot-ROM accepts it and boots. But capacity of FM25V05 is too small for the my project. Now I'll try booting from the FM25V20A. I hope it will boot from there. PS: The CY15B104QN belongs to the new generation of SPI-FRAM chips - "EXCELON™" F-RAM" (Infineon). Apparently, the LPC54018 bootloader doesn't support them. Re: Boot LPC54S018 from SPI-MRAM (MR25H40). Hi @jcxz  It is great to hear that your board has booted successfully. Do you have any further questions or concerns? Thank you. BR Alice Re: Boot LPC54S018 from SPI-MRAM (MR25H40). I was able to successfully boot LPC54018 from FM25V20A-G! Final result of the LPC54018 MRAM/FRAM boot capability check: 1. Booting from SPI-MRAM (MR25H40): FAILED. Possible reason = JEDEC-ID read command not supported. 2. Booting from SPI-FRAM CY15B104QN, JEDEC-ID = "00,2C,C2,7F,7F,7F,7F,7F,7F" (hex): FAILED. Possible reason = boot-ROM does not recognize JEDEC-ID. 3. Booting from SPI-FRAM FM25V20A-G, JEDEC-ID = "7F,7F,7F,7F,7F,7F,C2,25,08" (hex): SUCCESSFUL. Possible reason = boot-ROM recognizes JEDEC-ID. 4. Booting from SPI-FRAM FM25V05, JEDEC-ID = "7F,7F,7F,7F,7F,7F,C2,23,00" (hex): SUCCESSFUL. Possible reason: The boot ROM recognizes the JEDEC-ID. However, the boot image must be located at address 1 (not 0). But the CY15B104QN memory family is newer. It replaces the outdated FM25Vxx. Therefore, I'd like to use the CY15B104QN. Why booting from CY15B104QN not supported? And will booting from the CY15B104QN (or other chips in this family) be added in future LPC540xx revisions?

从 SPI-MRAM (MR25H40) 启动 LPC54S018。 我购买了 EVB LPC54S018M-EVK，其中包含 LPC54S018，并将其连接到 SPI-MRAM 芯片 = MR25H40。 我需要将固件从 SPI-MRAM (MR25H40) 加载到 LPC54S018 中。我将 MRAM 连接到了 FLEXCOMM9。我的固件可以正常地对这个 MRAM 进行数据读写操作——没问题。但我无法从中启动MCU。 从示波器上，我看到（RESET后）微控制器的启动 ROM 代码开始以默认速度 = 12 MHz 与 MRAM 通信（启动 ROM 向其发送唤醒命令（操作码 = 0xAB），然后三次发送“读取 JEDEC-ID”命令（操作码 = 0x9F））。此后，SPI 上不再发生任何活动。唤醒命令由 MRAM 正常处理，但存储器不支持“读取 JEDEC-ID”命令（根据 MRAM 的数据手册）。我原以为，由于没有收到“读取 JEDEC-ID”命令的响应，启动 ROM 代码会继续以默认速度启动。但不知何故，在三次尝试“读取 JEDEC-ID”后，启动过程被取消。 我尝试将 LPC54S018 的 ISP 引脚设置为以下状态： 1) 或 ISP0 = 高，ISP1 = 高，ISP2 = 高； 2) 或 ISP0 = 高，ISP1 = 低，ISP2 = 高。 情况依旧没有改变——微控制器无法启动。 是否有办法在不等待“读取 JEDEC-ID”命令的响应的情况下，继续从 SPI 存储器启动 LPC54S018？ PS：我附上了加载过程的示波图。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). 看来无法从 SPI-MRAM (MR20H40/MR25H40) 启动 LPC540xx。因为 SPI-MRAM 不支持“读取 JEDEC-ID”命令。 😞😞 但 SPI-FRAM（与 SPI-MRAM 不同）支持“读取 JEDEC-ID”命令。我已将 SPI-MRAM 更换为 SPI-FRAM (FM25V05)，并成功启动了我的 LPC54S018！但是，在 FM25V05 中，固件应该从地址 0x0001 开始，而不是从 0x0000 开始。在执行“读取 JEDEC-ID”命令后，LPC540xx 启动 ROM 首先向 SPI 存储器发送 READ命令 0x03，地址为 24 位。如果读取失败，则发送带有 32 位地址的 READ命令 0x03。FM25V05 具有 16 位地址。但是，如果将启动映像移至地址 0x0001，即使从 FM25V05 启动，LPC540xx 也能成功启动。启动 ROM 使用 24 位读取命令进行启动，因此会跳过读取的第一个字节。 请参见附图示波图。 稍后我会尝试从 CY15B104QN（SPI-FRAM）启动，它具有 24 位寻址。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). 是的。接下来，我尝试从 CY15B104QN-50SXI SPI-FRAM 启动。它不起作用 😞 无法从 CY15B104QN 启动。虽然该芯片响应“读取 JEDEC-ID”命令。但 CY15B104QN 以相反的字节顺序输出 JEDEC-ID："00,2C,C2,7F,7F,7F,7F,7F,7F"（十六进制）。这大概就是为什么启动 ROM LPC54018 无法从中启动的原因。 FM25V05 输出 JEDEC-ID，格式为："7F,7F,7F,7F,7F,7F,C2,23,00"（十六进制） - LPC54018 启动 ROM 接受它并启动。但是 FM25V05 的容量太小，无法满足我的项目需求。 现在我尝试从 FM25V20A 启动。我希望它能从那里启动。 PS：CY15B104QN 属于新一代 SPI-FRAM 芯片——“EXCELON™”F-RAM（英飞凌）。显然，LPC54018 引导加载程序不支持它们。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). 嗨@jcxz 很高兴听到您的板已成功启动。 您还有其他问题或疑虑吗？ 谢谢！ BR 爱丽丝 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). 我成功地从 FM25V20A-G 启动了 LPC54018！ LPC54018 MRAM/FRAM 启动能力检查的最终结果： 1. 从 SPI-MRAM (MR25H40) 启动：失败。可能原因 = 不支持 JEDEC-ID 读取命令。 2. 从 SPI-FRAM CY15B104QN 启动，JEDEC-ID = "00,2C,C2,7F,7F,7F,7F,7F,7F" (十六进制):失败。可能的原因 = 启动 ROM 无法识别 JEDEC-ID。 3. 从 SPI-FRAM FM25V20A-G 启动，JEDEC-ID = "7F,7F,7F,7F,7F,7F,C2,25,08" (十六进制):成功。可能的原因 = 启动 ROM 识别 JEDEC-ID。 4. 从 SPI-FRAM FM25V05 启动，JEDEC-ID = "7F,7F,7F,7F,7F,7F,C2,23,00" (十六进制):成功。可能的原因：启动 ROM 识别了 JEDEC-ID。但是，启动映像必须位于地址 1（而不是 0）。 但CY15B104QN系列内存是较新的产品。它取代了过时的FM25Vxx。因此，我想使用 CY15B104QN。为什么不支持从 CY15B104QN 启动？未来 LPC540xx 版本是否会增加从 CY15B104QN（或该系列的其他芯片）启动的功能？

mcxn947 dma传输开启後没进入回调 #include "fsl_debug_console.h" #include "pin_mux.h" #include "clock_config.h" #include "board.h" #include "app.h" #include "fsl_flexio_spi_edma.h" #include "board.h" //#include "app.h" #include "fsl_debug_console.h" void BOARD_InitHardware ( void ); #include "fsl_debug_console.h" #include "fsl_flexio.h" #include "fsl_edma.h" #include "fsl_inputmux.h" #include "fsl_common.h" /* ハードウェア常数定义 */ #define DEMO_FLEXIO_BASE FLEXIO0 #define DEMO_DMA_BASE DMA0 #define DEMO_DMA_CH      0 /* DMA チャネル 61 を使用 */ #define CHANNEL_COUNT    20 /* 20路并行引 */ #define BIT_DEPTH        24 /* 24位深度 */ #define SHIFTERS_USED    8 /* 次回 DMA 充填 8 个 シフター */ /* データ缓冲区：DMA パフォーマンスを強化する必要があります */ SDK_ALIGN ( uint32_t g_dac_buffer [ BIT_DEPTH ], 32 ); edma_handle_t g_edma_handle ; volatile bool g_transfer_done = false ; /* DMA 完了回调 */ void EDMA_Callback ( edma_handle_t * handle , void * param , bool transferDone , uint32_t tcds ) {    if ( transferDone )     {        /* FlexIO の最後の一組のデータを確保します */        while ( ! ( FLEXIO_GetShifterStatusFlags ( DEMO_FLEXIO_BASE ) & 0x01U ));        /* 立即关闭 DMA 请要求、生成仮想假触発を防止 */        FLEXIO_EnableShifterStatusDMA ( DEMO_FLEXIO_BASE , 1 << 0 , false );        g_transfer_done = true ;    } } void Init_FlexIO_DAC ( void ) {    flexio_config_t fxioConfig ;    flexio_shifter_config_t shConfig = { 0 };    flexio_timer_config_t timConfig = { 0 };    FLEXIO_GetDefaultConfig ( & fxioConfig );    FLEXIO_Init ( DEMO_FLEXIO_BASE 、 & fxioConfig );    FLEXIO_Reset ( DEMO_FLEXIO_BASE );    /* 配置 8 个 Shifter 并行出力 */    for ( uint8_t i = 0 ; i < SHIFTERS_USED ; i ++ )     {        shConfig.timerSelect​​   = 0 ;        shConfig.timerPolarity = kFLEXIO_ShifterTimerPolarityOnPositive ;​​        shConfig . pinConfig     = kFLEXIO_PinConfigOutput ;        shConfig.pinSelect​​     = 0 ; /* 引脚から D0 開始 */        shConfig . pinPolarity   = kFLEXIO_PinActiveHigh ;        shConfig.shifterMode​​   = kFLEXIO_ShifterModeTransmit ;        shConfig.inputSource​​   = kFLEXIO_ShifterInputFromPin ;        shConfig . shifterStop   = kFLEXIO_ShifterStopBitDisable ;        shConfig . shifterStart  = kFLEXIO_ShifterStartBitDisabledLoadDataOnEnable ;        shConfig 。平行幅= CHANNEL_COUNT - 1U ; /* 20路并行宽度 */        FLEXIO_SetShifterConfig ( DEMO_FLEXIO_BASE , i , & shConfig );    }    /* タイマー 0 を SCLK 時間源として設定 */    timConfig.triggerSelect​​   = FLEXIO_TIMER_TRIGGER_SEL_SHIFTnSTAT ( 0 );    timConfig.triggerPolarity​​= kFLEXIO_TimerTriggerPolarityActiveLow ;    timConfig.triggerSource​​   = kFLEXIO_TimerTriggerSourceInternal ;    timConfig . pinConfig       = kFLEXIO_PinConfigOutput ;    timConfig.pinSelect​​       = 20 ; /* 時刻信号出力 D20 */    timConfig.timerMode​​       = kFLEXIO_TimerModeDual8BitBaudBit ;    timConfig.timerDisable​​    = kFLEXIO_TimerDisableOnTimerCompare ;    timConfig.timerEnable​​     = kFLEXIO_TimerEnableOnTriggerHigh ;    /* 8 位 = 16 边沿線 (15)、周波数分周波数 = 10 */    timConfig.timerCompare​​    = ( 15U << 8U ) | 10U ;    FLEXIO_SetTimerConfig ( DEMO_FLEXIO_BASE , 0 , & timConfig ); } void Init_DMA_DAC ( void ) {    edma_config_t edmaConfig ;    /* 修正後の MCXN947 InputMux 接続 */    /* 結果 kINPUTMUX_Flexio0Shift0ToDma0Ch61Ena 依然报错，       kINPUTMUX_Flexio0Request0ToDma0Ch61Ena */    INPUTMUX_Init (INPUTMUX0);    //INPUTMUX_EnableSignal(INPUTMUX0, kINPUTMUX_Flexio0Shift0ToDma0Ch61Ena, true);    INPUTMUX_EnableSignal (INPUTMUX0, kINPUTMUX_FlexIO0ShiftRegister0RequestToDma0Ch61Ena , true );    EDMA_GetDefaultConfig ( & edmaConfig );    EDMA_Init ( DEMO_DMA_BASE , & edmaConfig );    EDMA_CreateHandle ( & g_edma_handle , DEMO_DMA_BASE , DEMO_DMA_CH );    EDMA_SetCallback ( & g_edma_handle , EDMA_Callback , NULL ); } void DAC_Transmit ( void ) {    edma_transfer_config_t xferConfig ;    edma_minor_offset_config_t offsetConfig ;    g_transfer_done = false ;    /*       パラメータ修正説明： 1.bytesEachRequest = 32 (每次触発行搬运 8 个 Shifter、每个 4 字节) 2.transferBytes = 96 (总共 24 位データ、每位 4 字节、24 * 4 = 96)       このように 96 % 32 == 0、承認すれば通過できます。    */    EDMA_PrepareTransferConfig ( & xferConfig 、 ( void * )g_dac_buffer, /* srcAddr */                               4 , /* srcWidth: 4文字节 */                               4 、 /* srcOffset: 4 */ ( void * ) & ( DEMO_FLEXIO_BASE -> SHIFTBUF [ 0 ]), /* destAddr */                               4 , /* destWidth: 4文字节 */                               4 、 /* destOffset: 4 */                               32 、 /* bytesEachRequest: 32 */                               96 /* transferBytes: 96 (！！修正点) */                               );    /* 提交配置 */    EDMA_SubmitTransfer ( & g_edma_handle , & xferConfig );    /* 配置地址回帰：マイナーループ終了後、目的地址减去 32 字节回帰 SHIFTBUF[0] */    offsetConfig.enableSrcMinorOffset​​  = false ;    offsetConfig.enableDestMinorOffset = true ;​​    offsetConfig.minorOffset​​           = -32 ;​    EDMA_SetMinorOffsetConfig ( DEMO_DMA_BASE , DEMO_DMA_CH , & offsetConfig );    /* DMA と FlexIO の要求 */    EDMA_StartTransfer ( & g_edma_handle );    FLEXIO_EnableShifterStatusDMA ( DEMO_FLEXIO_BASE , 1 << 0 , true ); } int main ( void ) {    /* 基础ハードウェア初期化 (時間钟/引脚) */    BOARD_InitHardware ();    Init_FlexIO_DAC ();    Init_DMA_DAC ();    /* 例データ充填 */    for ( int i = 0 ; i < BIT_DEPTH ; i ++ ) g_dac_buffer [ i ] = 0xAAAAA ;    （ １ ）​     {        DAC_Transmit ();        /* 等待ち回调执行 */        while ( ! g_transfer_done );        /* 間隔 */        SDK_DelayAtLeastUs ( 1000 、 SystemCoreClock);    } }     程序卡死在 while(!g_transfer_done); 問題はここにあります 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) Re: mcxn947 dma传输开启后没有进入回调 コールバックは実行されませんでした。 ここではどのチャネルをDMAに使用すべきでしょうか？チャネル61ではアサーションが満たされません。チャネル61は16を超えることはできません。 DMAチャネルが0に設定されている場合、DMAコールバックは一切実行されません。 Re: mcxn947 dma传输开启后没有进入回调 こんにちは、 @justdomyself 1) デバッグ用のブレークポイントを設定し、eDMA割り込み関数とコールバック関数が実行されているかどうかを確認します。 2) 使用されているeDMAチャネルを確認してください。 ＃定義する DEMO_DMA_CH      / * DMAチャネル61を使用 */ ここではチャネル0が使用されているようです。 INPUTMUX_EnableSignal(INPUTMUX0, kINPUTMUX_FlexIO0ShiftRegister0RequestToDma0Ch61Ena, true); ただし、コメントとこのコード行から判断すると、チャネル61を使用しているようです。 BR アリス

Doubt regarding iMX95 PMIC output based on SoM design i wanted to make a custom pcb based on iMX95 and i am using the iMX95 SoM schematic as the reference schematic. As per what i understood, the PF09 will be the master pmic and will be making all the voltages except the soc and arm core voltages, these core voltages are made by pf530x. My doubts are: 1.  In the ref schematic LDO3 of PF09 is also making the VDD_SoC voltage line, why is it done? 2. And it is shown it can only source upto 200mA, but SoC current requirement is more than that, and if we both PF09 and PF530x is making the same voltages then it is like shorting the power lines, in such case will the pin at PF09 sink the current and then cause issues? 3. Should I/Can I remove the  power output from Pf09 LDO and just use the other one, will it work? (give a clear suggestion, regarding "should i remove" or "can i remove") images are attached below for reference PF09 outputs PF530x used for VDD_SOC generation

mcxn947 dma传输开启后没有进入回调 #include "fsl_debug_console.h" #include "pin_mux.h" #include "clock_config.h" #include "板.h" #include "app.h" #include “fsl_flexio_spi_edma.h” #include "板.h" //#include "app.h" #include "fsl_debug_console.h" void BOARD_InitHardware ( void ); #include "fsl_debug_console.h" #include "fsl_flexio.h" #include "fsl_edma.h" #include "fsl_inputmux.h" #include "fsl_common.h" /* 硬件硬件定义 */ #define DEMO_FLEXIO_BASE FLEXIO0 #define DEMO_DMA_BASE DMA0 #define DEMO_DMA_CH      0 /* 使用 DMA 通道 61 */ #定义CHANNEL_COUNT    20 /* 20路主板引脚 */ #define位深度        24 /* 24位深度 */ #define SHIFTERS_USED    8 /* 补充 DMA 填充 8 个 Shifter */ /* 数据像素：必须对齐以优化 DMA 性能 */ SDK_ALIGN ( uint32_t g_dac_buffer [ BIT_DEPTH ], 32 ); edma_handle_t g_edma_handle ; volatile bool g_transfer_done = false ; /* DMA完成回调 */ void EDMA_Callback ( edma_handle_t * handle , void * param , bool transferDone , uint32_t tcds ) {    如果（转移完成）     {        /* 确定 FlexIO 最后一组数据已从升降机旋转释放 */        while ( ! ( FLEXIO_GetShifterStatusFlags ( DEMO_FLEXIO_BASE ) & 0x01U ));        /* 立即关闭 DMA 请求，防止产生转向触发 */        FLEXIO_EnableShifterStatusDMA ( DEMO_FLEXIO_BASE , 1 << 0 , false );        g_transfer_done = true ;    } } void Init_FlexIO_DAC ( void ) {    flexio_config_t fxioConfig ；    flexio_shifter_config_t shConfig = { 0 };    flexio_timer_config_t timConfig = { 0 };    FLEXIO_GetDefaultConfig （ & fxioConfig ）；    FLEXIO_Init （ DEMO_FLEXIO_BASE ， & fxioConfig ）；    FLEXIO_重置（ DEMO_FLEXIO_BASE ）；    /* 配置8个Shifter输出 */    for ( uint8_t i = 0 ; i < SHIFTERS_USED ; i ++ )     {        shConfig.timerSelect​​   = 0 ；        shConfig.timerPolarity = kFLEXIO_ShifterTimerPolarityOnPositive ;​​        shConfig.pinConfig​​     = kFLEXIO_PinConfigOutput ；        shConfig.pinSelect​​     = 0 ; /* 引脚从D0开始 */        shConfig.pinPolarity​​   = kFLEXIO_PinActiveHigh ；        shConfig.shifterMode​​   = kFLEXIO_ShifterModeTransmit ；        shConfig.inputSource​​   = kFLEXIO_ShifterInputFromPin ；        shConfig.shifterStop​​   = kFLEXIO_ShifterStopBitDisable ；        shConfig.shifterStart​​  = kFLEXIO_ShifterStartBitDisabledLoadDataOnEnable ;        shConfig 。并行宽度= CHANNEL_COUNT - 1U ； /* 20路宽度 */        FLEXIO_SetShifterConfig ( DEMO_FLEXIO_BASE , i , & shConfig );    }    /* 配置定时器 0 作为 SCLK 时钟源 */    timConfig.triggerSelect​​   = FLEXIO_TIMER_TRIGGER_SEL_SHIFTnSTAT ( 0 );    timConfig.triggerPolarity​​= kFLEXIO_TimerTriggerPolarityActiveLow ；    timConfig.triggerSource​​   = kFLEXIO_TimerTriggerSourceInternal ；    timConfig.pinConfig​​       = kFLEXIO_PinConfigOutput ；    timConfig.pinSelect​​       = 20 ； /*时钟信号在D20输出*/    timConfig.timerMode​​       = kFLEXIO_TimerModeDual8BitBaudBit ；    timConfig.timerDisable​​    = kFLEXIO_TimerDisableOnTimerCompare ;    timConfig.timerEnable​​     = kFLEXIO_TimerEnableOnTriggerHigh ；    /* 8个位 = 16个边沿 (15), 频率频分 = 10 */    timConfig.timerCompare​​    = ( 15U << 8U ) | 10U ;    FLEXIO_SetTimerConfig ( DEMO_FLEXIO_BASE , 0 , & timConfig ); } void Init_DMA_DAC ( void ) {    edma_config_t edmaConfig ；    /* 修改后面的MCXN947 InputMux连接 */    /* 如果 kINPUTMUX_Flexio0Shift0ToDma0Ch61Ena 仍然报错，       请尝试 kINPUTMUX_Flexio0Request0ToDma0Ch61Ena */    输入/输入混合器初始化（输入/输入混合器0）；    //INPUTMUX_EnableSignal(INPUTMUX0, kINPUTMUX_Flexio0Shift0ToDma0Ch61Ena, true);    INPUTMUX_EnableSignal (INPUTMUX0, kINPUTMUX_FlexIO0ShiftRegister0RequestToDma0Ch61Ena , true );    EDMA_GetDefaultConfig ( & edmaConfig );    EDMA_Init ( DEMO_DMA_BASE , & edmaConfig );    EDMA_CreateHandle ( & g_edma_handle , DEMO_DMA_BASE , DEMO_DMA_CH );    EDMA_SetCallback ( & g_edma_handle , EDMA_Callback , NULL ); } void DAC_Transmit ( void ) {    edma_transfer_config_t xferConfig ；    edma_minor_offset_config_t offsetConfig ；    g_transfer_done = false ;    /*       参数修改说明： 1.bytesEachRequest = 32  (每次触发搬运 8 个 Shifter，每 4 字节) 2.传输字节数 = 96     (总共 24 位数据，传输 4 字节，24 * 4 = 96)       这样 96 % 32 == 0，断言即可通过。 */    EDMA_PrepareTransferConfig （ & xferConfig ， ( void * )g_dac_buffer, /* srcAddr */                               4 , /* srcWidth: 4字节 */                               4 ， /* srcOffset: 4 */ ( void * ) & ( DEMO_FLEXIO_BASE -> SHIFTBUF [ 0 ]), /* destAddr */                               4 , /* 目标宽度: 4字节 */                               4 ， /* destOffset: 4 */                               32 ， /* bytesEachRequest: 32 */                               96 /* 传输字节数: 96 (！！！修改点) */                               );    /* 提交配置 */    EDMA_SubmitTransfer ( & g_edma_handle , & xferConfig );    /* 配置地址回退：小循环结束后，目的地址减少 32 字节返回 SHIFTBUF[0] */    offsetConfig.enableSrcMinorOffset​​  = false ；    offsetConfig.enableDestMinorOffset = true ;​​    offsetConfig.minorOffset​​           = -32 ；​    EDMA_SetMinorOffsetConfig ( DEMO_DMA_BASE , DEMO_DMA_CH , & offsetConfig );    /* 启动 DMA 和 FlexIO 请求 */    EDMA_StartTransfer ( & g_edma_handle );    FLEXIO_EnableShifterStatusDMA ( DEMO_FLEXIO_BASE , 1 << 0 , true ); } int main ( void ) {    /* 基础硬件初始化（时钟/引脚） */    BOARD_InitHardware ();    初始化 FlexIO_DAC ();    初始化 DMA_DAC ();    /* 示例数据填充 */    for ( int i = 0 ; i < BIT_DEPTH ; i ++ ) g_dac_buffer [ i ] = 0xAAAAA ;    当（ 1 ）     {        DAC_Transmit ();        /* 等待回调执行 */        while ( ! g_transfer_done );        /* 间隔 */        SDK_DelayAtLeastUs （ 1000 ，系统核心时钟）；    } }     程序卡死在 while(!g_transfer_done); 没有往下走。询问哪里生长问题 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） Re: mcxn947 dma传输开启后没有进入回调 callback  回调没有进 。  这里dma应该用哪个通道？  通道61，断言的时候就过不去，不能超过16. dma通道设0 ，dma回调直接进不去。 Re: mcxn947 dma传输开启后没有进入回调 Hi @justdomyself  1）打断点调试，查看是否进入了eDMA 中断和callback函数。 2）确认具体使用的哪个eDMA channel.  #define DEMO_DMA_CH      0  /* 使用 DMA 通道 61 */ 这里貌似使用的是channel 0.   INPUTMUX_EnableSignal(INPUTMUX0, kINPUTMUX_FlexIO0ShiftRegister0RequestToDma0Ch61Ena, true);   但从备注和这行代码看似乎又使用的Chaanel 61. BR Alice

imx95 + la12xx hi NXP       问题描述：我现在使用imx95加la1234，之间通过pcie连接，我现在将hostsw_la12xx的kernel_driver编译，并且加载了yami.ko，让后通过lspci没有查看到la1234这个设备      1.我现在la1234中没有烧写程序，需要烧写程序以后imx95才可以通过lspci查看吗，如何烧写呢 Re: imx95 + la12xx 从现象看，当前问题大概率不是 host 侧 yami.ko 编译或加载本身导致的。 lspci 能看到 LA1234 的前提是 LA1234 已经作为 PCIe Endpoint 正常启动，并且 PCIe link 已经训练成功。 如果 LA1234 端目前没有烧写/启动任何程序，那么 i.MX95 侧通过 lspci 看不到 LA1234 是合理的。需要先让 LA1234 从支持的 boot source 启动 LA12xx 端 BSP/FreeRTOS/PCIe EP firmware，使其完成 PCIe Endpoint 初始化后，i.MX95 作为 Root Complex 才能枚举到该设备。 hostsw_la12xx/kernel_driver/yami.ko 是 host Linux 侧 LA12xx PCIe driver。它通常是在 PCIe 设备已经能被 host 枚举后，再负责 LA12xx 进一步初始化，例如 PCIe inbound/outbound window、e200 OS boot、VSPA image boot、IPC/RFIC 等。它不能在 LA1234 端完全未启动 PCIe EP 的情况下，让设备直接出现在 lspci 中。 建议先按以下方向检查： 确认 LA1234 boot mode/boot source 是否正确，LA1234 端是否已启动包含 PCIe Endpoint driver 的 LA12xx BSP/FreeRTOS image。 确认 LA1234 PCIe controller 配置为 EP，i.MX95 侧配置为 RC。 检查 PCIe REFCLK、PERST#、power sequence、SerDes lane 设置、lane width/speed 是否匹配。 i.MX95 侧先执行 dmesg | grep -i pcie 、 echo 1 > /sys/bus/pci/rescan 、 lspci -nn -vv ，确认是否有任何 endpoint 枚举。 若仍无设备，建议先用一个已知可工作的 PCIe endpoint 接到 i.MX95，确认 i.MX95 RC 侧硬件和 device tree/kernel 配置没有问题；然后再回到 LA1234 侧检查 EP boot 和硬件连接。 关于如何烧写 LA1234，需要使用 LA12xx SDK/BSP 中提供的 LA1234/LA12xx 端 boot image 和对应烧写流程。公开的 hostsw_la12xx 仓库主要是 host 侧软件，FreeRTOS 端代码不在该仓库中，因此需要参考 LA12xx SDK User Guide / BSP release package 中关于 LA12xx board boot 和 image programming 的章节。

S32K3用SVDファイル - ライセンスに関する質問 S32K388とS32K344 SVDファイルから派生したソフトウェアをリリースしたいと考えています。しかし、SVDファイルには以下のテキストが含まれています。 著作権 2016-2024 NXP NXP機密かつ独自的な情報。このソフトウェアは所有または管理されています NXPによるものであり、適用される規定に厳密に従ってのみ使用可能です ライセンス条件。明示的にそのような条件を受け入れるか、ダウンロードすることで、 インストール、アクティベート、またはその他の方法でソフトウェアを使用することで、あなたは あなたが読んだこと、そして従うことに同意すること、そして そのようなライセンス条件に縛られています。もしあなたが 適用されるライセンス条件がある場合、保持、インストール、アクティベートができません または、ソフトウェアを使ったほうがいいです。 このコードを公開リポジトリに入れることはCANですか?それとも、リポジトリにS32DSをダウンロードしてSVDファイルを自分で抽出するように指示するガイドを記載する必要があるのでしょうか？ Re: SVD files for S32K3 - license question ご質問ありがとうございます。残念ながら、S32K3 SVD ファイル (S32K344.svd、S32K388.svd)本ソフトウェアには「NXP機密および専有」ライセンスが付与されており、派生作品の再配布や公開リポジトリへの掲載は許可されていません。 以下の方法をお勧めします。 SVDから得られたコードを公開リポジトリに直接含めないでください。ライセンス条項に違反する可能性が高いです。 代わりに、リポジトリにビルドスクリプトやツールを提供し、ユーザーにS32DSを自分でダウンロードしてSVDファイルを抽出し、ローカルでコード生成ステップを実行するよう指示してください。 派生コードを公開するために明示的な許可が必要な場合は、NXPの営業担当者にお問い合わせの上、正式なライセンス例外を申請してください。 NXPがSVDファイルのライセンス条項を明確化または更新するまでは、これが最も安全な方法です。