S32K3x4EVB-T172 PIL 通信错误/超时，MBDT S32K3xx 1.4.0 你好， 我尝试在 MATLAB 2023a 上运行 PIL S32CT 示例和 MBDT S32K3xx (v1.4.0)。我的配置包括通过板载 OpenSDA 端口连接的 S32K3x4EVB-T172。 尝试 1（OpenSDA COM）： 我可以成功刷写生成的目标模型，但是 PIL 执行立即失败，并出现以下错误： “无法打开通信通道”（请参见附件中的错误信息截图） 尝试 2（外置 USB 转串口转换器） 我保持 OpenSDA 端口连接以进行刷写，但将外部 USB2Sireal 连接器连接到 J44（1 到 TX，2 到 RX）以进行 PIL 通信，并在硬件设置中更新了 COM 端口。模型刷写成功，但执行超时并出现以下错误： 错误：从 rtiostream 接口接收数据的超时时间已超过 10 秒。通信失败可能由多种原因造成。 你应该： （a）检查目标硬件配置是否正确，例如，检查字节顺序是否正确。 （b）确认目标应用程序正在目标硬件上运行。 （c）考虑应用程序运行时故障的可能性（例如除以零异常、不正确的自定义代码集成等）。 注（c）：要确定运行时失败的可能原因，请考虑使用 SIL，它支持信号处理程序和调试。 如果找不到解决方案，请考虑使用 rtw.connectivity.RtIOStreamHostCommunicator 的 setTimeoutRecvSecs 方法来增加超时值。 问题： 1.S32K3x4EVB-T172开发板运行PIL时是否需要外接USB转串口转换器，还是可以通过板载OpenSDA端口运行PIL？ 2. 如果需要外部 USB 转串口转换器，所需的硬件 UART 配置具体是什么？ 3. 我是否遗漏了什么配置？ 非常感谢您的指导！ Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @PruthviB ， 在进一步调查之前，能否请您说明一下您使用MBDT S32K3xx v1.4.0 的原因？最新版本为v1.8.0 ，其中包含多项修复和改进。我们建议您先升级到 v1.8.0 版本，然后检查问题是否仍然存在。 关于您的设置， S32K3X4EVB-T172上的PIL 通信不需要外部 USB 转串口转换器。板载OpenSDA 接口已经提供了对用于主机-目标通信的目标 UART 的访问，因此同一个 USB 连接可以用于编程和 PIL 通信。 由于 OpenSDA 可以直接访问 UART 引脚，因此通常不需要连接额外的 USB 转串口适配器，如果多个串口处于活动状态，甚至可能会引入配置冲突。 请您尝试一下以下示例： MBDT S32K3xx v1.8.0 仅板载OpenSDA USB 连接 在硬件设置中选择的 OpenSDA 公开的 COM 端口 此致， 德拉戈斯 Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @dragostoma 感谢您对OpenSDA板载接口的指导。 关于版本，MBDT v1.4.0 是推荐用于电池管理系统的 MBDT 版本。请问能否提供在v1.4.0版本中运行PIL仿真的指导？ 顺祝商祺！ 普鲁特维 Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @PruthviB ， 没错，你说得对。The 电池管理系统 Toolbox requires S32K3 Toolbox version 1.4.0. 由于最初的讨论没有提到电池管理系统 工具箱，我假设这个问题与使用过时的 S32K3 工具箱版本有关。 关于 1.4.0 版本中的PIL 模拟，工作流程保持不变。工具箱提供的示例模型配置为使用LPUART 实例，其 RX 和 TX 信号通过 OpenSDA 接口路由。如果您打算使用专用的USB 转串口转换器，则需要配置不同的 LPUART 实例，并将转换器连接的相应 RX 和 TX 引脚分配给该实例。 总结起来： 使用 OpenSDA 接口：工具箱中包含的示例模型无需任何额外修改即可工作。所需的 LPUART 实例和相关的 RX/TX 引脚已配置完毕。 使用专用 USB 转串口转换器：转换器必须连接到目标设备上的特定 RX 和 TX 引脚。因此，必须配置这些引脚并将其映射到可用的 LPUART 实例，这需要对项目配置进行相应的更新。 使用 USB2Serial 变流器时，请确保使用正确的 COM 端口，并配置 J44 的 RX 和 TX 引脚。 与我们联系， 德拉戈斯

[SPSDK][i.MX95] nxpele read-common-fuse fails Hi, I'm working on enabling secure boot on an IMX95 19x19 EVK board. I've successfully signed my images using the SPSDK. Now, before writing the fuses, i wanted to read them using `nxpele` but i'm getting the error below. ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-fuse --index 136 SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 See debug log file: /home/user/.local/state/spsdk/3.11.0/log/debug.log for more info ``` and in the logs it says the following: ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"Message SIZE in response is invalid: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 DEBUG:spsdk:*************************************************** (206ms since start, spsdk_logger.py:212) DEBUG:spsdk:* SPSDK DEBUG LOGGING STARTED 2026-09-03 15:58:44 * (207ms since start, spsdk_logger.py:213) DEBUG:spsdk:* SPSDK version: 3.11.0 * (207ms since start, spsdk_logger.py:215) DEBUG:spsdk:* Python version: 3.14.4 * (207ms since start, spsdk_logger.py:216) DEBUG:spsdk:* OS version: Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * (208ms since start, spsdk_logger.py:217) DEBUG:spsdk:* Last command: ['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-fuse', '--index', '136'] * (208ms since start, spsdk_logger.py:218) DEBUG:spsdk:*************************************************** (208ms since start, spsdk_logger.py:219) TRACE:spsdk.uboot.uboot:Uboot WRITE -> invalid (210ms since start, __init__.py:50) DEBUG:spsdk.uboot.uboot:Uboot READ UNTIL <- => (210ms since start, uboot.py:271) DEBUG:spsdk.uboot.uboot:Checking if the serial console is open by sending invalid command: "invalid\r\nUnknown command 'invalid' - try 'help'\r\nu-boot=> " (224ms since start, uboot.py:209) DEBUG:spsdk.utils.database:Current database finger print hash: f0f0598d4e6ae6c755d693693f232e30537cfb3b (226ms since start, database.py:1967) DEBUG:spsdk.utils.database:Loaded database from cache: /tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache (226ms since start, database.py:1976) DEBUG:spsdk.utils.misc:Loading text file from /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml (226ms since start, misc.py:312) INFO:spsdk.ele.ele_comm:ELE communicator is using 196608 B size buffer at 92800000 address in mimx9596, Revision: latest target. DEBUG:spsdk.ele.ele_comm:ELE msg 0x92800000 0x30000 0602971788000000 (245ms since start, ele_comm.py:502) TRACE:spsdk.uboot.uboot:Uboot WRITE -> ele_message 0x92800000 0x30000 0602971788000000 (246ms since start, __init__.py:50) DEBUG:spsdk.uboot.uboot:Uboot READ UNTIL <- => (246ms since start, uboot.py:271) DEBUG:spsdk.ele.ele_comm:Raw ELE message output: ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (256ms since start, ele_comm.py:422) DEBUG:spsdk.ele.ele_comm:Stripped output: 060497e1d600000000000000 (256ms since start, ele_comm.py:460) DEBUG:spsdk.apps.utils.utils:SPSDK: Message SIZE in response is invalid: 0x4 (257ms since start, utils.py:182) Traceback (most recent call last): File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py", line 172, in wrapper retval = function(*args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 2189, in safe_main sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1631, in __call__ return self.main(*args, **kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1552, in main rv = self.invoke(ctx) File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 2032, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1415, in invoke return ctx.invoke(self.callback, **ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 910, in invoke return callback(*args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py", line 46, in new_func return f(get_current_context().obj, *args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 575, in cmd_read_common_fuse ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 588, in ele_read_common_fuse ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py", line 519, in send_message msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py", line 1235, in decode_response super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py", line 346, in decode_response raise SPSDKParsingError(f"Message SIZE in response is invalid: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 ``` Note: i'm using `SPSDK 3.11.0` I've created an issue also on SPSDK's github page https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614  Any help is very much appreciated.  Thank you, BR, Re: [SPSDK][i.MX95] nxpele read-common-fuse fails Hi joanxie I'm using linux BSP version LF6.18.20_2.0.0 (yocto wrynose) And here is the output of nxpele get-info $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails could you tell me what ele fw version do you use for this command? let me double check it Re: [SPSDK][i.MX95] nxpele read-common-fuse fails I reproduced this issue, and I checked internal data base, this is existed issue and will fixe on spsdk 3.12.0 

i.MX8M PlusおよびTIM-VX/VSINPU上のGC7000UL汎用演算推論パスはNPU専用であるように見える 理事会/BSP: i.MX8M Plus、aarch64 Galcore バージョン 6.4.11.p2.745085 VSINPUExecutionProviderを用いたONNXランタイム(libtim-vx.so に対して静的リンク) Vivante OpenCL ICDの存在と機能(Vivante.icd → libVivanteOpenCL.so) 目標: GC7000UL 3D GPUコア上でResNet50推論ベンチマーク(MLPerfロードゲンハーネス)を実行し、既存のNPU(VIP8000Nano)やCPUベンチマークの結果と比較します。 動作確認済みの項目： Vivante OpenCL ICDを経由したclGetPlatformIDs/clGetDeviceIDsは、1つのプラットフォーム上で2つの独立したデバイスをきれいに列挙します。 デバイス0：GC7000UL.6204.0000 デバイス1：VIP8000Nano-S+I.8002.0000 両者とも、CL_DEVICE_TYPE_ACCELERATORを報告し、エラーはなく、libOpenCL.so → libGAL.so と連携した最小限のCテストプログラムで確認されました。 ORT経由でGPUディスパッチを妨げている原因: ort.get_available_providers()は['VSINPUExecutionProvider', 'CPUExecutionProvider']のみを返します — OpenCLベースのEPはありません。 VSINPUExecutionProviderは静的にリンク libtim-vx.so(OVXLIB/vsi_nn_* API)です。libtim-vx.so と libGAL.so の両方のシンボル/文字列ダンプでは、DEVICE_INDEX/DEVICE_IDスタイルのenv varやconfig surfaceは表示されず、動作の切り替え(VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_*など)のみが表示されます。 libGAL.so 生のHALレイヤーでgcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndexをエクスポートしますが、OVXLIB/TIM-VXからその呼び出しまでの配管は見当たりません。これは、VSINPUが使うグラフコンパイラがデバイスインデックスに関係なくNPUコアのみをターゲットにしている可能性を示唆しています。 具体的な質問： このBSP(galcore 6.4.11.p2)上のTIM-VX / OVXLIBは、グラフをコンパイルして一般的な計算対象としてGC7000ULにディスパッチするのをサポートしているのでしょうか?それともこのビルドではグラフコンパイラは設計上NPUのみ対応されているのでしょうか?また、その方法で実行可能かどうかはどうやって確認すればよいのでしょうか? もしTIM-VXの上流でGPUターゲットグラフコンパイルがサポートされているのに、このNXP搭載ビルドでは有効になっていない場合、それを公開するビルドフラグやSDKコンポーネントはありますか? TIM-VX/ORTを通るサポート済みの経路がない場合、NXPが推奨する汎用推論をGC7000UL上で直接実行する方法(例えばOpenCL/OpenVXレイヤー経由、その部分は機能が確認されているため)やサンプルアプリ、SDKコンポーネント、または参照実装などを基準に構築する方法はありますか? 現在学生で、この実装に取り組みながらGPUの上にORTを動かそうとしているのですが、GPUを使って推論できる方法、あるいは他に何か方法はありますか? どうもありがとうございます。 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 @WaleedO さん。 NXPサポートまでご連絡いただきありがとうございます。 GPU上で推論を実行するにはGPUデリゲートを使うべきで、これを使うとサポートされた操作をCPUだけで動作するのではなくGPUで加速できます。 利用可能な実行バックエンド、設定の委任、サポートフレームワーク、例のアプリケーションをよりよく理解するために、 Machine Learning ユーザーガイド の確認をお勧めします。ガイドには、GPUデリゲートが正しく読み込まれているか、モデルが期待通りに動作しているかを確認するためのステップバイステップの例も含まれています。 セットアップや実行中に問題が発生した場合は、モデル、BSPバージョン、使用しているコマンドを共有していただければ、喜んでサポートいたします。 よろしくお願いします、 アレハンドロ・ガルシア Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 @Chavira はじめまして。 ドキュメントを確認すると、GPUデリゲートとOpenCLパスは95/952 GPU(Arm Mali G310)内で i.MX 使われています。現在、『The IMX8MPLUS』に取り組んでいます。 IMX8M Plusは以下のスタックを持っています:VX delegate ==> TIM-VX ==> GPU/NPU(統一ドライバー)==> I.MX 8シリーズNPU、 GPU(GC7000,GC7000L、GC7000UL)。ドキュメントによると。 現在、私はONNXとORTを扱っています。実行時には、デフォルトでNPU上で実行されます。OpenCLを使って IMX8MPLUS GPUで作業する方法はありますか?あるいは、コンパイルをNPUかGPUに手動で設定できる手動オーバーライドや技術があれば教えてください。 ご返信いただき、誠にありがとうございます。 敬具、 IMX8MPLUS #TIM-VX #VX-delegate Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 はい、まだ可能な経路はありますが、VSINPU Execution プロバイダにGC7000ULを強制するのは避けたほうがいいです。 あなたの結果は、現在のNXP TIM-VX/OVXLIBのビルドが主にVIP8000 NPU向けに設計されていることを強く示唆しています。gcoHAL_SetDeviceIndex libGAL.so だけではTIM-VXがNNグラフをGPUにリダイレクトできるわけではありません。 まずは、ONNXランタイムの外で、小さなモデルでTIM-VX/OpenVXを直接テストします。 お使いのOVXLIBがGC7000UL/GPUのNNターゲットを公開しているか確認してください。 NXP TIM-VXのビルドとアップストリームのTIM-VXを比較してみてください。特にマルチデバイス/プラットフォームのサポートです。 もしTIM-VXがGC7000ULでコンパイルできない場合は、GPUベンチマークとしてVivante OpenCL/OpenVXスタックを直接使用してください。 MLPerfプロジェクトでは、GPUパスに必ずしもORTは必要ありません。別のGC7000ULバックエンドを作成し、CPU/NPU用の同じLoadGenハーネスに接続することができます。 ですので、次のように構成します。 MLPerf LoadGen → ResNet50 GPU バックエンド → OpenCL/OpenVX → GC7000UL それよりも： MLPerf→ORT→VSINPU→GPUを強制的に使います ベストリグラッド、 フェサジ

参考文档请求：在 S32DS 中将 AI 工具与 Cody Chat 集成 尊敬的NXP社区团队： 我目前正在使用 S32 Design Studio，并使用 IDE 中提供的 Cody Chat 功能。 我想知道是否可以将OpenAI ChatGPT 和 Anthropic Claude等外部 AI 模型集成到 S32 Design Studio 的 Cody Chat 部分中。 我的需求是在 S32DS 内部直接使用 AI 助手来执行以下操作： C/C++ 代码生成及说明 嵌入式 C 开发 调试编译器和链接器错误 CAN、SPI、I2C、UART 和 ADC 开发 S32K3/S32K344 开发 了解并参与当前的S32DS项目项目。 我发现 Sourcegraph Cody 的官方文档描述了对 OpenAI 和 Anthropic 模型的支持，包括模型配置和自带密钥 (BYOK) 选项。 请问您能否澄清一下： S32 Design Studio 中使用的 Cody 集成是否能够连接到 ChatGPT/OpenAI 和 Claude 等外部 AI 提供商？ 我们能否在 Cody Chat 部分为这些 AI 提供商配置我们自己的 API 密钥？ 是否有任何 NXP 官方文档、S32DS 文档、Cody 文档或示例项目说明如何在 S32DS 中配置或将外部 AI 模型与 Cody 集成？ 如果当前 S32DS 版本不直接支持此功能，是否有官方方法可以扩展 Cody/Eclipse 插件以支持外部 AI 提供商？ 与标准的 Sourcegraph Cody 实现相比，S32DS 实现的 Cody 是否存在任何限制？ 作为参考，我找到了以下关于支持的LLM和模型配置的Sourcegraph文档： 支持的LLM 科迪模型配置 Cody 模型配置示例 请问能否提供NXP的相关参考文档或推荐的S32DS实施流程？ 感谢您的支持。 此致， 阿拉文德·托加拉利 Re: Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS 你好， 人工智能工具及其外部使用文档计划于9月26日发布。

Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS Dear NXP Community Team, I am currently working with S32 Design Studio and using the Cody Chat feature available in the IDE. I would like to know whether it is possible to integrate external AI models such as OpenAI ChatGPT and Anthropic Claude into the Cody Chat section of S32 Design Studio. My requirement is to use an AI assistant directly inside S32DS for activities such as: C/C++ code generation and explanation Embedded C development Debugging compiler and linker errors CAN, SPI, I2C, UART and ADC development S32K3/S32K344 development Understanding and working with the current S32DS project context I found that the official Sourcegraph Cody documentation describes support for both OpenAI and Anthropic models, including model configuration and Bring Your Own Key (BYOK) options. Could you please clarify: Is the Cody integration used in S32 Design Studio capable of connecting to external AI providers such as ChatGPT/OpenAI and Claude? Can we configure our own API key for these AI providers in the Cody Chat section? Is there any official NXP documentation, S32DS documentation, Cody documentation, or example project explaining how to configure or integrate external AI models with Cody in S32DS? If this functionality is not directly supported in the current S32DS version, is there an official method to extend the Cody/Eclipse plugin to support external AI providers? Are there any restrictions in the S32DS implementation of Cody compared with the standard Sourcegraph Cody implementation? For reference, I found the following Sourcegraph documentation regarding supported LLMs and model configuration: Supported LLMs Cody Model Configuration Cody Model Configuration Examples Could you please provide the appropriate NXP reference documentation or recommended procedure for implementing this in S32DS? Thank you for your support. Best regards, Aravind Togaralli Re: Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS Hi,  the release of AI tools with documentation for external usage is planed on September 26. 

PFE EMAC0 ECUウェイクアップ後の無効なバッファアクセス こんにちは、 EMAC0を2500 Mbpsで設定し、必要なSERDESチャネル設定も行っています。ECUの稼働状態中は、イーサネット通信が正常に動作しています。 Eth通信にアクセスするアプリケーションをシャットダウンした後、ECUMからECUスリープリクエストをトリガーし、MCUモードをSOCスタンバイに設定し、HSE_CM7をメインコアとして選択します。 ウェイクアップ後、ECUは通常の動作に戻り、COM、SOAD、TCPIP、ETHIFのレイヤーは期待通りに動作します。EthのIFレイヤーでは、API呼び出し中の「Provide TX buffer」が「Provide TX buffer」が空いていないというエラーを返し、その後Ethフレームの送信が停止します 問題解決のために試された修正方法のリスト: 1. 「Eth_43_Pfe_Deinit」を使ってPFEドライバをシャットダウンし、「Eth_43_Pfe_Init」を呼んでPFEドライバを起動しようとしましたが、実行後にCPUがロックされてしまいました。 2. EthコントローラをEth_43_Pfe_SetControllerモードで下げてアクティブに戻そうとしたところ、バス障害が発生しました この問題の解決策を教えてください。 追伸> 使用コンフィギュレーター:EB tresos Eth PFE RTDバージョン:1.3.0 SDK:GOLDVIP Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん ご返信よろしくお願いします。 1.SOCがスタンバイモードに入ると、パーティション2のPFEクロックが無効になります。ウェイクアップ後にパーティション2が再度有効になっているか確認してください。PFE開始前のPCSの状態PRTN2_STATを確認してみてください。PFE開始前のPCS状態。 2. SERDESが正常に機能しているかどうかを確認します。 BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 @Joey_z 1.PFEはMコアでのみ使用されています 2. 開発ボードを使っています:S32G-VNP-RDB3 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん お問い合わせいただきありがとうございます。 1. PFEはMコアでのみ使用されますか？Aコアを一緒に使ったことはありますか？ 2. お客様のボードを使っていますか、それとも私たちの開発ボードを使っていますか? BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、@Joey_z。 ステータスレジスタのビットフィールドはスリー プ前Partition_2 1のままですが、スリープ中は 0 に更新され、MCUモードが通常に設定された後、ウェイクアップ後には再び 1 に更新されます。 Serdesは正常に動作しています。さらに、ET Phyコネクタ(RJ45)とコントローラー(NXPS32G399A)の間にSERDESが関与しないRGMIIモードでEMAC2を試しましたが、それでも問題は同じままでした。 Partition_2の起動後に再起動シーケンスが必要な場合は、お知らせください。 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん 問題は、おそらくウェイクアップ後のPFE初期化に関するものと思われます。クロックと関連するPFE構成を確認し、理想的な状態に初期化されていることを確認してください。 1. PFEの初期化がブートローダーに入力され、起動後にアプリケーション内で正しく再初期化されているか確認してください。 2. スタンバイプロセスに従って該当する構成を確認する。RM 32.5.5「実行モードからスタンバイモードへ」を参照してください。 BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん ご返信よろしくお願いします。 スタンバイとウェイクアップシーケンスの操作について教えていただけますか? 1. コアとパーティションはどのように設定しますか？ 2.Do アプリケーションでブートローダーとAコアを使っていますか? BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 @Joey_z さん。 以下に睡眠・覚醒の順序を示します。 1. API 「EcuM_SelectShutdownTarget()」 を使ってECUスリープモードをリクエストしています。これにより、ECUMの実装通りにMCUモードがスタンバイに設定されます。 2. ECUMがスリープモードに入ると、ウェイクアップイベントをポーリングし、CANトランシーバーがバスの活動を検出してEcuM_SetWakeupEvent() APIを使ってウェイクアップイベントを設定し、その後ECUは通常の動作を再開します。 ブートローダーについては、NXPのブートローダー(0x0にフラッシュされる)のフラッシュ位置と、Mコアアプリケーションが0x400000にフラッシュされます。Aコアはどこにも使用されていません。 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 Avinash_7373 あなたの問題について何か進展はありましたか？もし継続的なサポートが必要な場合は、以下のリンクからコードをアップロードしていただければ問題をより詳しく分析できます。 https://support.nxp.com BR ジョーイ

can not get all details with command: v4l2-ctl --device /dev/video0 --all Hi All, I'm working with camera sensor os02g10. I can get the RAW10 file from sensor but the picture is not correct. There is misalignment  and picture has 2 parts shifted to each other. You can see it here: https://community.nxp.com/t5/i-MX-Processors/Camera-sensor-os02g10-MIPI-CSI-for-IMX8MM-Image-issue/m-p/1512386#M194329 I tested many DeviceTree setting for camera sensor and mipi-csi but no changes in the picture. There is also issue with v4l2, below you can see it. Why it can not get Driver Info: Driver name : mx6s-csi Card type : i.MX6S_CSI Bus info : platform:32e20000.csi_bridge Driver version : 5.10.72 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Priority: 0 Video input : 0 (Camera: ok) Format Video Capture: Width/Height : 1920/1080 Pixel Format : '' Field : None Bytes per Line : 0 Size Image : 4147200 Colorspace : Default Transfer Function : Default (maps to Rec. 709) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Full Range) Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 0, Height 0 Default : Left 0, Top 0, Width 0, Height 0 Pixel Aspect: 1/1 Selection Video Capture: crop, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_padded, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: native_size, Left 0, Top 0, Width 0, Height 0, Flags: But when I get picture there is more details. I try to identify if v4l2 is the source of incorrect picture or something else. What can be wrong ? v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 3840 Size Image : 4147200 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags : VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned 0 (Success) cap dqbuf: 0 seq: 0 bytesused: 4147200 ts: 46.903731 delta: 46903.731 ms (ts-monotonic, ts-src-eof) i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Hi, you can use our linux upstreamed driver,  we have tested this on i.mx8mp based debix platform.  Here is our driver  https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad Here is our DT https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- Rutvij  SiliconSignals Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Looks like mx6s_vidioc_g_fmt_vid_cap is incomplete.  mx6s_vidioc_s_fmt_vid_cap has all details btarnowski_0-1672393812102.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all regarding RAW10 there is solution https://community.nxp.com/t5/i-MX-Graphics/gst-launch-1-0-returns-Internal-data-stream-error/m-p/1536966 and regarding: v4l2-ctl --device /dev/video0 --all hard to say what is wrong, maybe camera driver uses ctrl API instead ctrlio for V4L2 But now it's not problem, for me next thing is to set parameter like exposure or gain Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all hi @btarnowski  for the display thing with v4l2-ctl --all, you just need to edit mx6s_capture.c In function 'mx6s_vidioc_s_fmt_vid_cap' : just copy the whole pix struct instead of just width/height/sizeimage/field csi_dev->pix = f->fmt.pix; this way, internal struct csi_dev->pix has all the information needed when you do a get_format (see function mx6s_vidioc_g_fmt_vid_cap) i feel mx6s_capture.c is full of little mistakes and needs a lot of improvements to have a better compliance with v4l2 tools. regards Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Hi, Regarding v4l2-ctl --device /dev/video0 --all  and  gstream no progress. Looks like it is camera sensor driver issue. dev/media0 - is not necessary There is different approaches for handling camera sensor. Below you can see differences for low level API handling. ov5640 (camera sensor) works on other device. btarnowski_0-1663928001102.png And the other comparison: btarnowski_1-1663928150167.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all did you get any solution for that? because i have got the same error if you got pls share your solution Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all And also I see not correct assignments. The csi_bridge should be assigned to media0. btarnowski_0-1662374734790.png How to do that, any help? Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all in the meantime: root@qrnd:~# gst-inspect-1.0 -a > gst-inspect.txt and the result below in the attachement Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all next issue: I can see video devices, but there is no /dev/media devices root@qrnd:~# v4l2-ctl --list-devices i.MX6S_CSI (platform:32e20000.csi_bridge): /dev/video0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video2 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video1 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all I had to update the list of packages for yocto build: # Camera support tools IMAGE_INSTALL_append = " i2c-tools" IMAGE_INSTALL_append = " v4l-utils" IMAGE_INSTALL_append = " gstreamer1.0" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good" IMAGE_INSTALL_append = " gstreamer1.0-plugins-imx" IMAGE_INSTALL_append = " gstreamer1.0-plugins-base" IMAGE_INSTALL_append = " gst-player" IMAGE_INSTALL_append = " gstreamer1.0-meta-base" IMAGE_INSTALL_append = " gst-examples" IMAGE_INSTALL_append = " gstreamer1.0-rtsp-server" IMAGE_INSTALL_append = " gst1.0-fsl-plugin" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-video4linux2" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-png" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-jpeg" but now I have issue with the command gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=1 ! video/x-raw,width=1920,height=1080 ! pngenc ! filesink location=/tmp/test_1920x1080.png I got: Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline: pipeline0/GstV4l2Src:v4l2src0: Internal data stream error. Additional debug info: ../git/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: streaming stopped, reason not-negotiated (-4) Execution ended after 0:00:00.057218529 Setting pipeline to NULL ... Freeing pipeline ... Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Looks that Yocto makes this issue. There is no all needed components in the kernel image. Lack of v4lsrc from gstreamer-plugins-good. I added additional packages to Yocto build but no effect. Need to investigate the deploy stage of Yocto build process.

摩托罗拉 MCQ1C3L69J 和摩托罗拉 MC908Q4CP 数据手册 我正在寻找以上两种元器件的数据手册，谢谢。 Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets 你好， 由此给您带来的不便，我深表歉意。这是老产品，信息有限； MC908Q4CP：您是不是想说的是“908QC4”，而您正在寻找的是MC68HC908QC4？如果是这样，这是数据手册[ MC68HC908QC16、MC68HC908QC8、MC68HC908QC4 - 数据手册] 有关 C08Q 系列的更多数据手册，请参阅HC08Q|8 位 EEPROM 仿真 Q MCU | NXP 半导体 MCQ1C3L69J：根据勘误信息，“3L69J”指的是掩码； 您能否帮我们确认一下，您是否还有其他名称可以用来识别该设备？ 顺祝商祺！ Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets Hello 谢谢！ 请看附图

S9KEAZN16AM WDOG 时序说明：128 个总线时钟与观察到的 80 微秒和 2.5 毫秒延迟对比 你好， 我正在与S9KEAZN16AM合作，想了解一下 WDOG 初始化时间的相关问题。 配置 MCU：S9KEAZN16AM 总线时钟：16.777216 MHz WDOG 时钟源：1 kHz LPOCLK 重置类型：软件重置（SYSRESETREQ） 根据KEA64参考手册，在看门狗解锁序列之后： “解锁序列完成后，用户必须在 128 个总线时钟周期内重新配置看门狗；否则，看门狗将强制 RESET MCU。” ppande19_1-1784788705383.pngppande19_1-1784788705383.png 总线时钟频率为 16.777216 MHz： 128 个总线时钟周期 ≈ 7.63 微秒 说明 为了确保可靠运行，我们目前的实施方案需要以下延迟： 软件重置();   SysTick_DelayUs(2500);   禁用中断();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   启用中断(); 我们发现两个问题： 如果移除或减少Software_Reset() 之后的 2.5 毫秒延迟，看门狗计数器并不总是能正确启动/运行。 如果移除WDOG_Init() 之后的 80 µs 延迟，看门狗配置将无法始终正确应用。 问题 128 总线时钟要求是否仅限于解锁后的配置窗口，还是之后还会进行额外的内部同步？ 使用1 kHz LPO 时钟是否会引入额外的同步延迟？ RESET后是否存在已知的启动时间要求，可以解释为何需要约 2.5 毫秒？ 是否有推荐的状态位或轮询机制可以替代固定延迟？ 主要令人困惑的是，观察到的延迟（ 80 µs 和 2.5 ms ）明显大于记录在案的128 总线时钟（~7.6 µs）要求所隐含的时序。 任何指导都将不胜感激。 谢谢！ Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays 如果在 ICS 完全锁定之前尝试初始化看门狗或运行严格的定时循环，则在该时间段内，实际总线时钟频率会较低或不稳定。较低的实际总线时钟意味着 128 个总线周期将比 7.6 µs 长得多，或者您的初始化序列在硬件外设完全脱离其RESET状态之前执行。约2.5毫秒的延迟使ICS有足够的时间完全锁定并稳定16.777216 MHz总线频率。 Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays 你好， 等待约 2.5 毫秒，以便内部时钟源 (ICS) 完全锁定并稳定总线时钟 (16.777216 MHz)。过早初始化看门狗或运行紧密循环会导致时钟不稳定/降低，从而造成时序偏差或在外部设备RESET之前执行。

高级线粒体配方评测：完整购买指南 最后更新日期：2026年9月5日 高级线粒体配方是一种膳食补充剂，旨在支持线粒体健康和细胞能量产生。与许多主要侧重于兴奋剂的普通能量补充剂不同，该配方旨在为线粒体提供营养支持，线粒体通常被称为细胞的“动力工厂”。这正是高级线粒体配方与其他市面上的线粒体支持补充剂区别开来的原因之一。 高级线粒体配方 的核心理念 很简单：为身体提供有助于维持线粒体健康功能和高效细胞能量产生的营养物质。当线粒体正常运作时，细胞就能更有效地产生能量。这有助于维持日常精力、耐力、精神集中力和整体细胞机能。 Re: Advanced Mitochondrial Formula Reviews: A Complete Buyer’s Guide 高级线粒体配方是一种膳食补充剂，由美国、加拿大、英国、澳大利亚和新西兰配制而成，旨在支持线粒体功能和健康的细胞能量产生。与许多传统能量补充剂主要依赖兴奋剂不同，它专注于提供关键营养素，帮助滋养和支持线粒体——通常被描述为我们细胞的“动力工厂”的结构。这种营养方法是ORIGINAL 高级线粒体配方与其他许多线粒体支持产品区别开来的特点之一。 高级线粒体配方的理念很简单：为身体提供营养，以帮助维持健康的线粒体活性，并支持细胞层面的有效能量产生。功能正常的线粒体在细胞产生能量的过程中发挥着重要作用。通过支持正常的线粒体功能，该配方可能有助于提高日常精力、耐力、精神警觉性和整体细胞性能。

コード戦士からハードウェアへ 私はCW_VSPA_v10.3.10を使用しています。コードのデバッグは成功したのですが、それをハードウェアにデプロイする方法がわかりません。私が使用しているボードはLA1224です。すべてのサンプルファイルには .eld が含まれていることに気づきましたおよび .mapファイル、ただし.eldのみこのファイルは私のプロジェクト内で生成されます。 Re: From codewarrior to hardware ありがとう。しかし、CodeWarrior Tapを使ってコードをデプロイできるのか、またその使い方がわからないのです。スクリプトを書いてみたのですがうまくいきませんでした。スクリプトの書き方を教えてくれる例や手順書などはありますか？ Re: From codewarrior to hardware LA1224ボードにコードをデプロイする RAMへのロードか、永続的なフラッシュメモリへのロードかによって、一般的なデプロイメント方法は2つあります。 オプションA：デバッガを使用してハードウェアに直接ロードする（開発時に最もよく用いられる方法） これは通常、デバッグ時に既に行っていることです。 手順： LA1224ボードを接続します（必要に応じてJTAG/プローブ/USB接続）。 CW_VSPAでは： Run → Debug Configurations VSPA / LA1224のデバッグ構成を選択してください 確認する： プロジェクトの.eldファイルが選択されました デバッグをクリックします ✅ これにより、既にコードがターゲットのRAMにデプロイされます。 ❌ 永続的なものではありません（電源を入れ直すと消えます）。 オプションB：コードをFlashに書き込む（スタンドアロン動作） LA1224をリセット後にアプリケーションを自動的に起動させたい場合は、以下の手順に従ってください。 一般的なプロセス： プロジェクトを構築 → 取得 .eld LA1224フラッシュプログラミングツールを使用してください（ボードのサポートパッケージによって異なります）。 CW_VSPAからよく起動される： Tools → Flash Programmer または Run → External Tools 選択： ターゲット: LA1224 入力ファイル: あなたの .eld フラッシュメモリへのプログラム ボードをリセットするか、電源を入れ直してください。 ✅ コードはデバッガーなしで実行できるようになりました ✅ .map ファイルはここでは関係ありません Re: From codewarrior to hardware こんにちは、私も同じ問題を抱えています。私はVSPA 10.3.10用のCodeWarriorを使用していますが、「ツール - Flash Programmer」オプションが見当たりません。 「対象タスク」には、「メモリのインポート/エクスポート/フィル」と「ハードウェア診断」というオプションしかありません。 VSPAイメージをフラッシュメモリにプログラムするにはどうすればいいですか? E200の場合、私はCWforARMのFlash Programmerを使用しています。オフセット0x0で*xspi.binを正常にフラッシュしました。

From codewarrior to hardware I'm using CW_VSPA_v10.3.10. After successfully debugging my code, I don't know how to deploy it to the hardware. The board I'm using is LA1224. I noticed that all the example files include both .eld and .map files, but only the .eld file is generated in my project. Re: From codewarrior to hardware Thank you. But I'm still wondering whether I can deploy my codes by using codewarrior Tap and how to use it. I tried to write a script but failed, so are there any examples or instructions that can tell me how to write a script? Re: From codewarrior to hardware Deploying your code to the LA1224 board There are two common deployment paths, depending on whether you want RAM loading or persistent Flash loading. Option A: Load directly to hardware using the debugger (most common during development) This is usually what you already did when debugging. Steps: Connect the LA1224 board (JTAG / probe / USB as required) In CW_VSPA: Run → Debug Configurations Select your VSPA / LA1224 debug configuration Make sure: The .eld file from your project is selected Click Debug ✅ This already deploys your code into target RAM ❌ It is not persistent (power cycle clears it) Option B: Program the code into Flash (standalone operation) If you want the LA1224 to boot your application automatically after reset: Typical process: Build the project → obtain .eld Use the LA1224 Flash programming tool (varies by board support package): Often launched from CW_VSPA: Tools → Flash Programmer or Run → External Tools Select: Target: LA1224 Input file: your .eld Program to Flash Reset or power-cycle the board ✅ Code now runs without debugger ✅ .map file is irrelevant here Re: From codewarrior to hardware Hi, I'm having the same problem. I'm using CodeWarrior for VSPA 10.3.10, but I don't see the “Tools - Flash Programmer” option there. Under “Target Tasks,” the only options are “Import/Export/Fill Memory” and “HW Diagnostics.” How can I program the VSPA image to the flash memory? For the E200, I use the Flash Programmer from CWforARM. I successfully flash *xspi.bin with an offset of 0x0.

从密码战士到硬件 我使用的是 CW_VSPA_v10.3.10。成功调试代码后，我不知道如何将其部署到硬件上。我正在使用的主板是 LA1224。我注意到，所有示例文件都包含 .eld和 .map文件，但只有 .eld文件已在我的项目中生成。 Re: From codewarrior to hardware 谢谢。但我仍然想知道我能否使用 codewarrior Tap 来部署我的代码以及如何使用它。我试着编写脚本，但失败了，有没有任何例子或说明可以告诉我如何编写脚本？ Re: From codewarrior to hardware 将您的代码部署到 LA1224 板上 有两种常见的部署路径，取决于你是想要 RAM 加载还是持久闪存加载。 选项 A：使用调试器直接加载到硬件（在开发过程中最常见） 这通常是您在调试时已经做过的。 步骤： 连接 LA1224 板（根据需要连接 JTAG/probe/USB） 在 CW_VSPA 中： Run → Debug Configurations 选择您的VSPA / LA1224 调试配置 确保 选择项目中的.eld 文件 点击 “Debug” ✅ 这已将代码部署到目标 RAM中 ❌ 它不是持久性的（电源循环会清除它） 选项 B：将代码编程到 Flash 中（独立组网 (SA) 操作） 如果你希望 LA1224 在RESET后自动启动应用程序： 典型流程 生成项目 → 获取 .eld 使用 LA1224 闪存编程工具（因主板支持包而异）： 通常从 CW_VSPA 启动： Tools → Flash Programmer 或 Run → External Tools 请选择： 目标： LA1224LA1224 输入文件：您的 .eld 编程至闪存 RESET主板或重新通电 ✅ 代码现在无需调试器即可运行 ✅ .map 文件与此处无关 Re: From codewarrior to hardware 您好，我也遇到了同样的问题。我使用的是 CodeWarrior for VSPA 10.3.10，但我没有在那里看到“工具 - 闪存编程器”选项。 在“目标任务”下，只有“导入/导出/填充内存”和“硬件诊断”这两个选项。 如何将VSPA镜像写入闪存？ 对于 E200，我使用 CWforARM 的 Flash Programmer。我已成功将偏移量为 0x0 的 *xspi.bin 文件刷入系统。

コマンド:v4l2-ctl --device /dev/video0 --all ですべての詳細を取得できません こんにちは、皆さん。 私はカメラセンサーOS02G10を使っています。センサーからRAW10のファイルは入手できますが、画像は正しくありません。位置ずれがあり、画像内の2つの部分が互いにずれています。こちらでご覧いただけます: https://community.nxp.com/t5/i-MX-Processors/Camera-sensor-os02g10-MIPI-CSI-for-IMX8MM-Image-issue/m-p/1512386#M194329 カメラセンサーやmipi-csiのDeviceTree設定を何度も試しましたが、画像に変化はありませんでした。 v4l2にも問題があります。下記で確認できます。なぜそれができないのか Driver Info: Driver name : mx6s-csi Card type : i.MX6S_CSI Bus info : platform:32e20000.csi_bridge Driver version : 5.10.72 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Priority: 0 Video input : 0 (Camera: ok) Format Video Capture: Width/Height : 1920/1080 Pixel Format : '' Field : None Bytes per Line : 0 Size Image : 4147200 Colorspace : Default Transfer Function : Default (maps to Rec. 709) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Full Range) Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 0, Height 0 Default : Left 0, Top 0, Width 0, Height 0 Pixel Aspect: 1/1 Selection Video Capture: crop, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_padded, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: native_size, Left 0, Top 0, Width 0, Height 0, Flags: しかし、写真を見るともっと詳細がわかる。v4l2が画像がおかしい原因なのか、それとも別の原因なのかを特定しようとしています。何が問題なのでしょうか? v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 3840 Size Image : 4147200 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags : VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned 0 (Success) cap dqbuf: 0 seq: 0 bytesused: 4147200 ts: 46.903731 delta: 46903.731 ms (ts-monotonic, ts-src-eof) i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all こんにちは、Linuxのアップストリームドライバーを使えます。 私たちはこれをi.mx8MPベースのDebixプラットフォームでテストしました。 こちらがドライバです https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad こちらが当社のDTです https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- ルトヴィイ シリコンシグナルズ Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all mx6s_vidioc_g_fmt_vid_cap が不完全なようです。 mx6s_vidioc_s_fmt_vid_cap にはすべての詳細が記載されています btarnowski_0-1672393812102.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all RAW10に関しては解決策があります https://community.nxp.com/t5/i-MX-Graphics/gst-launch-1-0-returns-Internal-data-stream-error/m-p/1536966 また、v4l2-ctl --device /dev/video0 --all に関して 何が問題なのかは判断が難しいですが、もしかするとカメラドライバーはV4L2でctrlioではなくctrl APIを使っているのかもしれません しかし今は問題ではないので、次にすべきことは露出やゲインなどのパラメータを設定することです Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all こんにちは、 @btarnowskiさん v4l2-ctl --all で表示させるには、mx6s_capture.c を編集するだけで済みます。関数 'mx6s_vidioc_s_fmt_vid_cap' では、幅/高さ/サイズ画像/フィールドだけでなく、pix 構造体全体をコピーしてください。 csi_dev->pix = f->fmt.pix; このようにすることで、内部構造体 csi_dev->pix には get_format を実行する際に必要なすべての情報が含まれます (関数 mx6s_vidioc_g_fmt_vid_cap を参照)。 mx6s_capture.cには細かいミスがたくさんあり、v4l2ツールとの互換性を向上させるためには多くの改善が必要だと感じています。 よろしくお願いします。 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all こんにちは、 v4l2-ctl --device /dev/video0 --allとgstreamに関して進展がありません。 カメラセンサのドライバの問題のようです。 dev/media0 - 不要 カメラセンサーの取り扱いにはさまざまなアプローチがあります。 以下に、低レベルのAPI処理の違いを示します。 OV5640(カメラセンサー)は他のデバイスで動作します。 btarnowski_0-1663928001102.png そしてもう一つの比較： btarnowski_1-1663928150167.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 何か解決策は見つかりましたか？私も同じエラーが出ています。もし同じエラーが出たら、解決策を教えてください。 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all また、正しくない課題も見られます。csi_bridgeはmedia0に割り当てる必要があります。 btarnowski_0-1662374734790.png どうすればいいですか？何かアドバイスをいただけますか？ Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all その間に： root@qrnd:~# gst-inspect-1.0 -a > gst-inspect.txt 結果は添付ファイルに記載されています。 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 次の問題:ビデオデバイスは見えますが、/dev/mediaデバイスはありません root@qrnd:~# v4l2-ctl --list-devices i.MX6S_CSI (platform:32e20000.csi_bridge): /dev/video0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video2 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video1 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Yocto ビルド用のパッケージリストを更新しなければなりませんでした: # カメラサポートツール IMAGE_INSTALL_append = "i2c-tools" IMAGE_INSTALL_append = "v4l-utils" IMAGE_INSTALL_append = "gstreamer1.0" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good" IMAGE_INSTALL_append = " gstreamer1.0-plugins-imx" IMAGE_INSTALL_append = " gstreamer1.0-plugins-base" IMAGE_INSTALL_append = " gst-player" IMAGE_INSTALL_append = " gstreamer1.0-meta-base" IMAGE_INSTALL_append = " gst-examples" IMAGE_INSTALL_append = " gstreamer1.0-rtsp-server" IMAGE_INSTALL_append = " gst1.0-fsl-plugin" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-video4linux2" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-png" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-jpeg" しかし、コマンドに問題が発生しました gst -ローンチ- 1.0v4l2srcデバイス= / dev / video0 num - buffers = 1 !ビデオ/ x - raw 、幅= 1920 、高さ= 1080 !pngenc !filesink location =/ tmp / test_1920x1080 . png 私は以下を受け取りました： Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline: pipeline0/GstV4l2Src:v4l2src0: Internal data stream error. Additional debug info: ../git/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: streaming stopped, reason not-negotiated (-4) Execution ended after 0:00:00.057218529 Setting pipeline to NULL ... Freeing pipeline ... Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all どうやらYoctoがこの問題を作っているようです。カーネルイメージには必要なコンポーネントがすべて含まれているわけではありません。gstreamer-plugins-goodから v4lsrc が欠落しています。Yocto Buildに追加のパッケージを追加しましたが、効果はありませんでした。Yoctoビルドプロセスのデプロイ段階を調べる必要があります。

PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi, I have configured EMAC0 at 2500 MBPS with required SERDES channel configuration. The Eth communication is up and running during ECU run state.  After shutting down the applications accessing Eth communication, I trigger the ECU sleep request from ECUM with sets the MCU mode to SOC standby with HSE_CM7 selected as main core.  Post wakeup the ECU resumes the normal operation, the layers COM, SOAD, TCPIP, ETHIF are working as expected, In the Eth if layer during the API invocation of "Provide TX buffer" returns an error stating TX buffers are not free, followed by no transmission of Eth frames List of fixes tried resolve the issue: 1. Tried to Shutdown the PFE driver using "Eth_43_Pfe_Deinit" and starting the PFE driver by calling "Eth_43_Pfe_Init" but the CPU gets locked after the execution if Init API. 2. Tried to turndown the Eth controller using Eth_43_Pfe_SetController mode to down and bring it active by setting back the mode to "Active" which led to bus fault Please let me know the potential fix for this issue.  P.S> Configurator Used: EB tresos Eth PFE RTD version:  1.3.0  SDK: GOLDVIP Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi @Joey_z  1. The PFEs are only being used in M-core 2. I'm using the development board: S32G-VNP-RDB3 Regards, Avinash V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi,Avinash_7373 Thank you for contacting us. 1.Are the PFEs only used in the M core? Have you used the A core together? 2.Are you using your customer board or our development board? BR Joey Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi,Avinash_7373 Thank you for your reply. 1.When the SOC entry the mode of standby, about the PFE clock of partition2 will be disabled, you should check if you have reenabled the partition2 after wakeup. You can try to check the  PRTN2_STAT.PCS state before the PFE Init. 2. Check the SERDES if it is a normal function. BR Joey Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi @Joey_z, The bitfield in Partition_2 status register remains 1 pre-sleep, it gets updated to 0 during sleep state and it is getting updated back to 1 post wakeup i.e, after the MCU mode is set to normal. The Serdes is working fine. Additionally I have tried with EMAC2 in RGMII mode where SERDES is not involved in between the ETH Phy connector (RJ45) and the controller (NXPS32G399A) even in this case the issue remained the same. If there is any restart sequence required for Partition_2 post wakeup, please let me know. Regards, Avinash V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi,Avinash_7373 Thank you for your reply. Could you tell me about your operation of standby and wakeup sequence?  1. How to you set the core and partition? 2.Do you use the bootloader and A core in your application? BR Joey Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi @Joey_z, Please find the sleep-wakeup sequence below: 1. I'm requesting ECU sleep mode using API "EcuM_SelectShutdownTarget()"  which in turns sets the MCU mode to standby as per the ECUM implementation. 2. Once the ECUM enters sleep mode it polls for a wakeup event, the CAN transceiver detects the bus activity and set the wakeup event using EcuM_SetWakeupEvent() API then the ECU resumes normal operation. Regarding bootloader, we have the NXP bootloader (blob is flashed at 0x0) location of flash and the M-core application is flashed at location 0x400000.  A-core is not being used anywhere. Regards, Avinash V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi,Avinash_7373 Your problem is likely to be a PFE initialization issue after wakeup. Check the clock and the related PFE configuration, and ensure that it has been initialized to an ideal state. 1. Check that the PFE initialization is put into bootloader and properly reinitialized in the application after waking up. 2. Check the relevant configurations according to the Standby process. Refer to RM 32.5.5 "Run mode to Standby mode". BR Joey Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi，Avinash_7373 Has there been any progress on your issue? If you need continued support, could you please upload your code to the following link so that we can better analyze the problem? https://support.nxp.com BR Joey

Motorola MCQ1C3L69JおよびMotorola MC908Q4CPのデータシート 上記2つの部品のデータシートを探しています。 Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets こんにちは、 ご不便をおかけし申し訳ありません。これは古い製品で情報が限られています。 MC908Q4CP: もしかして「908QC4」のことで、MC68HC908QC4をお探しでしょうか？もしそうなら、こちらがデータシートです[MC68HC908QC16、MC68HC908QC8、MC68HC908QC4 - データシート] C08Qファミリーに関するさらなるデータシートについては 、HC08Q|8ビットEEPROMエミュレーションQ MCUを参照してください。NXPセミコンダクターズ MCQ1C3L69J: 「3L69J」は、正誤表の情報によるとマスクを指しています。 デバイスを特定するための他の名前があるか確認していただけますか? よろしくお願いいたします。 Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets Hello よろしくお願いします。 添付画像をご覧ください

S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays Hello, I am working with S9KEAZN16AM and would like some clarification regarding WDOG initialization timing. Configuration MCU: S9KEAZN16AM Bus Clock: 16.777216 MHz WDOG Clock Source: 1 kHz LPOCLK Reset Type: Software Reset (SYSRESETREQ) According to the KEA64 Reference Manual, after the watchdog unlock sequence: "On completing the unlock sequence, the user must reconfigure the watchdog within 128 bus clocks; otherwise, the watchdog forces a reset to the MCU." ppande19_1-1784788705383.pngppande19_1-1784788705383.png With a bus clock of 16.777216 MHz: 128 bus clocks ≈ 7.63 µs Observations Our current implementation requires the following delays for reliable operation: Software_Reset();   SysTick_DelayUs(2500);   DisableInterrupts();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   EnableInterrupts(); We observe two issues: If the 2.5 ms delay after Software_Reset() is removed or reduced, the watchdog counter does not always start/run correctly. If the 80 µs delay after WDOG_Init() is removed, the watchdog configuration is not always applied correctly. Questions Is the 128 bus clock requirement only the configuration window after unlock, or does additional internal synchronization occur afterwards? Can the use of the 1 kHz LPO clock introduce additional synchronization delays? Is there any known startup timing requirement after a software reset that could explain the need for ~2.5 ms? Is there a recommended status bit or polling mechanism that should be used instead of fixed delays? The main point of confusion is that the observed delays (80 µs and 2.5 ms) are significantly larger than the timing implied by the documented 128 bus clock (~7.6 µs) requirement. Any guidance would be greatly appreciated. Thank you. Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays you try to initialize the watchdog or run tight timing loops before the ICS has completely locked, your actual bus clock frequency will be lower or unstable during that window. A lower actual bus clock means that 128 bus cycles will take significantly longer than 7.6 µs, or your initialization sequence executes before the hardware peripherals are fully out of their reset state. The ~2.5 ms delay gives the ICS ample time to achieve a full lock and stabilize the 16.777216 MHz bus frequency.   Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays Hello, Wait ~2.5 ms for the Internal Clock Source (ICS) to achieve a full lockand stabilize the bus clock (16.777216 MHz). Initializing the watchdogor running tight loops too early results in an unstable/lower clock,causing timing discrepancies or executing before peripherals leave reset.

PFE EMAC0 ECU唤醒后无效缓冲区访问 你好， 我已经将 EMAC0 配置为 2500 MBPS，并进行了所需的 SERDES 通道配置。ECU运行期间，以太网通信正常进行。 关闭所有访问以太网通信的应用程序后，我从ECUM触发ECU睡眠请求，将MCU模式设置为SOC待机模式，并选择HSE_CM7作为主核心。 ECU唤醒后恢复正常运行，COM、SOAD、TCPIP和ETHIF层工作正常。但在ETHIF层调用“提供TX缓冲区”API时，返回错误信息，提示TX缓冲区已满，导致无法发送以太网帧。 以下列出了尝试解决此问题的修复方法： 1. 尝试使用“Eth_43_Pfe_Deinit”关闭 PFE 驱动程序，并通过调用“Eth_43_Pfe_Init”启动 PFE 驱动程序，但如果执行 Init API，CPU 将在执行后锁定。 2. 尝试使用 Eth_43_Pfe_SetController 模式将以太网控制器关闭，然后通过将模式设置回“Active”来激活它，结果导致总线故障。 请告知此问题的潜在解决方案。 PS> 使用的配置器：EB tresos 以太坊 PFE RTD 版本：1.3.0 SDK：GOLDVIP Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好，Avinash_7373 感谢您的回复。 1.当 SOC 进入待机模式时，分区 2 的 PFE 时钟将被禁用，唤醒后应检查是否已重新启用分区 2。您可以尝试在 PFE 初始化之前检查 PRTN2_STAT.PCS 状态。 2. 检查 SERDES 是否正常工作。 BR 乔伊 Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 嗨@Joey_z 1.PFE 仅用于 M 型核心。 2. 我使用的是开发板： S32G-VNP-RDB3 问候， 阿维纳什·V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好，Avinash_7373 感谢您与我们联系。 1. PFE 是否仅用于 M 核心？你们都用过A核心组件吗？ 2.您使用的是客户的开发板还是我们的开发板？ BR 乔伊 Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 嗨@Joey_z ， Partition_2 状态寄存器中的位域在睡眠前保持为1 ，在睡眠状态下更新为0 ，在唤醒后（即 MCU 模式设置为正常后）更新回1 。 SerDes 工作正常。此外，我还尝试了 EMAC2 的 RGMII 模式，其中 ETH Phy 连接器 (RJ45) 和控制器 (NXPS32G399A) 之间不涉及 SERDES，即使在这种情况下，问题仍然存在。 如果 Partition_2 在唤醒后需要任何重启顺序，请告知。 问候， 阿维纳什·V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好，Avinash_7373 您的问题很可能是唤醒后 PFE 初始化问题。检查时钟和相关的 PFE 配置，并确保其已初始化到理想状态。 1. 检查 PFE 初始化是否已放入引导加载程序中，并在应用程序唤醒后正确重新初始化。 2. 根据备用流程检查相关配置。请参阅 RM 32.5.5“运行模式到待机模式”。 BR 乔伊 Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 嗨@Joey_z ， 请查看以下睡眠-觉醒顺序： 1. 我正在使用 API " EcuM_SelectShutdownTarget()"请求 ECU 进入睡眠模式，这反过来会根据 ECUM 的实现将 MCU 模式设置为待机模式。 2. 当ECU进入睡眠模式后，它会轮询唤醒事件，CAN收发器检测到总线活动并使用EcuM_SetWakeupEvent() API设置唤醒事件，然后ECU恢复正常运行。 关于引导加载程序，NXP引导加载程序（blob文件刷写在闪存的0x0地址）和M-core应用程序刷写在0x400000地址。A核心目前在任何地方都没有使用。 问候， 阿维纳什·V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好，Avinash_7373 感谢您的回复。 能否介绍一下你们的待机和唤醒顺序？ 1. 如何设置核心和分区？ 2.你的应用程序中是否使用了引导加载程序和A核心？ BR 乔伊 Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好， Avinash_7373 你的问题有进展吗？如果您需要继续获得支持，请将您的代码上传到以下链接，以便我们更好地分析问题？ https://support.nxp.com BR 乔伊

Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets I am looking for the datasheets for the above 2 components Please Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets Hello, I apologize for the inconveniences this might cause you, this are old product and the information is limited; MC908Q4CP: Is it possible that you meant "908QC4" and looking for the MC68HC908QC4? If so this is the Datasheet [MC68HC908QC16, MC68HC908QC8, MC68HC908QC4 - Data Sheet] For more datasheets on the C08Q family refer to HC08Q|8-bit EEPROM Emulation Q MCUs | NXP Semiconductors MCQ1C3L69J: The "3L69J" is referring to a mask according to the erratas information; Could you help us confirm if you have an additional name to identify the device? Best Regards Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets Hello Thanks Please see attached picture

Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK Dear NXP Support Team, While reviewing the i.MX95 19x19 CPU EVK board schematic, I noticed that the SD2_VSEL and SD2_RST_B signals are connected to the FP09 GPIO1 and GPIO2 pins. Could you please explain the purpose of these connections in more detail? In particular, I would like to understand why these two signals are connected to the GPIO pins and how they are intended to be controlled or used in the system. Best regards, Walter Re: Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK The intent is to let the i.MX95 uSDHC2 block control the SD-card power rails through the PF09 PMIC, rather than treating those nets as ordinary board GPIOs. SD2_VSEL → PF09 GPIO1 : this is for SD/SDIO voltage switching. The i.MX95 uSDHC VSELECT output is defined as a signal used to change the external power-supply voltage, and the controller supports voltage selection through VEND_SPEC[VSELECT] . In PF09, GPIO1 can be configured as a dedicated VSELECT input ; when enabled, GPIO1 selects LDO2 = 3.3 V when low and LDO2 = 1.8 V when high . This matches the SD3.0 requirement that the platform implement both 3.3 V and 1.8 V signaling. SD2_RST_B → PF09 GPIO2 : this is for card power/reset control. The i.MX95 RESET_B signal is described as optional, active-low, and for a removable card it can be used “instead of hardware reset to enable/disable Card power during warm reset.” PF09 GPIO2 can be configured as an LDO1EN input , where the pin enables or disables the LDO1 output by hardware. So the EVK connection gives the uSDHC2 reset/power-control signal a direct path to the PMIC-controlled SD-card supply. In practical terms, these PF09 pins are not being used as random expansion GPIOs on the EVK. They are multi-function PMIC pins wired so the SD host controller can request the correct SD-card rail behavior: Signal PF09 pin role System purpose SD2_VSEL PF09 GPIO1 in VSELECT mode Switch NVCC_SD2 /SD I/O supply between 3.3 V and 1.8 V for SD3.0 operation. SD2_RST_B PF09 GPIO2 in LDO1EN mode or equivalent card-power control role Enable/disable SD-card power, especially around reset/warm-reset behavior. So the control path is typically: uSDHC2 driver/U-Boot configures the SD host controller → uSDHC2 drives SD2_VSEL and/or SD2_RST_B → PF09 interprets those pins according to its OTP/configuration → PF09 changes the SD-related LDO state . PF09’s GPIO modes/default behavior are OTP-configurable, and its GPIO outputs can also be controlled in system-on states when configured as GPOs, but the EVK wiring is intended to use the PMIC’s dedicated SD power-management functions rather than manual bit-banging. Bottom line: SD2_VSEL and SD2_RST_B are routed to PF09 GPIO1/GPIO2 so the i.MX95 uSDHC2 interface can perform SD-card voltage switching and card power/reset control through the PMIC. Re: Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK Hello, Yes. Those connections are intentional SD2_VSEL and SD2_RST_B are used to let the i.MX95 USDHC2 interface control the SD-card power/reset behavior through the PF09 PMIC, rather than being ordinary GPIO signals. SD2_VSEL → PF09 GPIO1: controls the SD-card I/O voltage switching, typically between 3.3 V and 1.8 V for SD 3.0 operation. SD2_RST_B → PF09 GPIO2: provides SD-card power/reset control, particularly useful during reset or power-cycle sequences. So the intended path is essentially: i.MX95 USDHC2 → SD2_VSEL / SD2_RST_B → PF09 → SD-card power rails The Linux device tree also shows SD2_VSELECT being used by USDHC2 and SD2_RESET_B being used for SD-card power control, which confirms these are part of the normal SD-card design rather than spare GPIOs.