免费RTOS软件包问题。 亲爱的团队， 我遇到一个问题，请帮我解决一下。 配置过程中，我尝试选择免费的RTOS软件包， 请参考下图，即可了解问题所在。 期待您的回复。 谢谢 & 此致敬礼， 苏尼尔·拉德瓦。 Re: Free RTOS package issue. 你好@sunil0509 ， SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603软件包需要RTD 7.0.1，如版本说明中所述，请确认是否已安装？ SW32K3 FreeRTOS 11.1.0 version 0.8.0 CD1 Release NotesSW32K3 FreeRTOS 11.1.0 version 0.8.0 CD1 Release NotesSW32K3 FreeRTOS 11.1.0 版本 0.8.0 CD1 发行说明 工具链/IDE 项目中找不到“Freertos”。项目无法编译！当软件包尚未添加到项目中时，出现“您正在共享”的警告是预期行为。这意味着在添加“FreeRTOS”元器件并单击“更新代码”后，警告应该会消失。 请问能否确认可以使用 FreeRTOS 软件包添加、更新代码并构建项目？ Peripherals PerspectivePeripherals Perspective外围设备视角 Correct view for FreeRTOS component added to projectCorrect view for FreeRTOS component added to project项目中已添加 FreeRTOS 元器件的正确视图 此致， 朱利安 Re: Free RTOS package issue. 各位同事好， 我还想告诉您，我使用的是 GCC 10.2 版本，编译版本为 S32DS.3.6.12。我已经安装了“SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603”这个IDE，但是问题仍然存在。 请帮我解决这个问题。 谢谢，此致敬礼！ 苏尼尔·拉德瓦。 Re: Free RTOS package issue. 你好 ， 请检查这些错误，请帮我修复这些错误。 谢谢，此致敬礼！ 苏尼尔·拉德瓦

S32K344 QuadSPIから外部NVMメモリへ 私はQuadSPIモジュールを使用して、外部FRAM NVMデバイスであるCY15B102QSNと通信しています。今のところはシンプルさを保つため、デバイスとモジュールをシングルSPIモードで使用しています。 メモリへの読み書きルーチンと、読み書きをサポートするLUTシーケンスを作成しました。私の問題は、これらの関数とLUTシーケンスにおける処理の流れがどうあるべきかという点です。 s32k344 参照。マニュアルにはこの点についてあまり明確な説明がありません。 NVMへの読み書きアクセスを開始するために、s32k344のどのレジスタに書き込みが必要ですか?もし良いNXPドライバの例があれば助かります。 以下のサンプル関数を読み書きしてください。 // 読み取りシーケンス =============================================== ReadコマンドでLUTシーケンスを指定するためにBFGENCRレジスタを使用しています。 次に、C言語のステートメントを使用してメモリのアドレスを変数に読み込みます。 // 擬似コードの例 /* AHB クワッド読み取り操作 */      for(unit32 i=0; i < buf_size; ++i)         {             /*  AHB 読み取り用の LUT Seq id の値で BFGENCR[SEQID] を書き込みます。*/                quad_base_addr->BFGENCR = (quad_base_addr->BFGENCR &  ~QuadSPI_BFGENCR_SEQID_MASK) |  QuadSPI_BFGENCR_SEQID(qspi_lut_seq_read_memory);                /* 次のデータ要素を取得します */ buffer[i] = *(volatile U8_T *)(mem_addr[i]);         } // 書き込みシーケンス ============================================ 書き込みコマンドでLUTシーケンスを指定するためにBFGENCRレジスタを使用するかどうかは私には明確ではありません。 または、レジスタ書き込み時と同様にSFARとIPCRを使用するためです。 // SFARとIPCRを使用した擬似コードの例     for(unint32 i=0; i < buf_size; ++i)         {                            /* FRAMへの書き込みを有効にするためにWRENコマンドを書き込む */ cy15_write_opcode_wren(quad_base_addr, qspi_lut_seq_wren_opcode);             if(G_FALSE == qspi_is_tx_full(quad_base_addr)){     /** シリアルフラッシュアドレスレジスタ（SFAR）にメモリのアドレスをロードします */ quad_base_addr->SFAR = mem_addr;         /* シーケンスをトリガーする前に、データを TX FIFO に書き込みます。*/                    quad_base_addr->TBDR = buffer[i];         /** シーケンス ID = (1) で IPCR を書き込み用に設定、IDATASZ = 8 バイト * これでシーケンスが開始されます。*/               quad_base_addr->IPCR  = QuadSPI_IPCR_SEQID(1) | QuadSPI_IPCR_IDATSZ(8);         /* 操作が完了するまで待機してから戻ります。*/                    if( G_FALSE == qspi_wait_for_idle(quad_base_addr)){                        ret_val = QSPI_TIMEOUT_BUSY;                 }            }     } // または、読み取り操作により近いものを使用します ======================= /* AHB 書き込みクワッド操作 */     for(i=0; i < buf_size; ++i)         {             /* AHB 書き込み用の LUT Seq id の値で BFGENCR[SEQID] を書き込みます。*/                quad_base_addr->BFGENCR = (quad_base_addr->BFGENCR & ~QuadSPI_BFGENCR_SEQID_MASK) |  QuadSPI_BFGENCR_SEQID(qspi_lut_seq_write_memory);                /* 次のデータ要素を取得します */ *(volatile U8_T *)(mem_addr[i]) = buffer[i];     } Re: S32K344 QuadSPI to external NVM Memory AHBの読み取りフローは原理的には正しいですが、BFGENCR[SEQID]は読み取りループの前に一度だけ設定し、バイトごとに設定しないでください。QSPI AHBウィンドウから、例えばQSPIベースアドレスとFRAMオフセットを読み取ります。mem_addrがベースアドレスである場合は、mem_addr[i]ではなく、ベースアドレスに現在のオフセットを加えた値を使用します。 S32K344ではAHB書き込みアクセスはサポートされていません。したがって、BFGENCR の後にポインタ書き込みを行わないでください。IPコマンドを使用してFRAMに書き込みます。 CY15B102QSNデータシートの指示に従ってWRENを送信してください。 SFARには、メモリマップされたCPUアドレスではなく、外部FRAMオフセットを書き込みます。 TBDRを介して、書き込みデータ全体をTX FIFOにロードします。 書き込みLUTシーケンスIDとIDATASZを使用してIPCRを書き込みます。 QuadSPIモジュールがアイドル状態になり、IPトランザクションが完了するまでお待ちください。 示されている例では、IDATASZは8ですが、TBDRには1つのバッファ要素しかロードされていません。8バイトすべてをロードして8バイトのトランザクションを1回実行するか、IDATASZを1に設定して1バイトのトランザクションを実行するかのいずれかを選択してください。最初の選択肢の方が望ましい。SFARは各ブロックごとに前倒しで算出する必要がある。WRENは、FRAMデータシートの要件に従って、書き込みトランザクション全体ごとに処理されるべきであり、個々のバイトをロードする際に意図せず繰り返されるべきではない。 IP読み出しの場合、FRAMオフセットをSFARに書き込み、IPCRを介して読み出しシーケンスを開始し、RXバッファから結果を読み出します。通常のリードでは、AHB方法の方がシンプルで効率的です。 LUTはCY15B102QSNプロトコルに準拠している必要があります。具体的には、シングルパッドのコマンド、アドレス、データフェーズ、および正しいアドレス幅が必要です。このFRAMに適用可能でない限り、NORフラッシュの消去やWIP処理を追加しないでください。FRDM-A-S32K344用のQspi_Ip_Example_S32K344およびQSPIフラッシュメモリ読み書きデモは出発点として使用できますが、それらのNRフラッシュLUTコマンドやステータス処理はFRAMに適応する必要があります。 Re: S32K344 QuadSPI to external NVM Memory ご回答ありがとうございます。 関連する質問ですが、IPアドレスの書き込みと読み込みに関する新しい質問です。FRAMにRDIDオペコード（8バイトのデバイスIDを読み出す）を送信すると、期待されるバイトとは逆のバイトが返ってきます。S32K344 QuadSPI MCRレジスタの設定を実験しています。予約ビットがバイト順序に影響を与えるようです。これは参考文献には記載されていません。マニュアル。特にMCR[ビット3、2]はRXバイト順序に影響します。送信バイト順序に影響を与える予約ビットは他にありますか？他の予約された部分が何をするのか教えてもらえますか? Re: S32K344 QuadSPI to external NVM Memory QuadSPI MCRレジスタ内の予約ビットの機能は文書化されていないため、MCR[3:2]が内部で制御するものや、他の予約ビットがTXバイト順序に影響を与えるかどうかは確認できません。 予約ビットはモジュールの設定に使用してはならず、文書に記載されている値またはリセット値のままにしておく必要があります。したがって、これらのビットを変更した際に観察されるいかなる動作も、サポートされているQuadSPI構成として信頼すべきではありません。

I.MX95 Neutron NPU - ONNX 运行时 EP 我目前正在使用 Neutron NPU 和 ONNX Runtime，在尝试运行量化 INT8 模型时遇到了一个问题。我想详细介绍一下我的工作流程和问题，希望有人能提供指导。 遵循的步骤： 使用 QDQ 格式将模型量化到 INT8 我采用了最初的 FP32 ONNX 模型，并使用 QDQ（量化-去量化）方法对 INT8 进行量化。 我用 ONNX 工具验证了量化模型，以确保所有支持的运算符都被正确量化。 设置 ONNX 运行时 我的系统已安装 ONNX Runtime 1.22.0。 在 /usr/lib 中找到的库：   libonnxruntime.so.1 libonnxruntime.so.1.22.0   我没有单独的 libonnxruntime_neutron.so 或类似文件，它与 Neutron NPU 执行提供程序相对应。 尝试在 Neutron NPU 上运行模型 我尝试在 Python 中初始化一个 InferenceSession，并将提供程序设置为 ['NeutronExecutionProvider', 'CPUExecutionProvider']。     观察到的行为 尽管指定了 Neutron EP，运行时仍将所有操作委托给 CPU。 未观察到 NPU 加速，表明 Neutron Execution Provider 不可用或未加载。 我知道 ONNX Runtime 需要一个特定的 Neutron NPU EP (.so) 来委托 NPU 执行。 我目前安装的系统只有通用的 ONNX Runtime 库（libonnxruntime.so.*），不包括 Neutron 专用的 Execution Provider。 我已经查看了恩智浦软件开发工具包和GitHub仓库，但我不确定是否提供了预建的EP库，或者我是否需要编译支持Neutron的ONNX运行时。 为明确我们的路线图和发展规划，请恩智浦确认以下内容： 支持状态： 是否有官方计划在未来的 电路板支持包 版本中将 ONNX 运行库与 i.MX 95 平台的 Neutron NPU 执行提供商 (Neutron EP) 一起纳入 与 QDQ INT8 兼容： 作为该版本的一部分，Neutron EP 是否支持 INT8 QDQ 量化模型，还是存在已知的局限性？ 感谢您的支持 Re: I.MX95 Neutron NPU - ONNX runtime EP 你好@ACasCen、 感谢您联系恩智浦支持中心。 根据我们的《i.MX 机器学习用户指南》，ONNX Runtime Execution Provider for Neutron（Neutron EP）仍是一项实验功能，仅支持有限的操作员子集，主要是 CNN 类型的工作负载和一些量化的 LLM 内核。这意味着许多 ONNX 模型无法完全卸载到 Neutron NPU，可能会回到 CPU 执行。 出于这个原因，为了确保在 Neutron NPU 上稳定执行，我们强烈建议将您的模型转换为 TensorFlow Lite，然后使用 eIQ 工具包中包含的中子变流器进行转换。TFLite 模型，特别是量化 INT8，是使用 Neutron Delegate 在 Neutron-S NPU 上实现全面加速的官方支持和验证路径。 建议的工作流程 将模型转换为 TFLite（最好是 INT8）。 通过中子变流器（eIQ 工具包）运行模型。 使用 Neutron 委托进行部署： --external_delegate_path=/usr/lib/libneutron_delegate.so 使用 tfLITE/Neutron 分析工具验证操作员的兼容性和性能。 这种方法确保了 Neutron NPU 的最高可靠性和硬件覆盖率。 最崇高的敬意， Chavira Re: I.MX95 Neutron NPU - ONNX runtime EP 你好@ACasCen、 目前，官方还没有计划在 NPU 上支持 ONNX 型号。不过，eIQ 工具包提供的工具允许您将 ONNX 模型转换为 TFLite，并在 i.MX95 的 NPU 上运行。 Re: I.MX95 Neutron NPU - ONNX runtime EP 非常感谢@Chavira的支持，非常感谢！！因此，目前没有计划或预计发布的 电路板支持包 版本将包括对使用 ONNX Runtime 的模型的官方支持，对吗？ 谢谢，祝您一切顺利、 亚历杭德罗 Re: I.MX95 Neutron NPU - ONNX runtime EP 标题：[FRDM-i.MX95] ONNX 运行时 1.24.3选择 Neutron 执行提供程序时发生段错误 您好，NXP支持团队， 我正在使用 FRDM-i.MX95 开发板，并尝试使用 Neutron NPU 运行 ONNX 模型。 系统信息： 开发板：NXP FRDM-i.MX95 BSP：LF6.18.37_2.1.0 内核版本：6.18.37-2.1.0 ONNX 运行时：1.24.3 建筑：AArch64 Neutron 设备： /dev/neutron0存在 Neutron固件： NeutronFirmware.elf文件存在 问题： ONNX 运行时与 CPU 执行提供程序配合使用正常。 但是，选择 Neutron 执行提供程序会导致立即出现段错误。 即使不提供模型，也会出现此问题。 重现步骤： cd /usr/bin/onnxruntime-1.24.3 ./onnxruntime_perf_test -e neutron 结果： Segmentation fault (core dumped) 我还测试了一个 ONNX 模型： ./onnxruntime_perf_test \ -e neutron \ -I \ -m times \ -r 10 \ tests/testdata/matmul_integer_to_float_int8_bias.onnx 这会产生同样的段错误。 使用-e cpu成功运行该模型。 GDB 回溯信息： Program received signal SIGSEGV, Segmentation fault. #0 __GI_strcmp () at ../sysdeps/aarch64/strcmp.S:76 #1 0x0000aaaaaaac58f8 in ?? () #2 0x0000aaaaaaacf468 in ?? () #3 0x0000aaaaaaac056c in ?? () 问题： 这是 电路板支持包。 LF6.18.37_2.1.0 中 ONNX Runtime 1.24.3 的已知问题吗？ Neutron 执行提供程序是否需要与此 电路板支持包。 中的onnxruntime_perf_test配合使用？ 是否需要特定的设备树、固件配置或其他初始化步骤？ 能否提供一个经过验证的适用于 FRDM-i.MX95 的 Neutron NPU 演示程序，并使用此 电路板支持包。 版本？ 我们的目标是验证 Neutron NPU 推理，随后在板上运行量化语言模型。 感谢您的支持。

I.MX95 Neutron NPU - ONNX runtime EP I am currently working with the Neutron NPU and ONNX Runtime, and I am encountering an issue when trying to run a quantized INT8 model. I would like to share my workflow and the problem in detail, in case anyone can provide guidance. Steps Followed: Model Quantization to INT8 using QDQ format I took my original FP32 ONNX model and applied quantization using the QDQ (Quantize-DeQuantize) approach to INT8. I verified the quantized model with ONNX tools to ensure that all supported operators were correctly quantized. Setting up ONNX Runtime ONNX Runtime 1.22.0 is installed on my system. Libraries found in /usr/lib:   libonnxruntime.so.1 libonnxruntime.so.1.22.0   I did not have a separate libonnxruntime_neutron.so or similar, which would correspond to the Neutron NPU Execution Provider. Attempting to Run the Model on Neutron NPU I attempted to initialize an InferenceSession in Python with the providers set as ['NeutronExecutionProvider', 'CPUExecutionProvider'].     Observed Behavior Despite specifying the Neutron EP, the runtime delegates all operations to the CPU. No NPU acceleration is observed, indicating that the Neutron Execution Provider is either not available or not being loaded. I understand that ONNX Runtime needs a specific Neutron NPU EP (.so) to delegate execution to the NPU. My current installation only has the generic ONNX Runtime libraries (libonnxruntime.so.*) and does not include the Neutron-specific Execution Provider. I have checked the NXP SDK and GitHub repos, but I am not certain whether prebuilt EP libraries are provided or if I need to compile ONNX Runtime with Neutron support. To clarify our roadmap and development planning, could NXP please confirm the following: Support Status: Is there an official plan to include ONNX Runtime libraries with the Neutron NPU Execution Provider (Neutron EP) for the i.MX95 platform in a future BSP release Compatibility with QDQ INT8: Will the Neutron EP support INT8 QDQ quantized models as part of that release, or are there known limitations? Thank you in advance for your support!! Re: I.MX95 Neutron NPU - ONNX runtime EP Hi @ACasCen, Thank you for reaching out to NXP Support. According to our i.MX Machine Learning User’s Guide, the ONNX Runtime Execution Provider for Neutron (Neutron EP) is still an experimental feature and supports only a limited subset of operators, primarily CNN‑type workloads and some quantized LLM kernels. This means that many ONNX models cannot be fully offloaded to the Neutron NPU and may fall back to CPU execution. For this reason, and to ensure stable execution on the Neutron NPU, we strongly recommend converting your model to TensorFlow Lite and then converting it with the Neutron converter included in the eIQ Toolkit. TFLite models especially quantized INT8 are the officially supported and validated path to achieve full acceleration on the Neutron‑S NPU using the Neutron Delegate. Recommended workflow Convert your model to TFLite (preferably INT8). Run the model through the Neutron converter (eIQ Toolkit). Deploy using the Neutron Delegate: --external_delegate_path=/usr/lib/libneutron_delegate.so Verify operator compatibility and performance using the TFLite/Neutron profiling tools. This approach ensures the highest reliability and hardware coverage on the Neutron NPU. Best regards, Chavira Re: I.MX95 Neutron NPU - ONNX runtime EP Thank a lot for your suuport @Chavira , appreciate it!! So, there is currently no planned or estimated BSP release that will include official support for models using ONNX Runtime, correct? Thanks, best regatds, Alejandro Re: I.MX95 Neutron NPU - ONNX runtime EP Hi @ACasCen, At the moment, there are no official plans to support ONNX models on the NPU. However, the eIQ Toolkit provides tools that allow you to convert your ONNX model to TFLite and run it on the NPU of the i.MX95. Re: I.MX95 Neutron NPU - ONNX runtime EP Title: [FRDM-i.MX95] ONNX Runtime 1.24.3 Segmentation Fault When Selecting Neutron Execution Provider Hello NXP Support Team, I am working with the FRDM-i.MX95 development board and trying to run ONNX models using the Neutron NPU. System Information: Board: NXP FRDM-i.MX95 BSP: LF6.18.37_2.1.0 Kernel: 6.18.37-2.1.0 ONNX Runtime: 1.24.3 Architecture: AArch64 Neutron device: /dev/neutron0 is present Neutron firmware: NeutronFirmware.elf is present Problem: ONNX Runtime works correctly with the CPU Execution Provider. However, selecting the Neutron Execution Provider causes an immediate segmentation fault. The issue occurs even when no model is provided. Steps to Reproduce: cd /usr/bin/onnxruntime-1.24.3 ./onnxruntime_perf_test -e neutron Result: Segmentation fault (core dumped) I also tested an ONNX model: ./onnxruntime_perf_test \ -e neutron \ -I \ -m times \ -r 10 \ tests/testdata/matmul_integer_to_float_int8_bias.onnx This produces the same segmentation fault. The model runs successfully using -e cpu. GDB Backtrace: Program received signal SIGSEGV, Segmentation fault. #0 __GI_strcmp () at ../sysdeps/aarch64/strcmp.S:76 #1 0x0000aaaaaaac58f8 in ?? () #2 0x0000aaaaaaacf468 in ?? () #3 0x0000aaaaaaac056c in ?? () Questions: Is this a known issue with ONNX Runtime 1.24.3 in BSP LF6.18.37_2.1.0? Is the Neutron Execution Provider expected to work with onnxruntime_perf_test in this BSP? Is a specific device tree, firmware configuration, or additional initialization required? Could you provide a validated Neutron NPU demo for the FRDM-i.MX95 with this BSP version? Our goal is to validate Neutron NPU inference and subsequently run a quantized language model on the board. Thank you for your support.

S32K344 QuadSPI 至外部 NVM 存储器 我正在使用 QuadSPI 模块与外部 FRAM NVM 设备 CY15B102QSN 进行通信。为了简单起见，我目前使用单 SPI 模式来使用该设备和模块。 我创建了用于读写内存的例程和 LUT 序列来支持读写操作。我的问题是，这些函数和查找表序列的流程应该是什么。 s32k344 参考。手册在这方面写得不太清楚。 要对NVM进行读写访问，我需要写入S32K344上的哪些寄存器？如果能提供一个很好的NXP驱动程序示例，那就太好了。 阅读并编写以下示例函数。 // 读取序列 =============================================== 我使用 BFGENCR 寄存器来指定 READ命令中的 LUT 序列。 然后使用 C 语句将内存地址读取到一个变量中。 // 示例 sudo 代码 /* AHB 读取四路操作*/ for(unit32 i=0; i < buf_size; ++i)         { /* 将 AHB 读取的 LUT 序列 ID 值写入 BFGENCR[SEQID]。*/ quad_base_addr->BFGENCR = (quad_base_addr->BFGENCR & ~QuadSPI_BFGENCR_SEQID_MASK) | QuadSPI_BFGENCR_SEQID(qspi_lut_seq_read_memory); /* 获取下一个数据元素 */ buffer[i] = *(volatile U8_T *)(mem_addr[i]);         } // 写入序列 ============================================== 我不清楚是否可以使用 BFGENCR 寄存器来指定写入命令中的 LUT 序列。 或者说，因为我像在寄存器写入时一样使用 SFAR 和 IPCR。 // 使用 SFAR 和 IPCR 的示例 sudo 代码 for(unint32 i=0; i < buf_size; ++i)         {             /* 写入 WREN 命令以启用对 FRAM 的写入 */ cy15_write_opcode_wren(quad_base_addr, qspi_lut_seq_wren_opcode);             if(G_FALSE == qspi_is_tx_full(quad_base_addr)){     /** 将串行闪存地址寄存器 (SFAR) 加载内存地址 */ quad_base_addr->SFAR = mem_addr;         /* 在触发序列之前，将数据写入 TX FIFO。*/ quad_base_addr->TBDR = buffer[i];         /** 设置 IPCR，序列 ID = (1) 用于写入，IDATASZ = 8 字节 * 序列由此开始。*/ quad_base_addr->IPCR  = QuadSPI_IPCR_SEQID(1) | QuadSPI_IPCR_IDATSZ(8);         /* 等待操作完成再返回。*/                 if( G_FALSE == qspi_wait_for_idle(quad_base_addr)){ ret_val = QSPI_TIMEOUT_BUSY; }         }     } // 或者使用与读取操作更相似的操作 ======================= /* AHB 写入四元组操作 */ for(i=0; i < buf_size; ++i)         {             /* 将 AHB 写入的 LUT 序列 ID 值写入 BFGENCR[SEQID]。*/ quad_base_addr->BFGENCR = (quad_base_addr->BFGENCR & ~QuadSPI_BFGENCR_SEQID_MASK) | QuadSPI_BFGENCR_SEQID(qspi_lut_seq_write_memory); /* 获取下一个数据元素 */ *(volatile U8_T *)(mem_addr[i]) = buffer[i];     } Re: S32K344 QuadSPI to external NVM Memory 您的 AHB 读取流程原则上是正确的，但需要在读取循环之前配置一次 BFGENCR[SEQID]，而不是每个字节都配置一次。例如，从 QSPI AHB 窗口读取 QSPI 基地址加上 FRAM 偏移量。如果 mem_addr 是基地址，则使用基地址加上当前偏移量，而不是 mem_addr[i]。 S32K344 不支持 AHB 写入访问。因此，不要使用 BFGENCR 后跟指针写入。通过 IP 命令写入 FRAM： 按照 CY15B102QSN 数据表的要求发送 WREN。 将外部 FRAM 偏移量（而不是内存映射的 CPU 地址）写入 SFAR。 通过 TBDR 将完整的写入数据加载到 TX FIFO 中。 使用写入 LUT 序列 ID 和 IDATASZ 写入 IPCR。 等待 QuadSPI 模块空闲且 IP 事务完成。 在所示示例中，IDATASZ 为 8，但只有一个缓冲区元素加载到 TBDR 中。要么加载全部 8 个字节并执行一个 8 字节的事务，要么使用 IDATASZ 等于 1 来执行一个字节的事务。第一个方案更可取。SFAR 也必须针对每个模块进行升级。WREN 应按照 FRAM 数据手册的要求，在每个完整的写入事务中处理，而不是在加载单个字节时无意中重复处理。 对于 IP 读取，将 FRAM 偏移量写入 SFAR，通过 IPCR 开始读取序列，并从 RX 缓冲区读取结果。对于普通读取，AHB 方法更简单、更高效。 LUT 必须与 CY15B102QSN 协议匹配：单焊盘命令、地址和数据阶段，以及正确的地址宽度。除非适用于此 FRAM，否则请勿添加 或非-Flash 擦除或 WIP 处理。Qspi_Ip_Example_S32K344 和 FRDM-A-S32K344 的 QSPI Flash Memory Read/Write demo 可以作为起点，但它们的 或非-Flash LUT 命令和状态处理必须针对 FRAM 进行调整。 Re: S32K344 QuadSPI to external NVM Memory 谢谢你的回复。 相关但又新的问题，一般是关于 IP 写入和读取的。当我向 FRAM 发送 RDID 操作码（读取 8 字节设备 ID）时，我得到的响应与预期的字节顺序相反。尝试调整 S32K344 QuadSPI MCR 寄存器设置。看来保留位会影响字节顺序。参考文献中没有相关记录。手册中特别提到，MCR[位 3,2]会影响 RX 字节顺序。还有其他保留位会影响发送字节顺序吗？您能解释一下其他保留部分的作用吗？ Re: S32K344 QuadSPI to external NVM Memory QuadSPI MCR 寄存器中保留位的功能没有文档说明，因此我无法确认 MCR[3:2] 内部控制什么，或者其他保留位是否会影响 TX 字节顺序。 保留位不应用于配置模块，应保持其文档中规定的/RESET 值。因此，更改这些位时观察到的任何行为都不应被视为受支持的 QuadSPI 配置。

S32K344 QuadSPI to external NVM Memory I am using the QuadSPI module to communicate to an external FRAM NVM device, CY15B102QSN. I am using the device and module in single SPI mode to keep it simple for now. I created a routines to read and write to memory and LUT Sequences to support the read and writes. My trouble is in what the flow should be in these functions and the LUT Sequences. The s32k344 ref. Manual is not very clear on this. Which registers do I need to write to on the s32k344 to initiate a read and write access to the NVM?  If there is a good NXP driver example available that would be helpful. Read and write example functions below. // read sequence ============================================= I am using the BFGENCR register to specify the LUT sequence on a Read command then using a C statement to read the memory address into a variable. // example sudo code /* AHB read quad operation*/         for(unit32 i=0; i < buf_size; ++i)         {             /*  write the BFGENCR[SEQID] with the value of LUT Seq id for AHB reading. */             quad_base_addr->BFGENCR = (quad_base_addr->BFGENCR &  ~QuadSPI_BFGENCR_SEQID_MASK) |  QuadSPI_BFGENCR_SEQID(qspi_lut_seq_read_memory);             /* get the next data element */ buffer[i] = *(volatile U8_T *)(mem_addr[i]);         } // write sequence =========================================== It is not clear to me if I sue the BFGENCR register to specify the LUT sequence on a write command  or due I use SFAR and IPCR as I do on register writes. // Example sudo code using  SFAR and IPCR        for(unint32 i=0; i < buf_size; ++i)         {                         /* write WREN command to enable writing to FRAM */             cy15_write_opcode_wren(quad_base_addr, qspi_lut_seq_wren_opcode);             if(G_FALSE == qspi_is_tx_full(quad_base_addr)){                     /**  load Serial Flash Address Register (SFAR) with address of memory*/                 quad_base_addr->SFAR = mem_addr;                          /* write data to the TX FIFO before triggering the sequence. */                 quad_base_addr->TBDR = buffer[i];                         /** set IPCR with sequence id = (1)for write, IDATASZ = 8 bytes                  * This starts the sequence.  */                                quad_base_addr->IPCR  = QuadSPI_IPCR_SEQID(1) | QuadSPI_IPCR_IDATSZ(8);                         /* wait for operation to complete before returning. */                 if( G_FALSE == qspi_wait_for_idle(quad_base_addr)){                     ret_val = QSPI_TIMEOUT_BUSY;                 }            }     } // OR use the more similar to the read operation =======================  /* AHB write quad operation*/        for(i=0; i < buf_size; ++i)         {                         /*  write the BFGENCR[SEQID] with the value of LUT Seq id for AHB writing. */             quad_base_addr->BFGENCR = (quad_base_addr->BFGENCR & ~QuadSPI_BFGENCR_SEQID_MASK) |  QuadSPI_BFGENCR_SEQID(qspi_lut_seq_write_memory);             /* get the next data element */ *(volatile U8_T *)(mem_addr[i]) = buffer[i];     } Re: S32K344 QuadSPI to external NVM Memory Your AHB read flow is correct in principle, but configure BFGENCR[SEQID] once before the read loop, not for every byte. Read from the QSPI AHB window, for example the QSPI base address plus the FRAM offset. If mem_addr is a base address, use the base address plus the current offset rather than mem_addr[i]. AHB write access is not supported on the S32K344. Therefore, do not use BFGENCR followed by a pointer write. Write the FRAM through an IP command: Send WREN as required by the CY15B102QSN data sheet. Write the external FRAM offset, not the memory-mapped CPU address, to SFAR. Load the complete write data into the TX FIFO through TBDR. Write IPCR with the write LUT sequence ID and IDATASZ. Wait until the QuadSPI module is idle and the IP transaction is complete. In the shown example, IDATASZ is 8 but only one buffer element is loaded into TBDR. Either load all 8 bytes and execute one 8-byte transaction, or use IDATASZ equal to 1 for a one-byte transaction. The first option is preferable. SFAR must also be advanced for each block. WREN should be handled per complete write transaction as required by the FRAM data sheet, not repeated unintentionally while loading individual bytes. For an IP read, write the FRAM offset to SFAR, start the read sequence through IPCR, and read the result from the RX buffer. For normal reads, the AHB method is simpler and more efficient. The LUT must match the CY15B102QSN protocol: single-pad command, address, and data phases, with the correct address width. Do not add NOR-Flash erase or WIP handling unless applicable to this FRAM. The Qspi_Ip_Example_S32K344 and QSPI Flash Memory Read/Write demo for FRDM-A-S32K344 can be used as starting points, but their NOR-Flash LUT commands and status handling must be adapted for the FRAM. Re: S32K344 QuadSPI to external NVM Memory Thank you for that response. Related but new question, generally on IP write and read. When I send the RDID opcode to the FRAM (read back 8-byte device ID) the response I get is byte reversed from what is expected. Experimenting with the S32K344 QuadSPI MCR register settings. it seems the reserved bits affect the byte order. This is not documented in the Ref. Manual. in particular the MCR[bits 3,2] affect the RX byte order. Are there other reserved Bits that affect TX Byte Order? Can you shed any light on what the other reserved bits do? Re: S32K344 QuadSPI to external NVM Memory The functionality of the reserved bits in the QuadSPI MCR register is not documented, so I cannot confirm what MCR[3:2] internally control or whether other reserved bits could affect the TX byte order. Reserved bits should not be used to configure the module and should be kept at their documented/reset values. Any behavior observed when changing these bits should therefore not be relied upon as a supported QuadSPI configuration.

S32k144 ADC example code (RTD Non Autosar) - Not working / Build error Hi, I am using the existing Pdb_Adc example from the RTD Non-AUTOSAR driver. After configuring the ADC channel in the peripheral configuration tools and attempting to build, I encountered a compilation error regarding a missing header file:   ../board/Port_Ci_Port_Ip_Cfg.h:47:10: fatal error: Port_Ci_Port_Ip_Types.h: No such file or directory It seems the code generation or include paths for the Port driver are incomplete. Could   S32K1  #ADC  Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error Hi @VaneB , Thanks for your reply, yes it works as you suggested.  Now the error cleared the code uploaded, but the ADC value is not changing depends on the pot position in the S32k144 Eval board. Do I need to add any function or capture the data. Kindly guide me for the solution. Also, I have attached the main function file for your reference., Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error Hi @Buddyn  In the original demo, no pins are configured using the Pins Tool, so there was no need to add the Port_Ip driver in the Peripherals Tool. However, since you are now configuring an ADC pin, you need to add the Port_Ip driver. You also need to change the Pins Tool Functional Group name to PortContainer_0_VS_0, which corresponds to: PortContainer name from the Port_Ip driver + "_" + Peripherals Functional Group name You can modify the name in the window shown in the following image: BR, VaneB Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error Hi @Buddyn  Did you only modify the part I previously mentioned for the Port_Ip driver and the Functional Group Name? I noticed that, in the project you shared, ADC0_SE12 is configured as an output. It needs to be configured as an input to read the ADC value. I also recommend taking a look at the S32M24x/S32K1 – FTM/TRGMUX/PDB/ADC – [RTD300] thread. It provides an example of a more complex application. The example uses the potentiometer on the S32K144EVB-Q100, but the implementation could still be helpful as a reference for your application.

S32K144 RTD 3.0.0：S32DS 配置工具和 EB Treso 之间的区别 你好，   S32K144、S32 Design Studio 3.6.0、RTD SW32K1_S32M24x_RTD_R21-11_3.0.0_D2503、EB tresos Studio 29.0.0。仅限高级 AUTOSAR 驱动程序。   在 EB Tresos 中，端口和 MCU 需要手动填写。在 S32 配置工具中，引脚和时钟与相应的驱动程序一起使用。在 S32DS Dio 示例中，引脚在“引脚”中配置，然后使用 PortPinPcr 添加到“端口”中。方向和相关字段从“引脚”中获取。时钟树在“时钟”中配置，MCU 仅通过名称引用该配置。   按照这种方式使用引脚和时钟之后，还需要在端口、MCU 或任何相关模块中配置什么？ 对于其他高级驱动程序，其配置项和生成结果是否与 EB tresos 中的相同？ 除了引脚和端口、时钟和MCU之外，还有哪些地方的配置行为与EB Tresos不同？ Re: S32K144 RTD 3.0.0: differences between S32DS Configuration Tools and EB tresos 嗨@Julián_AragónM ， 感谢您详细清晰的解释！很高兴得知 HLD (MCAL) 生成的代码完全相同，主要区别仅在于配置格式。 由于我的项目是一个裸机设置，完全专注于 MCAL 和我自己定制的 BSW，我将严格遵循 EB Tresos 工作流程，并且仅使用 S32DS 进行编译。 “一切都在按计划进行。”（计画门） 再次感谢你的帮助！ 此致， 超凡 Re: S32K144 RTD 3.0.0: differences between S32DS Configuration Tools and EB tresos 你好@chaofan ， S32DS 提供编辑设备配置的视角，主要包括引脚、时钟、外设、DCD（设备配置数据）、IVT（映像矢量表）、QuadSPI、eFUSE、ICE、GTM 等。 DDR。 但是，S32K1（和 S32K MCU）仅支持引脚、时钟和外设。您可以在“配置工具概览”中看到这一点： Config Tools OverviewConfig Tools Overview配置工具概述 S32DS 和 EB Tresos 之间生成的所有高级驱动程序 (HLD) 文件都是相同的。这两个工具的主要区别在于，EB Tresos 使用 AUTOSAR 格式（例如 AUTOSAR schema XML 格式），而 S32DS 使用 .mex 文件。虽然该文件不符合ASR模式格式，但通过此接口对NXP设备进行编程更加容易。 此致， 朱利安 Re: S32K144 RTD 3.0.0: differences between S32DS Configuration Tools and EB tresos 嗨@chaofan ， 没问题，祝你好运！ 此致， 朱利安

ICのCOD 以下の部品のCOD（ウェハー位置）を確認するのを手伝ってください。 PCA82C251T/YM、118 PCA9547PW、118

i.MX95 Android 15:88W8987 Bluetooth UARTタイムアウトと共有クロックストラップ/UART RXピンの問題 親愛なるNXPサポートチームへ、 Weidongの勧告に従い、i.MX95プラットフォームでBluetooth導入の新規チケットを開設します。Wi-Fiは正常に動作するようになりましたが、リセット中に正しい基準クロックを選択したまま、Bluetooth UART通信を復旧させる方法についてご教示いただく必要があります。 1. ハードウェアおよびソフトウェア構成 ホストボード：NXP i.MX95 19×19 EVK、B0 無線モジュール:u-blox JODY-W263-00B、88W8987をベースに、M.2 Key-Eを介してコネクテッド BSP:オートモーティブAndroid 15.0.0_2.1.0 カーネル: 6.12.23 Wi-Fiインターフェース:SDIOからuSDHC3まで Bluetoothインターフェース:LPUART5、/dev/ttyLP4として公開されています Wi-Fiドライバー: オートモーティブ-15.0.0_2.1.0のNXP mwifiex、リリース537.p9 ファームウェア: 対応するAndroid BSPファームウェアリポジトリからsduart8987_combo.bin ファームウェアバージョン：16.92.21.p151.4 ファームウェアサイズ：628,200バイト 推奨されているSDIO + UART構成を引き続き採用する予定です。 2. Wi-Fiの起動失敗とスイッチの観察 以前は、モジュールはSDIO経由で検出され、ファームウェアの転送は完了しましたが、ファームウェアのアクティベーションが以下のエラーで失敗しました。 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! 調査の結果、NXPは、88W8987 GPIO[8]/UART_SOUTがリセット時にサンプリングされ、基準クロックが選択されていると報告した。 低周波数: 38.4 MHz HIGH: 26 MHz この信号は、通常動作時にはBluetooth UART TX出力としても機能し、ホストのLPUART5 RX入力に接続されます。 当社のEVKにおける関連接続は次のとおりです。 Module Bluetooth TX → M.2 J24 pin 22 → R607 → BT_UART5_RXD → R17 → SW1 contacts 7–8 → host LPUART5 RX 我々が繰り返し観察した結果は以下のとおりです。 コールドブート中にSW1が7–8オンに接続:Wi-Fiファームウェアのアクティベートが0xf005で失敗します。 SW1がコールドブート中に7–8のOFFに接触: Wi-Fiは正常に初期化され、動作します。 また、推奨されたホストRXパッドのプルダウン構成についてもテストしました。 IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e しかし、以前のテストではSW1接点7–8オンの故障は解決しませんでした。その後抽出した実行中のデバイスツリーにはRXパッドの設定 が示0x31eため、完全な構成方法と起動・リセット時にいつ発効するかについてのガイダンスをいただけるとありがたいです。 3. Wi-Fi設定は正常に動作しているが、Bluetoothが故障する SW1の接点を7〜8オフにするとWi-Fiは動作しますが、同時にモジュールのBluetooth TXがホストUART RXから切断されます。したがって、ホストがコントローラの応答を受け取れないため、Bluetoothの初期化が失敗すると予想されます。 BluetoothはADBでテストされます。基板にはコネクテッドディスプレイがないためです。 インストールされているベンダー構成は以下のとおりです。 mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 ベンダーライブラリはデフォルトbaudrate_btで 3000000です。UARTファームウェアのダウンロードはデフォルトで無効化されています。現在の構成はWi-Fiドライバを通じて読み込まれたコンボファームウェアに依存しています。 BluetoothベンダーのHALはバージョン009.030を報告し、UARTデバイスを正常に開きました。 bt_vnd_init --- BT Vendor HAL Ver: 009.030 --- mchar_port set to /dev/ttyLP4 baudrate_fw_init is set to 3000000 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 しかし、BluetoothスタックはBLE_TURNING_ON状態のままになり、最終的に異常終了します。 Can't start stack, last instance: starting HciHal クローズ/リカバリ中、ベンダーライブラリは以下の情報も報告します。 Read hci complete event failed timed out Failed to read HCI RESET CMD response! ソース構成シーケンスは、HCIリセットコマンドから始まります。UARTデバイスの起動は成功しましたが、コントローラとの通信は成功していません。 4. 指導要請 以下の点についてアドバイスいただけますか? この共有クロック設定/Bluetooth UART信号はi.MX95上でどのように扱うべきでしょうか? 38.4 MHz選択時にはリセット時にモジュールTX/ホストRXラインをLOWにし、通常動作時にはコネクテッドされた機能するUART受信パスが必要です。 SW1の接点7〜8とLPUART5 RXパッドの推奨構成は何ですか? スイッチは特定のパッド構成でオンのままでいるべきでしょうか、それとも基板レベルの追加の変更が必要ですか? プルダウンはどのブート段階で適用すべきですか? Linuxのデバイスツリー設定で十分でしょうか?それともモジュールリセットが解放される前にU-Boot、System マネージャ/SCMIピン制御、または他の初期化段階でこのパッドを設定する必要がありますか? クロックサンプリングとそれに続くUART動作が正しく行われるように、推奨される電源投入/リセットおよびピン制御シーケンス（W_DISABLE2#/Bluetooth有効化の必要な処理を含む）を提供してください。 BSPが提供するsduart8987_combo.binのBluetooth設定を確認してください。具体的には、初期UARTボーレート、動作ボーレート、RTS/CTSフロー制御、および必要なウェイク/スリープ設定やベンダー設定エントリなどを確認してください。 このBSP上で、88W8987モジュール用の検証済みDTS/パッチおよびBluetoothベンダー構成はありますか？もしあれば、検証に使用した参照構成とモジュール部品番号を教えてください。 SDIO-SDIOの代替案も調査しましたが、Weidongによると、これらの専門パッケージは時代遅れでカーネルのアップグレードに追いついていないとのことです。このターゲット上でSDSDファームウェアの検証は行っておらず、標準のSDIO + UARTアーキテクチャを使用して問題を解決したいと考えています。 リセットおよびBluetooth初期化時に共有されたストラップ/UARTラインの完全なBluetoothログ、動作装置ツリー、回路図抜粋、オシロスコープ測定などを提供できます。どの測定ポイントと測定タイミング条件が最も有用か教えてください。 Wi-Fiの有効化を引き続きサポートいただき、ありがとうございます。動作中のWi-Fi設定を維持したまま、Bluetoothの起動を完了させるためのご指導をいただければ幸いです。 よろしくお願いします、 ラケシュ・クマール・タクール Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue @Rakesh_Kumar_Thakur様、 変更してください baudrate_fw_init = 3000000 ～ baudrate_fw_init = 115200 それでは、試してみてください。 ありがとうございます よろしくお願いいたします。 魏東 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 件名：i.MX95 / JODY-W263：ボーレートテスト結果と、手動SW1切り替えなしの恒久的な解決策のリクエスト 親愛なる魏東様 サポートありがとうございます。baudrate_fw_initを3000000 から115200に変更するという推奨をテストしました。以下に結果と残りの起動時間の問題を示します。 来週の統合活動のために恒久的な解決策が必要なので、必要な構成やパッチについてのご指導をいただけるとありがたいです。 プラットフォーム ボード: NXP i.MX95 19×19 EVK、B0 モジュール: u-blox JODY-W263-00B / 88W8987、M.2 Key-E BSP:オートモーティブAndroid 15.0.0_2.1.0 カーネル: 6.12.23 BluetoothベンダーHAL: 009.030 Wi-Fiインターフェース:SDIOからuSDHC3まで Bluetoothインターフェース:UART5、 /dev/ttyLP4 ファームウェア: sduart8987_combo.bin 調査中のスイッチ: SW1、スイッチセクション4、接点7–8、ホスト側のBluetooth UART RX経路上。 1. SW1接点7–8オンのブート Wi-Fiファームウェアの有効化に失敗しました。 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! WLAN: Fail download FW with nowwait: 0 Bluetoothもオン状態になりません。 推奨されているLinux RXパッドの構成を適用しました: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 実行中のデバイスツリーを抽出し、この値が存在し、有効化されたUART5ノードによって参照されていることを確認しました。しかし、スイッチオン時の起動問題は依然として残っています。 2. 初期化ボーレート3000000での動作シーケンス 以下の手順を実行することで、Wi-FiとBluetoothが動作します。 電源を入れる前に SW1の接点を7〜8度オフに保ち ましょう。 基板の電源を入れ、ファームウェアの初期化が完了するまで待ちます。 確認する： [12.738590] WLAN FW is active [12.954531] wlan: Driver loaded successfully Bluetoothを無効にして、 STATE_OFFであることを確認してください。 ボードが動いている状態で、物理的にSW1接点を7〜8のオンに回します。 Bluetoothを有効にする。 説明： baudrate_fw_init = 3000000 baudrate_bt = 3000000 我々は以下を得た： wait-for-state:STATE_ON: Success enabled: true state: ON Wi-FiはP3デバイスとコネクテッドのままで、IPアドレスは10.17.36.30、請求者の状態は完了、ネットワークステータスは検証済みでした。 Bluetoothスキャンやペアリングも、この手動スイッチシーケンスで以前は動作していました。最新の3M社による比較テストでは、Bluetoothのオン状態とWi-Fi接続が確認されました。 3. 推奨初期化ボーレート115200のテスト ベンダー/スーパーイメージと、それに対応するボード固有のAVBメタデータを再構築してフラッシュしました。 mchar_port = /dev/ttyLP4 baudrate_dl_image = 115200 iSecondBaudrate = 3000000 baudrate_fw_init = 115200 baudrate_bt = 3000000 展開された構成とHALログの両方で、 115200が使用されたことが確認されました。 同じ手順で、連絡先7–8をOFFで起動し、WLANファームウェアが有効か確認、Bluetoothを無効にし、お問い合わせ7–8を物理的にオンにしてからBluetoothを有効にしました。 Wi-Fiは引き続き動作したが、Bluetoothの初期化に失敗した。 baudrate_fw_init is set to 115200 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 Read hci complete event failed timed out. Total_duration = 1000 Failed to read HCI RESET CMD response! config_uart failed アダプタがSTATE_ON状態に達しませんでした。Bluetoothスタックの初期化に繰り返し失敗しました。 初期化時のボーレート設定のみを3000000に戻し、同じ実験的なブートローダーとカーネルを保持したままイメージを再構築したところ、Bluetoothは起動時にオフ→初期化後にオンという同じシーケンスを使用してオンになりました。 4. 追加の起動時実験 また、以下の項目もテストしました。 U-Bootの初期のpinctrl hogにRX 0x51eの設定を追加します。 実験的なSCMIのpinctrl-ドライバ変更により、ゼロオフセットDAP_TDIピンへの多解請求が含まれています。元のドライバ条件(mux_ofs)は、そのピンの多解消オフセットがゼロであるため、多解請求をスキップします。 これらの実験ではスイッチオンの起動失敗は解決しませんでした。初期シリアルログからは、設定がいつ適用されたのか、あるいはSCMIリクエストが成功したのかはまだ確認できていません。したがって、これらの変更は確実な解決策とは考えていません。 恒久的な解決策を求める 手動スイッチシーケンスはデバッグには有用ですが、通常の動作には適していません。Wi-FiとBluetoothが、電源オンおよび実行時の間、SW1のお問い合わせ7〜8をオンのままにして、ユーザーの介入なしに確実に初期化する必要があります。 これらの結果を確認し、以下の内容をご提供いただけますか: このコンボファームウェアを使用したJODY-W263 / 88W8987の正しい初期化ボーレートは、比較において115200が失敗し、3000000が成功したことを踏まえて決定しました。 初期化中に正しい GPIO[8]/UART_SOUT ストラップの状態を維持し、その後も UART の動作を維持するために必要なピン構成とモジュール電源/リセットシーケンス。 適切な実装場所は、システムマネージャー、SPL/U-Boot、Linux pinctrl/MMCの電源シーケンス、またはハードウェアの変更です。 必要なGPIO極性、リセットタイミング、ピン所有権の変更などを含め、当社のボード/BSP専用のパッチまたは検証済み構成。 また、SCMIのpinctrlドライバにおけるゼロオフセットマルチプレクサ処理がi.MX95向けに意図されているかどうかも確認してください。 成功ログと失敗ログの完全なファイル、デバイスツリーの実行、ソース差分、SW1の写真も提供可能です。追加の起動時トレースが必要な場合はお知らせください。 手作業による手順から、信頼性の高い恒久的な解決策へと移行するお手伝いをしていただき、ありがとうございました。 よろしくお願いします、 ラケシュ・クマール・タクール Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue @Rakesh_Kumar_Thakur様、 u-blox製のWi-Fi/Bluetoothモジュールでボーレートが固定されているかどうかをご確認ください。 固定ボーレートが115200の場合は、以下の設定を試してください。 mchar_port = /dev/ttyLP4 baudrate_fw_init = 115200 固定ボーレートが3000000の場合は、設定を使用します mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 それでは、試してみてください。 来週ならテストする時間が取れるだろう。まずは試してみてはどうでしょうか。 ところで、あなたの事業内容がよく理解できていないのですが。Wi-FiのオンオフはAndroid経由で簡単にできます。ボード上のSW1スイッチを操作する必要はありません。 ありがとうございます よろしくお願いいたします。 維東 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue @Rakesh_Kumar_Thakur様、 はい、わかりました。すみません、スイッチを無視しました。 はい、M.2でLPUART5を使用する場合は、SW1を介してすべてのLPUART5信号を有効にする必要があります。 LPUART5信号はこれらのJTAGパッドを介して多重化されるためです。 しかし、SW1はシステム起動には影響しません。 構成、 IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e Linuxデバイスツリーでのみ設定すればよい。 u-bootのデバイスツリーには不要です。 ありがとうございます よろしくお願いいたします。 魏東 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 親愛なる魏東様 ご返信いただき、また来週テストしていただけるとのこと、ありがとうございます。 u-blox JODY-W2システム統合マニュアル（UBX-18068879、改訂版R14） を確認しました 。 17ページには、デフォルトのUARTボーレートが3000000であると記載されています。 セクション2.4.2の29ページには、ファームウェアロード後のボーレートは3000000であり、専用のHCIボーレートコマンドで他のサポートレートを設定できると記載されています。 したがって、文書に記載されているデフォルト値は3Mであり、UARTがこの速度に恒久的に制限されているとは記載されていません。 私たちのテストは以下の構成もサポートしています: mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 baudrate_bt = 3000000 WLANファームウェアが有効でUARTパスが接続されている場合、 115200 での初期化が繰り返しタイムアウトし、HCIリセット応答を待ちました。 3000000 を復元することで、Bluetoothは有効(true、state:ON)に到達し、Wi-Fiはコネクテッドされたままでした。 また、物理的なスイッチの操作についても明確にしたいと思います。SW1ではWi-Fiのオン/オフを切り替えることはできません。 i.MX95 EVKベースボード回路図SPF-87753-B、シート4によれば、SW1セクション4、接点7–8を以下の経路で操作しています。 ホストJTAG_TDI/LPUART5_RX ↔ SW1がM.2に向かって7–8 ↔ R17(49.9 Ω)↔ BT_UART5_RXD接触。 ここで、R17は基板抵抗の基準です。これはu-blox文書のリビジョンR14とは別です。基板抵抗R14は異なるCTSチャネルに属します。 我々が観察した行動は以下のとおりです。 電源オン前の7–8のコンタクト:firmwarestat=0xf005でWLANファームウェアのアクティベーションが失敗します。 7–8の接点が電源オン前にOFF: WLANファームウェアが正常に初期化されました。 ファームウェア初期化後、連絡先7〜8がオンになり、 Bluetoothは3Mで初期化され、Wi-Fiはコネクテッドのままです。 推奨されるLinux RXのプルダウン構成はすでに適用されています: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 実行中のデバイスツリー内で、この値と有効化されたUART5ノードの参照を確認しました。しかし、手動のスイッチシーケンスは依然として必要です。 Android Wi-Fiの切り替えは、このUART信号経路を物理的に切断・再接続することはありません。したがって、残りの問題は、起動および実行時を通じてSW1の接点7–8をオンのままにしたままの信頼性の高い初期化です。 必要な早期ピン設定やモジュールの電源/リセットシーケンスについて調査し、恒久的な解決策にはシステムマネージャー、U-Boot、Linux、またはハードウェアの変更が必要なのか助言いただけますか? テストのために、回路図抜粋、スイッチ写真、初期シリアルログを提供できます。 よろしくお願いします、 ラケシュ・クマール・タクール Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 親愛なる魏東様 SW1のルーティングについて明確にしてくれて、RXのプルダウン設定はLinuxデバイスツリーでのみ必要だと教えてくれてありがとうございます。 この構成だけでLinuxとオートモーティブAndroid 15.0.0_2.1.0の両方で88W8987の初期化問題が完全に解決できるのか確認していただけますか? IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e この設定はすでに当社の実行中のAndroidデバイスツリーで適用・検証されています。しかし、我々が観察した行動は依然として以下の通りである。 SW1は電源オン前に7〜8オンに接続:firmwarestat=0xf005でWLANファームウェアのアクティベーションが失敗します。 電源オン前にお問い合わせがオフ:WLANファームウェアが正常にアクティベートされます。 ファームウェア起動後に連絡先がオンになった場合:Bluetoothは3Mで初期化され、Wi-Fiはコネクテッドのままです。 明確にしておきますが、私たちの問題はi.MX95システムの起動自体ではなく、WLANファームウェアの有効化に関するものです。 LinuxとオートモーティブAndroidの両方で、必要なSW1セクションをすべてオンにして冷たい電源を入れた状態でWi-FiとBluetoothの初期化を確認しましたか?テスト対象モジュールの部品番号、BSPバージョン、および必要な追加パッチや電源/リセットシーケンスの変更点をお知らせください。 私たちの目標は、SW1を手動で操作することなく、確実に初期化することです。 よろしくお願いします、 ラケシュ・クマール・タクール Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue @Rakesh_Kumar_Thakur様、 あなたのi.MX95-EVKは私のものとは違うようですね。B0シリコンを使用したi.MX95 19×19 EVKの回路図はお持ちですか？比較のために教えてもらえますか?     ありがとうございます よろしくお願いいたします。 維東 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue こんにちは、 @Rakesh_Kumar_Thakur さん。 私も回路図を使います。 しかし、私の方では何の問題もありません。 8987のWi-Fiモジュールを送ってもらえますか?私の方でもテストしてみたいです。     ありがとうございます よろしくお願いいたします。 維東 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue @Rakesh_Kumar_Thakur様、 私は自分のi.MX95-EVKでこれを何度もテストしました。Wi-FiとBluetoothの同時動作、コールドリセット、完全な電源オフ/電源オンサイクルなどです。 テスト中は4つのSW1スイッチすべてがオンのままです。なぜならLPUART5信号はこれら4つのJTAGピンを経由しているからです。電源投入時やWi-Fi/Bluetoothの初期化時にはSW1の設定を変更しません。 こちらは、私がテストに使用したi.MX95-EVKの写真です。お使いのi.MX95-EVKのハードウェアリビジョンが同じかどうかご確認ください。 私の環境ではこの問題は発生していません。 あなたのボードの動作は非常に異常です。もう一つ気づいた点があります:あなたはAndroid 15.0.0_2.1.0を使っていますBSPですが、ご指摘のカーネルバージョンは、弊社のBSPに含まれる実際のカーネルバージョンと一致しません。なぜこのような食い違いがあるのか、私にはよく分かりません。     ありがとうございます よろしくお願いいたします。 維東     Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 親愛なる魏東様 ここに回路図ファイルをアップロードできないため、両方のデザインパッケージを含む公式NXPページを共有します。 https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19 デザインファイル の下に 、以下をダウンロードしてください: SPF-87753-B — i.MX 95 19EVK デザインファイル SPF-87754-B — i.MX 95 19EVK コンピュートモジュールデザインファイル これらは、u-blox JODY-W263-00B (88W8987) モジュールを使用した i.MX95 19×19 EVK セットアップで使用している回路図の参照です。 テスト済みのハードウェア、特にSW1/LPUART5ルーティング、M.2インターフェース、モジュールの電源/リセット回路と比較していただけますか?ファームウェア初期化時にSW1接点7〜8の接続を切断する必要があった理由に違いがあれば教えてください。また、必要な変更点についてご助言ください。 よろしくお願いします、 ラケシュ・クマール・タクール Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 親愛なる魏東様 繰り返し電源を切って再起動し、SW1の4つのセクションすべてをオンにした状態で、Wi-FiとBluetoothが正常に動作することを確認いただき、ありがとうございます。 私たちの体制は以下の通りです。 ボード：NXP i.MX95 19×19 EVK、B0シリコン モジュール:u-blox JODY-W263-00B、88W8987をベースに、M.2アダプターを介してコネクテッド インターフェース:Wi-Fi(SDIO経由)とBluetooth(LPUART5) BSP:オートモーティブAndroid 15.0.0_2.1.0 以前に確認された実行中のカーネル: 6.12.23-4k-ge0732a9b6eb5-dirty Bluetooth UART: /dev/ttyLP4 、初期化時および実行時のボーレートは両方とも3000000に設定されています。 以下のLinux RXプルダウン設定はすでに当社のランニングデバイスツリーで適用・検証されています: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e しかし、SW1の接点7〜8は電源オンおよびWLANファームウェア初期化時にオフにし、その後Bluetooth操作のためにONする必要があります。これらのコンタクトが電源オンの場合、firmwarestat=0xf005でWLANファームウェアのアクティベーションが失敗します。 取締役会は今後2日間、不在となります。その間に、検証済みのセットアップの詳細を教えていただけますか?私たちのものと比較し、どの変更点をAndroid BSPに移植できるか評価したいのです。 正確なハードウェア: Wi-Fi/Bluetoothモジュールの製造元とフル部品番号、M.2アダプターの部品番号/リビジョン、EVKベースボード/SOMのリビジョン。JODY-W263-00Bを具体的にテストしたかどうかを確認してください。 正確なソフトウェア:報告された成功したテストがLinux、オートモーティブ Android、またはその両方で行われたかどうか。各テスト済みセットアップについて、BSPのリリース、カーネルのバージョン、コミット、できればuname -aの出力を提供してください。カーネルバージョンに不一致があるとおっしゃいましたが、当社のBSPに対して期待されるカーネルバージョンを特定してください。 デバイスツリーの変更内容をすべて含めてください。最終的な動作ボードのDTSファイル、付属のDTSIファイル、DTオーバーレイ/DTBOソース、および関連するビルド構成が必要です。特に、正確なBSPベースラインに対するパッチがあると助かります。 ドライバとファームウェア: Wi-Fiドライバーのバージョン/ブランチ/コミット、正確なWi-Fi/Bluetoothファームウェアファイル名とバージョン、Bluetooth HAL/ベンダー設定(UARTボーレートやフロー制御を含む)。 その他の必要な変更点: カーネル設定、pinctrl、レギュレーター、SDIOの電源/リセットシーケンス、システムマネージャー、U-Boot、または作業環境で使用したハードウェアの変更。これらの部分に変更が必要かどうかは明確に確認してください。 再現フロー: クリーンBSPから動作イメージまでのステップで、すべてのパッチ、ビルドターゲット、点滅ステップ、スイッチ/ジャンパー位置、コールドオンテスト時に使用されるWi-Fi/Bluetooth初期化シーケンスが含まれます。 また、Linux DTS RXのプルダウンだけがこの問題に必要な変更なのか、それとも作業イメージに追加の変更が含まれているのかも確認してください。 私たちの目標は引き続きオートモーティブAndroid 15.0.0_2.1.0です。ブート時および実行時を通して必要なSW1セクションがすべてONの状態を維持しながら、Wi-FiとBluetoothの初期化を確実に行うことを目的として、必要な変更をこのBSPに移植することを検討したいと考えています。 よろしくお願いします、 ラケシュ・クマール・タクール Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue @Rakesh_Kumar_Thakur様、 まず、u-bloxのJODY-W263-00Bが26 MHzの基準クロックを使っているかどうか確認いただけますか? 26MHzを使用している場合は、 IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e が正しい設定です。 以下の手順をお試しください。 4つのSW1スイッチすべてを ON に設定し、そのままオンにしてください。 IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e に設定します。 ボードの電源を完全に切ってから、再度電源を入れてください。 WLANファームウェアが正常に初期化できるか確認してください。 結果を共有してください。 ありがとうございます よろしくお願いいたします。 維東

集成电路 请帮忙确认以下部件的晶圆位置 (COD) PCA82C251T/YM，118 PCA9547PW，118

S32_Power_Win32_v1.0_b151127 を探していますインストーラー（旧バージョン） こんにちは、NXPコミュニティの皆さん、 私は現在、 S32 Design Studio for Power Architecture v1.0 を特に必要とするレガシープロジェクトを管理しています 。 インストーラーファイルはすでに持っていますが、残念ながら.exeファイルが 破損 していて、もう実行できません。必要な正確なファイル名は以下の通りです: S32_Power_Win32_v1.0_b151127.exe 現在のNXP公式ダウンロードページを確認しましたが、見つかるのは新しいバージョン(v1.2、v2.1など)だけです。旧バージョンv1.0は、公開ダウンロードリストから削除されたようです。 どなたか(NXPスタッフやコミュニティの方)が、この特定のバージョンの有効なダウンロードリンクやアーカイブコピーを提供していただけませんか? 古いバージョンであることは承知していますが、現在の作業には不可欠です。どんなご支援でも大変ありがたく思います！ 事前に感謝いたします。

CLRC663をP2Pデバイスとして使用する こんにちは、 CLRC663 plusをピアツーピア（P2P）デバイスとして使用したいと考えています。データシートによると、CLRC663はISO/IEC 18092に準拠したパッシブイニシエータモードのP2Pモードをサポートしています。 しかし、これによって多くの疑問が生じる。 2台のCLRC663デバイスを相互に通信させることは可能ですか？ そうでない場合、CLRC663は別のデバイスと組み合わせるべきでしょうか？どちらがお勧めですか？ ISO 18092プロトコルを有効化するにはどうすればよいですか？他のプロトコルについては、 AN12657にCLRC633のLoadProtocol機能を使用して他のプロトコルをアクティブ化する方法が少なくとも記載されていることがわかりましたが、データシートにはISO 18092プロトコルに関する情報が一切ありません。これら2つの起動方法もデータシートからは全く不明ですが、このアプリケーションノートから推測できます。 パッシブイニシエーターモードで2台のデバイスが通信できますか? この件に関してフォーラムに投稿されている記事はほぼ全て確認しましたが、役に立つ情報は何も見つかりませんでした。NFCリーダ Libraryも見ましたが、P2Pに関して有益な情報は見つかりませんでした。 敬具 Re: Using CLRC663 as P2P device こんにちは、 NXPセミコンダクターズ製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます CLRC663はNFCフォーラムの規格に完全に準拠しておらず、リーダー/ライターモードでの使用を想定しています。したがって、CLRC663は必要なターゲットモードをサポートする(すなわちHCE）。標準的なISO/IEC 18092のP2P接続については 、PN5190の評価を検討してみてください。 しかし、このハードウェアの考慮も利用可能なサポートと併せて評価する必要があります。NXP NFCリーダライブラリでは、P2P機能の維持管理が中止されることにご注意ください。以前のライブラリリリースにはレガシーP2Pサポートが含まれていますが、現在のソフトウェアベースラインではP2P機能はサポートされていません。 よろしくお願いします、 アロンドラ Re: Using CLRC663 as P2P device こんにちは、 なお、Mikroe USBドングルはNXP製品ではありません。したがって、アプリケーションの実装と互換性は、ドングルメーカーが提供する機能とサポートに完全に依存します。 さらに、PN7150は新しいデザインには推奨されていません。NXPはPN7150のAndroidメンテナンスを中止しており、新しいAndroidバージョンのサポートを提供する予定はありません。 ISO/IEC 18092に基づくP2P通信は廃止され、NXPによるサポートは終了しました。 2つのPN5190デバイスを検討する場合にも、同様の状況が当てはまります。P2Pはもはやサポートされていないため、推奨される方法は、P2P構成を実装するのではなく、1台のPN5190をNFCリーダとして、もう1台をカードエミュレーションモードに設定することです。 新しいデザインについては、現在サポートされているNFC動作モードやソリューションの使用を推奨します。 よろしくお願いいたします。 Re: Using CLRC663 as P2P device こんにちは、 ご回答ありがとうございます。 PN5190についても調査します。 私たちはPN7150を使う Mikroe USBドングル を持っていますが、これを使ってこの機能もテストできますか? 私の主な懸念はCLRC663にISO 18092規格を設定することです。他のプロトコルではこれを有効にする設定を見つけましたが、ISO 18092では見つかりませんでした。 PN5190 ICを2つ使用して通信させることは可能でしょうか？あるいは、その方が簡単でしょうか？ ちなみに、NFC P2Pはどこか"昔ながら"のもののようです。Androidは約7バージョン前にサポートを終了し、NXPもこれをレガシーとして扱っているようです。これって試してみる価値があるの？ 敬具 Re: Using CLRC663 as P2P device こんにちは、 改めて感謝申し上げます。おかげさまで、正しい方向へ進むことができました。P2P方式は明らかに適切な方法ではない。

正在查找 S32_Power_Win32_v1.0_b151127安装程序（旧版） NXP社区的各位朋友，大家好！ 我目前正在维护一个遗留项目，该项目特别需要S32 Design Studio for Power Architecture v1.0 。 我已经有了安装程序文件，但不幸的是，.exe文件已损坏，无法运行。我需要的确切文件名是： S32_Power_Win32_v1.0_b151127.exe 我查看了 NXP 的官方下载页面，但只能找到较新的版本（v1.2、v2.1 等）。旧版本 v1.0 似乎已从公共下载列表中移除。 请问有人（NXP员工或社区成员）能否提供该特定版本的有效下载链接或存档副本？ 我知道这是个旧版本，但它对我目前的任务至关重要。非常感谢您的帮助！ 提前谢谢您。

i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear NXP Support Team, Following Weidong’s recommendation, we are opening a new ticket for Bluetooth bring-up on our i.MX95 platform. Wi-Fi is now working, but we need guidance on restoring Bluetooth UART communication while maintaining the correct reference-clock selection during reset. 1. Hardware and software configuration Host board: NXP i.MX95 19×19 EVK, B0 Wireless module: u-blox JODY-W263-00B, based on 88W8987, connected through M.2 Key-E BSP: Automotive Android 15.0.0_2.1.0 Kernel: 6.12.23 Wi-Fi interface: SDIO through uSDHC3 Bluetooth interface: LPUART5, exposed as /dev/ttyLP4 Wi-Fi driver: NXP mwifiex from automotive-15.0.0_2.1.0, release 537.p9 Firmware: sduart8987_combo.bin from the corresponding Android BSP firmware repository Firmware version: 16.92.21.p151.4 Firmware size: 628,200 bytes We intend to continue with the recommended SDIO + UART configuration. 2. Wi-Fi activation failure and switch observation Previously, the module was detected over SDIO and firmware transfer completed, but firmware activation failed with: Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! During investigation, NXP advised that 88W8987 GPIO[8]/UART_SOUT is sampled during reset to select the reference clock: LOW: 38.4 MHz HIGH: 26 MHz This signal also serves as the Bluetooth UART TX output during normal operation and connects to the host LPUART5 RX input. On our EVK, the relevant connection is: Module Bluetooth TX → M.2 J24 pin 22 → R607 → BT_UART5_RXD → R17 → SW1 contacts 7–8 → host LPUART5 RX Our repeatable observation is: SW1 contacts 7–8 ON during cold boot: Wi-Fi firmware activation fails with 0xf005. SW1 contacts 7–8 OFF during cold boot: Wi-Fi initializes successfully and is operational. We also tested the suggested host RX pad pull-down configuration: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e However, the earlier tests did not resolve the failure with SW1 contacts 7–8 ON. The running device tree we subsequently extracted showed RX pad configuration 0x31e, so we would appreciate guidance on the complete configuration and when it takes effect during boot/reset. 3. Bluetooth failure with the working Wi-Fi configuration Keeping SW1 contacts 7–8 OFF allows Wi-Fi to work, but it also disconnects the module Bluetooth TX from the host UART RX. We therefore expect Bluetooth initialization to fail because the host cannot receive controller responses. Bluetooth is tested through ADB because the board has no connected display. The installed vendor configuration is: mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 The vendor library defaults baudrate_bt to 3000000. UART firmware download is disabled by default; the current configuration relies on the combo firmware loaded through the Wi-Fi driver. The Bluetooth vendor HAL reports version 009.030 and successfully opens the UART device: bt_vnd_init --- BT Vendor HAL Ver: 009.030 --- mchar_port set to /dev/ttyLP4 baudrate_fw_init is set to 3000000 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 However, the Bluetooth stack remains in BLE_TURNING_ON and eventually aborts: Can't start stack, last instance: starting HciHal During close/recovery, the vendor library also reports: Read hci complete event failed timed out Failed to read HCI RESET CMD response! The source configuration sequence begins with an HCI Reset command. Opening the UART device succeeds, but successful controller communication has not been established. 4. Guidance requested Could you please advise on the following? How should this shared clock-configuration/Bluetooth UART signal be handled on i.MX95? We need the module TX/host RX line LOW during reset for 38.4 MHz selection, followed by a connected, functional UART receive path during normal operation. What is the recommended configuration for SW1 contacts 7–8 and the LPUART5 RX pad? Should the switch remain ON with a specific pad configuration, or is an additional board-level change required? At which boot stage must the pull-down be applied? Is the Linux device-tree setting sufficient, or must U-Boot, System Manager/SCMI pin control, or another earlier initialization stage configure this pad before module reset is released? Please provide the recommended power/reset and pin-control sequence, including any required handling of W_DISABLE2#/Bluetooth enable, to ensure correct clock sampling and subsequent UART operation. Please confirm the Bluetooth configuration for the BSP-provided sduart8987_combo.bin: initial UART baud rate, operating baud rate, RTS/CTS flow control, and any required wake/sleep settings or vendor configuration entries. Is there a validated DTS/patch and Bluetooth vendor configuration for an 88W8987 module on this BSP? If available, please share the reference configuration and module part number used for validation. We investigated the SDIO-SDIO alternative, but understand from Weidong that those specialized packages are outdated and have not kept pace with kernel upgrades. We have not validated an SDSD firmware on this target and would like to resolve the issue using the standard SDIO + UART architecture. We can provide full Bluetooth logs, the running device tree, schematic excerpts, and oscilloscope measurements of the shared strap/UART line during reset and Bluetooth initialization. Please advise which measurement points and timing conditions would be most useful. Thank you for your continued support in enabling Wi-Fi. We would appreciate your guidance on completing Bluetooth bring-up while preserving the working Wi-Fi configuration. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , Please change  baudrate_fw_init = 3000000 to baudrate_fw_init = 115200 Then try. Thanks, Regards, weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , Please confirm if baud rate is fixed in your wifi/bt module with u-blox. if the fixed baud rate is 115200, try the configuration: mchar_port = /dev/ttyLP4 baudrate_fw_init = 115200 If the fixed baud rate is 3000000, use the configuration mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 Then try it. I will have time to test it next week. you can try it first. BYW，I'm not quite sure I understand your operation. To turn Wi-Fi off and back on, you can simply do it through Android. There is no need to operate the SW1 switch on the board. Thanks, Best Regards, Weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Subject: i.MX95 / JODY-W263: Baud-rate test results and request for a permanent solution without manual SW1 switching Dear Weidong, Thank you for your support. We tested your recommendation to change baudrate_fw_init from 3000000 to 115200. Below are the results and the remaining boot-time issue. We need a permanent solution for our next week’s integration activities, so your guidance on the required configuration or patch would be appreciated. Platform Board: NXP i.MX95 19×19 EVK, B0 Module: u-blox JODY-W263-00B / 88W8987, M.2 Key-E BSP: Automotive Android 15.0.0_2.1.0 Kernel: 6.12.23 Bluetooth Vendor HAL: 009.030 Wi-Fi interface: SDIO through uSDHC3 Bluetooth interface: UART5, /dev/ttyLP4 Firmware: sduart8987_combo.bin Switch under investigation: SW1, switch section 4, contacts 7–8, on the Bluetooth UART RX path toward the host. 1. Boot with SW1 contacts 7–8 ON Wi-Fi firmware activation fails: Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! WLAN: Fail download FW with nowwait: 0 Bluetooth also fails to reach the ON state. We have applied the recommended Linux RX pad configuration: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e We extracted the running device tree and verified that this value is present and referenced by the enabled UART5 node. However, the switch-ON boot issue remains. 2. Working sequence with initialization baud rate 3000000 The following sequence allows Wi-Fi and Bluetooth to operate: Keep SW1 contacts 7–8 OFF before power-on. Power on the board and allow firmware initialization to complete. Confirm: [12.738590] WLAN FW is active [12.954531] wlan: Driver loaded successfully Disable Bluetooth and confirm STATE_OFF. With the board running, physically turn SW1 contacts 7–8 ON. Enable Bluetooth. With: baudrate_fw_init = 3000000 baudrate_bt = 3000000 we obtained: wait-for-state:STATE_ON: Success enabled: true state: ON Wi-Fi remained connected to P3-Devices, with IP address 10.17.36.30, supplicant state COMPLETED, and network status VALIDATED. Bluetooth scanning and pairing had also worked previously using this manual switch sequence. In the latest 3M comparison run, Bluetooth ON and the Wi-Fi connection were confirmed. 3. Test of your recommended initialization baud rate 115200 We rebuilt and flashed the vendor/super images and matching board-specific AVB metadata with: mchar_port = /dev/ttyLP4 baudrate_dl_image = 115200 iSecondBaudrate = 3000000 baudrate_fw_init = 115200 baudrate_bt = 3000000 Both the deployed configuration and HAL logs confirmed that 115200 was used. We followed the same sequence: boot with contacts 7–8 OFF, confirm WLAN firmware active, disable Bluetooth, physically turn contacts 7–8 ON, and enable Bluetooth. Wi-Fi continued to operate, but Bluetooth initialization failed: baudrate_fw_init is set to 115200 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 Read hci complete event failed timed out. Total_duration = 1000 Failed to read HCI RESET CMD response! config_uart failed The adapter did not reach STATE_ON; repeated Bluetooth stack initialization failures occurred. After restoring only the initialization baud setting to 3000000 and rebuilding the images while retaining the same experimental bootloaders and kernel, Bluetooth reached ON using the same OFF-at-boot → ON-after-initialization sequence. 4. Additional boot-time experiments We also tested: Adding the RX 0x51e configuration to the U-Boot early pinctrl hog. An experimental SCMI pinctrl-driver change to include a mux request for the zero-offset DAP_TDI pin. The original driver condition, if (mux_ofs), skips the mux request for this pin because its mux offset is zero. These experiments did not resolve the switch-ON boot failure. We have not yet confirmed through early serial logs when the configuration is applied or whether the SCMI request succeeds. We therefore do not consider these changes proven fixes. Request for a permanent solution The manual switch sequence is useful for debugging, but it is not suitable for normal operation. We need Wi-Fi and Bluetooth to initialize reliably with SW1 contacts 7–8 left ON throughout power-on and runtime, without user intervention. Could you please review these results and provide: The correct initialization baud rate for JODY-W263 / 88W8987 with this combo firmware, given that 115200 failed and 3000000 succeeded in our comparison. The required pin configuration and module power/reset sequence to maintain the correct GPIO[8]/UART_SOUT strap state during initialization while preserving UART operation afterward. The appropriate implementation location—System Manager, SPL/U-Boot, Linux pinctrl/MMC power sequencing, or a hardware change. A specific patch or validated configuration for our board/BSP, including any required GPIO polarity, reset timing, or pin-ownership changes. Please also confirm whether the zero-offset mux handling in the SCMI pinctrl driver is intentional for i.MX95. We can provide the complete successful and failed logs, running device tree, source diffs, and SW1 photographs. Please let us know which additional early-boot traces you require. Thank you for helping us move from the working manual sequence to a reliable permanent solution. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear Weidong, Thank you for your reply and for offering to test this next week. We checked the u-blox JODY-W2 System Integration Manual, UBX-18068879, revision R14: Page 17 documents the default UART baud rate as 3000000. Section 2.4.2, page 29, states that the baud rate after firmware loading is 3000000, and that other supported rates can be configured using the dedicated HCI baud-rate command. Therefore, the documented default is 3M; the UART is not described as permanently restricted to this rate. Our tests also support the following configuration: mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 baudrate_bt = 3000000 With WLAN firmware active and the UART path connected, initialization at 115200 repeatedly timed out waiting for the HCI Reset response. Restoring 3000000 allowed Bluetooth to reach enabled: true, state: ON, while Wi-Fi remained connected. I would also like to clarify the physical switch operation. We are not operating SW1 to toggle Wi-Fi ON/OFF. According to the i.MX95 EVK baseboard schematic, SPF-87753-B, sheet 4, we operate SW1 section 4, contacts 7–8, on this path: Host JTAG_TDI / LPUART5_RX ↔ SW1 contacts 7–8 ↔ R17 (49.9 Ω) ↔ BT_UART5_RXD toward M.2. Here, R17 is the board resistor reference. It is separate from the u-blox document revision R14. Board resistor R14 belongs to the different CTS channel. Our observed behavior is: Contacts 7–8 ON before power-on: WLAN firmware activation fails with firmwarestat=0xf005. Contacts 7–8 OFF before power-on: WLAN firmware initializes successfully. After firmware initialization, contacts 7–8 turned ON: Bluetooth initializes at 3M, and Wi-Fi remains connected. The recommended Linux RX pull-down configuration is already applied: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e We verified this value and the enabled UART5 node’s reference in the running device tree. However, the manual switch sequence is still required. Android Wi-Fi toggling does not physically disconnect/reconnect this UART signal path. The remaining problem is therefore reliable initialization with SW1 contacts 7–8 left ON throughout boot and runtime. Could you please investigate the required early pin configuration and module power/reset sequence, and advise whether the permanent solution requires a System Manager, U-Boot, Linux, or hardware change? We can provide the schematic excerpt, switch photographs and early serial logs for your testing. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , OK, understood. Sorry , I ignored the switch. Yes, if you want to use LPUART5 on M.2,  need to enable all LPUART5 signals through SW1. Because LPUART5 signals are multiplexed through these JTAG PADs. But SW1 doesn't affect system boot.   The configuration ,  IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e is only needed to be configured in linux device tree. Not needed in u-boot device tree. Thanks, Regards, weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear Weidong, Thank you for clarifying the SW1 routing and that the RX pull-down configuration is required only in the Linux device tree. Could you please confirm whether this configuration alone is the complete fix for the 88W8987 initialization issue on both Linux and Automotive Android 15.0.0_2.1.0? IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e This setting is already applied and verified in our running Android device tree. However, our observed behavior remains: SW1 contacts 7–8 ON before power-on: WLAN firmware activation fails with firmwarestat=0xf005. Contacts OFF before power-on: WLAN firmware activates successfully. Contacts turned ON after firmware activation: Bluetooth initializes at 3M, and Wi-Fi remains connected. To clarify, our issue concerns WLAN firmware activation, rather than the i.MX95 system boot itself. Have you verified Wi-Fi and Bluetooth initialization from a cold power-on with all required SW1 sections left ON throughout, on both Linux and Automotive Android? Please share the tested module part number, BSP versions, and any additional patches or power/reset sequencing changes required. Our goal is reliable initialization without manually operating SW1. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Hi @Rakesh_Kumar_Thakur , I also use the schematic.  But no problem on my side. Could you send me your 8987 Wi-Fi module? I'd like to test it on my side.     Thanks, Best Regards, Weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , I have tested this many times on my i.MX95-EVK, including simultaneous Wi-Fi and Bluetooth operation, cold reset, and complete power-off/power-on cycles. All four SW1 switches are kept ON throughout my testing, because the LPUART5 signals are routed through these four JTAG pins. I do not change the SW1 settings during power-on or Wi-Fi/Bluetooth initialization. Here is a photo of the i.MX95-EVK used for my testing. Please check whether your i.MX95-EVK is the same hardware revision. I do not see this issue on my setup. The behavior of your board is quite unusual. There is also another point I noticed: you are using the Android 15.0.0_2.1.0 BSP, but the kernel version you mentioned does not match the actual kernel version included in our BSP. I am not sure why there is this discrepancy.     Thanks, Best Regards, Weidong     Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear Weidong, Thank you for confirming that Wi-Fi and Bluetooth work on your setup through repeated cold resets and complete power cycles, with all four SW1 sections kept ON. Our setup is: Board: NXP i.MX95 19×19 EVK, B0 silicon Module: u-blox JODY-W263-00B, based on 88W8987, connected through an M.2 adapter Interfaces: Wi-Fi over SDIO and Bluetooth over LPUART5 BSP: Automotive Android 15.0.0_2.1.0 Previously observed running kernel: 6.12.23-4k-ge0732a9b6eb5-dirty Bluetooth UART: /dev/ttyLP4, initialization and runtime baud rates both set to 3000000 The Linux RX pull-down setting below is already applied and verified in our running device tree: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e However, we still require SW1 contacts 7–8 to be OFF during power-on and WLAN firmware initialization, then ON for Bluetooth operation. With these contacts ON from power-on, WLAN firmware activation fails with firmwarestat=0xf005. Our board will be unavailable for the next two days. Meanwhile, could you please provide the complete details of your validated setup so we can compare it with ours and assess which changes can be ported to our Android BSP? Exact hardware: Wi-Fi/Bluetooth module manufacturer and full part number, M.2 adapter part number/revision, and EVK baseboard/SOM revisions. Please confirm whether you have tested JODY-W263-00B specifically. Exact software: Whether the reported successful tests were performed on Linux, Automotive Android, or both. For each tested setup, please provide the BSP release, kernel version and commit, and preferably the uname -a output. You mentioned a discrepancy in our kernel version; please identify the expected kernel version for our stated BSP. Complete device-tree changes: The final working board DTS, included DTSI files, any DT overlays/DTBO sources, and relevant build configuration. A patch against the exact BSP baseline would be particularly helpful. Driver and firmware: The Wi-Fi driver version/branch/commit, exact Wi-Fi/Bluetooth firmware filenames and versions, and Bluetooth HAL/vendor configuration, including UART baud rate and flow control. Other required changes: Any kernel configuration, pinctrl, regulator, SDIO power/reset sequencing, System Manager, U-Boot, or hardware changes used in your working setup. Please confirm explicitly if no changes are required in any of these areas. Reproduction flow: The steps from the clean BSP to the working image, including all patches, build targets, flashing steps, switch/jumper positions, and the Wi-Fi/Bluetooth initialization sequence used during cold power-on testing. Please also confirm whether the Linux DTS RX pull-down is the only change needed for this issue, or whether your working image includes additional changes. Our target remains Automotive Android 15.0.0_2.1.0. We would like to evaluate porting the necessary changes to this BSP, with the goal of reliable Wi-Fi and Bluetooth initialization while all required SW1 sections remain ON throughout boot and runtime. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , It seems that your i.MX95-EVK may be different from mine. Do you have the schematic for the i.MX95 19×19 EVK with B0 silicon? Could you please share it with me for comparison?     Thanks, Best Regards, Weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear Weidong, I am unable to upload the schematic files here, so I am sharing the official NXP page containing both design packages: https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19 Under Design Files, please download: SPF-87753-B — i.MX 95 19EVK Base Board Design Files SPF-87754-B — i.MX 95 19EVK Compute Module Design Files These are the schematic references we are using for our i.MX95 19×19 EVK setup with the u-blox JODY-W263-00B (88W8987) module. Could you please compare them with your tested hardware, particularly the SW1/LPUART5 routing, M.2 interface, and module power/reset circuitry? Please let us know whether any differences could explain the need to disconnect SW1 contacts 7–8 during firmware initialization, and advise on the required changes. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , First, could you please confirm whether your u-blox JODY-W263-00B is using a 26 MHz reference clock?  If it is using 26 MHz, IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e should be the correct setting. Please try the following: Set all four SW1 switches to ON and keep them ON. Set IMX95_PAD_DAP_TDI__LPUART5_RX to 0x31e . Power off the board completely and power it on again. Check whether the WLAN firmware can be initialized successfully. Please share the result with me. Thanks, Regards, Weidong

i.MX95 Android 15：88W8987 蓝牙 UART 超时和共享时钟带/UART RX 引脚问题 尊敬的恩智浦技术支持团队： 根据魏东的建议，我们正在为 i.MX95 平台上的蓝牙启动创建一个新的工单。Wi-Fi 现在可以正常工作了，但是我们需要指导如何在RESET期间保持正确的参考时钟选择的同时恢复蓝牙 UART 通信。 1. 硬件和软件配置 主机板：NXP i.MX95 19×19 EVK，B0 无线模块：u-blox JODY-W263-00B，基于 88W8987，通过 M.2 Key-E 接口连接。 电路板支持包。：汽车 Android 15.0.0_2.1.0 内核版本：6.12.23 Wi-Fi接口：通过uSDHC3的SDIO 蓝牙接口：LPUART5，暴露为/dev/ttyLP4 Wi-Fi 驱动程序：NXP mwifiex，来自automotive-15.0.0_2.1.0 ，版本 537.p9 固件：来自相应 Android 电路板支持包。固件库的sduart8987_combo.bin文件 固件版本：16.92.21.p151.4 固件大小：628,200 字节 我们打算继续采用推荐的 SDIO + UART 配置。 2. Wi-Fi激活失败及交换机观察 之前，已通过 SDIO 检测到该模块并完成固件传输，但固件激活失败，错误信息如下： Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! 调查期间，NXP 指出，RESET期间会对 88W8987 GPIO[8]/UART_SOUT 进行采样，以选择参考时钟： 低频：38.4 MHz 高：26 MHz 该信号在正常操作期间也用作蓝牙 UART TX 输出，并连接到主机 LPUART5 RX 输入。 在我们的 EVK 中，相关连接是： Module Bluetooth TX → M.2 J24 pin 22 → R607 → BT_UART5_RXD → R17 → SW1 contacts 7–8 → host LPUART5 RX 我们可重复观察到的现象是： 冷启动期间 SW1 触点 7–8 ON： Wi-Fi 固件激活失败，错误代码为0xf005 。 冷启动期间 SW1 触点 7–8 关闭： Wi-Fi 初始化成功并可运行。 我们还测试了建议的主机 RX 焊盘下拉配置： IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 然而，之前的测试并未解决SW1触点7-8导通的问题。我们随后提取的运行设备树显示RX焊盘配置为0x31e，因此我们希望获得关于完整配置及其在启动/RESET过程中生效时间的指导。 3. Wi-Fi 配置正常，但蓝牙功能失效 将 SW1 触点 7-8 保持关闭状态可使 Wi-Fi 工作，但也会断开模块蓝牙 TX 与主机 UART RX 的连接。因此，我们预计蓝牙初始化会失败，因为主机无法接收控制器响应。 由于该板没有外接显示屏，因此蓝牙功能是通过 ADB 进行测试的。 已安装的供应商配置如下： mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 供应商库默认将baudrate_bt设置为 3000000。UART 固件下载默认处于禁用状态；当前配置依赖于通过 Wi-Fi 驱动程序加载的组合固件。 蓝牙供应商 HAL 报告版本为 009.030，并成功打开 UART 设备： bt_vnd_init --- BT Vendor HAL Ver: 009.030 --- mchar_port set to /dev/ttyLP4 baudrate_fw_init is set to 3000000 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 然而，蓝牙协议栈仍处于BLE_TURNING_ON状态，最终中止： Can't start stack, last instance: starting HciHal 在关闭/恢复期间，供应商库还会报告： Read hci complete event failed timed out Failed to read HCI RESET CMD response! 源配置序列以 HCI RESET 命令开始。UART 设备打开成功，但尚未建立成功的控制器通信。 4. 请求指导 请问您能否就以下问题提供建议？ 在 i.MX95 上应该如何处理这个共享时钟配置/蓝牙 UART 信号？ 我们需要在 RESET 期间将模块的 TX/主机 RX 线置低，以选择 38.4 MHz 频率，然后在正常运行期间保持 UART 接收路径连接正常。 SW1 的 7-8 号触点和 LPUART5 RX 焊盘的推荐配置是什么？在特定的焊盘配置下，开关是否应该保持开启状态，还是需要进行额外的板级更改？ 下拉电阻必须在启动的哪个阶段应用？ Linux 设备树设置是否足够，还是必须在模块 RESET释放之前，由 U-Boot、系统管理器/SCMI 引脚控制或其他更早的初始化阶段配置此焊盘？ 请提供推荐的电源/RESET 和引脚控制顺序，包括对 W_DISABLE2#/蓝牙使能的任何必要处理，以确保正确的时钟采样和后续的 UART 操作。 请确认电路板支持包。提供的sduart8987_combo.bin：初始 UART 波特率、工作波特率、RTS/CTS 流控制以及任何所需的唤醒/睡眠设置或供应商配置条目。 此电路板支持包。中是否存在针对88W8987模块的已验证的DTS/补丁和蓝牙供应商配置？如有，请分享用于验证的参考配置和模块部件号。 我们研究了 SDIO-SDIO 替代方案，但从 Weidong 那里了解到，这些专用软件包已经过时，没有跟上内核升级的步伐。我们尚未在此目标设备上验证 SDSD 固件，希望使用标准的 SDIO + UART 架构来解决此问题。 我们可以提供完整的蓝牙日志、运行中的设备树、原理图摘录以及RESET和蓝牙初始化期间共享跳线/UART线的示波器测量结果。请告知哪些测量点和时间条件最有用。 感谢您一直以来对启用Wi-Fi的支持。我们恳请您指导我们如何在保持现有 Wi-Fi 配置的情况下完成蓝牙启动。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 请更改 baudrate_fw_init = 3000000 至 baudrate_fw_init = 115200 那就试试。 谢谢！ 此致， 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 主题：i.MX95 / JODY-W263：波特率测试结果及无需手动切换SW1的永久解决方案请求 亲爱的卫东， 感谢您的支持。我们已测试了您提出的将baudrate_fw_init从3000000更改为115200的建议。以下是测试结果以及仍然存在的启动时间问题。 我们需要为下周的集成活动找到一个永久解决方案，因此，如果您能就所需的配置或补丁提供指导，我们将不胜感激。 平台 板：NXP i.MX95 19×19 EVK，B0 模块：u-blox JODY-W263-00B / 88W8987，M.2 Key-E 电路板支持包。：汽车 Android 15.0.0_2.1.0 内核版本：6.12.23 蓝牙供应商 HAL：009.030 Wi-Fi接口：通过uSDHC3的SDIO 蓝牙接口：UART5， /dev/ttyLP4 固件： sduart8987_combo.bin 被调查的开关： SW1，开关部分 4，触点 7–8 ，位于通往主机的蓝牙 UART RX 路径上。 1. 将 SW1 的 7-8 号触点拨至 ON 位置进行启动 Wi-Fi固件激活失败： Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! WLAN: Fail download FW with nowwait: 0 蓝牙也无法进入开启状态。 我们已应用推荐的Linux RX焊盘配置： IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 我们提取了运行中的设备树，并验证了该值存在，并且已被启用的 UART5 节点引用。然而，开机启动问题仍然存在。 2. 初始化波特率为 3000000 的工作序列 以下步骤可使 Wi-Fi 和蓝牙正常工作： 开机前 请保持SW1触点7-8 关闭 。 接通板电源，等待固件初始化完成。 确认： [12.738590] WLAN FW is active [12.954531] wlan: Driver loaded successfully 关闭蓝牙并确认STATE_OFF 。 在板运行的情况下，将 SW1 触点 7-8 物理打开。 启用蓝牙。 其中： baudrate_fw_init = 3000000 baudrate_bt = 3000000 我们获得了： wait-for-state:STATE_ON: Success enabled: true state: ON Wi-Fi 仍然连接到P3 设备，IP 地址为10.17.36.30 ，请求状态为COMPLETED ，网络状态为 VALIDATED 。 之前使用这种手动切换顺序也能成功进行蓝牙扫描和配对。在最新的 3M 对比测试中，蓝牙开启和 Wi-Fi 连接均已确认。 3. 测试推荐的初始化波特率 115200 我们重新构建并刷写了厂商/超级镜像以及匹配的板 AVB 元数据，内容如下： mchar_port = /dev/ttyLP4 baudrate_dl_image = 115200 iSecondBaudrate = 3000000 baudrate_fw_init = 115200 baudrate_bt = 3000000 已部署的配置和 HAL 日志均证实使用了115200 。 我们按照相同的步骤进行操作：启动时触点 7-8 关闭，确认 WLAN 固件已激活，禁用蓝牙，物理打开触点 7-8，然后启用蓝牙。 Wi-Fi 可以继续运行，但蓝牙初始化失败： baudrate_fw_init is set to 115200 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 Read hci complete event failed timed out. Total_duration = 1000 Failed to read HCI RESET CMD response! config_uart failed 适配器未达到STATE_ON 状态；蓝牙协议栈初始化反复失败。 仅将初始化波特率设置恢复为3000000 ，并在保留相同的实验性引导加载程序和内核的情况下重建映像后，蓝牙通过相同的启动时关闭 → 初始化后开启的序列实现了开启。 4. 额外的启动时间实验 我们还测试了： 将 RX 0x51e配置添加到 U-Boot 早期引脚控制占用中。 一项实验性的 SCMI pinctrl 驱动程序更改，旨在为零偏移的 DAP_TDI 引脚添加多路复用请求。原始驱动程序条件if (mux_ofs)会跳过此引脚的多路复用请求，因为其多路复用偏移量为零。 这些实验并没有解决启动失败的问题。我们尚未通过早期串行日志确认何时应用了配置，或者 SCMI 请求是否成功。因此，我们认为这些改动并不能证明是有效的解决方案。 请求提供永久解决方案 手动切换顺序对于调试很有用，但不适用于正常运行。我们需要 Wi-Fi 和蓝牙在整个上电和运行过程中，无需用户干预，就能可靠地初始化，并且开关 SW1 的 7-8 号触点始终保持开启状态。 请您审核这些结果并提供以下信息： 鉴于在我们的比较中，115200 波特率失败而 3000000 波特率成功，因此，对于使用此组合固件的 JODY-W263 / 88W8987，正确的初始化波特率是 3000000。 初始化期间保持正确的 GPIO[8]/UART_SOUT 跳线状态，同时保持 UART 操作，所需的引脚配置和模块电源/RESET 顺序。 合适的实施位置——系统管理器、SPL/U-Boot、Linux pinctrl/MMC 电源时序控制或硬件更改。 针对我们的板/电路板支持包。 的特定补丁或已验证的配置，包括任何所需的 GPIO 极性、复位时序或引脚所有权更改。 另外，请确认 SCMI pinctrl 驱动程序中的零偏移多路复用器处理是否是 i.MX95 的有意设计。 我们可以提供完整的成功和失败日志、运行中的设备树、源代码差异和 SW1 照片。请与我们联系您还需要哪些早期启动跟踪信息。 感谢您帮助我们从手动操作流程过渡到可靠的永久解决方案。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 请确认您的 u-blox wifi/bt 模块的波特率是否固定。 如果固定波特率为 115200，请尝试以下配置： mchar_port = /dev/ttyLP4 baudrate_fw_init = 115200 如果固定波特率为 3000000，请使用以下配置 mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 那就试试吧。 我下周有时间测试一下。你可以先试试。 BYW，我不太明白你的操作。要关闭再重新打开 Wi-Fi，您只需通过 Android 系统即可完成。无需操作板上的SW1开关。 谢谢！ 顺祝商祺！ 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 亲爱的卫东， 感谢您的回复，也感谢您愿意下周进行测试。 我们查阅了u-blox JODY-W2系统集成手册，UBX-18068879，修订版R14 ： 第 17 页记录了默认的 UART 波特率为3000000 。 第 2.4.2 节，第 29 页指出，固件加载后的波特率为3000000 ，其他支持的波特率可以使用专用的 HCI 波特率命令进行配置。 因此，官方记录的默认值为 3M；UART 并未被描述为永久限制于此速率。 我们的测试也支持以下配置： mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 baudrate_bt = 3000000 在 WLAN 固件激活且 UART 路径连接的情况下，初始化过程在115200处反复超时，等待 HCI RESET 响应。恢复到3000000后，蓝牙状态变为启用：true，状态：开启，而 Wi-Fi 连接仍然保持连接。 我还想澄清一下物理开关的操作。我们并非通过操作 SW1 来切换 Wi-Fi 的开关状态。 根据 i.MX95 EVK 底板原理图 SPF-87753-B，第 4 页，我们按以下路径操作SW1 第 4 部分，触点 7–8 ： 主机 JTAG_TDI / LPUART5_RX ↔ SW1 触点 7–8 ↔ R17 (49.9 Ω) ↔ BT_UART5_RXD 朝向 M.2。 此处，R17 为板电阻参考。与 u-blox 文档修订版中的 R14 不同。板电阻 R14 属于不同的 CTS 通道。 我们观察到的行为是： 开机前触点 7–8 接通： WLAN 固件激活失败，固件状态为 0xf005 。 开机前触点 7–8 关闭： WLAN 固件初始化成功。 固件初始化后，触点 7-8 开启：蓝牙初始化至 3M，Wi-Fi 保持连接。 已应用推荐的 Linux RX 下拉配置： IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 我们验证了该值以及运行设备树中已启用 UART5 节点的引用。但是，仍然需要手动切换顺序。 Android 的 Wi-Fi 开关操作并不会物理断开/重新连接此 UART 信号路径。因此，剩下的问题是如何在整个启动和运行时保持 SW1 触点 7-8 开启的情况下可靠地进行初始化。 请您调查一下所需的早期引脚配置和模块电源/RESET 顺序，并告知永久解决方案是否需要系统管理器、U-Boot、Linux 或硬件更改？ 我们可以提供原理图摘录、开关照片和早期串行日志供您测试。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 好的，明白了。抱歉，我忽略了开关。 是的，如果要在 M.2 上使用 LPUART5，需要通过 SW1 启用所有 LPUART5 信号。 因为 LPUART5 信号是通过这些 JTAG 焊盘进行多路复用的。 但SW1不影响系统启动。 配置， IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 只需在 Linux 设备树中进行配置即可。 u-boot 设备树中不需要。 谢谢！ 此致， 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 亲爱的卫东， 感谢您澄清了 SW1 的路由，并说明 RX 下拉配置仅需要在 Linux 设备树中进行。 请问仅此配置是否能完全解决 Linux 和 Automotive Android 15.0.0_2.1.0 上的 88W8987 初始化问题？ IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 此设置已在我们正在运行的 Android 设备树中应用和验证。然而，我们观察到的现象依然存在： SW1 触点 7–8 在上电前处于 ON 状态：WLAN 固件激活失败，固件状态为 0xf005 。 开机前触点断开：WLAN固件成功激活。 固件激活后联系人开启：蓝牙初始化距离为 3 米，Wi-Fi 保持连接。 需要澄清的是，我们的问题与 WLAN 固件激活有关，而不是 i.MX95 系统本身的启动有关。 您是否已验证在 Linux 和车载 Android 系统上，从冷启动开始，所有必需的 SW1 部分始终保持开启状态，Wi-Fi 和蓝牙初始化是否正常？请提供测试模块的部件号、电路板支持包。版本以及所需的任何其他补丁或电源/复位顺序更改。 我们的目标是在无需手动操作SW1的情况下实现可靠的初始化。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 我已经在我的 i.MX95-EVK 上多次测试过，包括同时进行 Wi-Fi 和蓝牙操作、冷 RESET 以及完全断电/开机循环。 在我的测试过程中，所有四个 SW1 开关都保持开启状态，因为 LPUART5 信号是通过这四个 JTAG 引脚传输的。开机或Wi-Fi/蓝牙初始化期间，我不会更改SW1设置。 这是我用于测试的 i.MX95-EVK 的照片。请检查您的 i.MX95-EVK 是否为相同的硬件版本。 我的设备上没有出现这个问题。 您的电路板运行情况非常不寻常。我还注意到另一点：您使用的是 Android 15.0.0_2.1.0 版本。电路板支持包。，但是您提到的内核版本与我们 BSP 中包含的实际内核版本不匹配。我不确定为什么会出现这种差异。     谢谢！ 顺祝商祺！ 卫东     Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 亲爱的卫东， 感谢您确认 Wi-Fi 和蓝牙在您的设置中能够正常工作，经过反复冷 RESET 和完全断电重启，并且所有四个 SW1 部分都保持开启状态。 我们的配置如下： 电路板：NXP i.MX95 19×19 EVK，B0 硅 模块：u-blox JODY-W263-00B，基于 88W8987，通过 M.2 适配器连接 接口：通过 SDIO 实现 Wi-Fi，通过 LPUART5 实现蓝牙 电路板支持包。：汽车 Android 15.0.0_2.1.0 先前观察到的运行内核版本： 6.12.23-4k-ge0732a9b6eb5-dirty 蓝牙 UART： /dev/ttyLP4 ，初始化波特率和运行时波特率均设置为3000000 下面列出的 Linux RX 下拉设置已在我们的运行设备树中应用并验证： IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 但是，我们仍然要求在开机和 WLAN 固件初始化期间，SW1 的 7-8 号触点保持关闭状态，然后在蓝牙运行时保持开启状态。如果这些触点在开机时处于开启状态，则 WLAN 固件激活会失败，并显示firmwarestat=0xf005错误。 我们的板将在未来两天内无法提供服务。同时，能否请您提供已验证设置的完整详细信息，以便我们将其与我们的设置进行比较，并评估哪些更改可以移植到我们的 Android 电路板支持包。中？ 请提供确切的硬件信息： Wi-Fi/蓝牙模块制造商及完整零件编号、M.2适配器零件编号/版本号，以及EVK底板/SOM版本号。请确认您是否专门测试过JODY-W263-00B模块。 具体软件：请说明所报告的成功测试是在 Linux、车载 Android 系统还是两者上进行的。对于每个测试环境，请提供电路板支持包。版本、内核版本和提交记录，最好还能提供`uname -a`命令的输出结果。您提到我们的内核版本存在差异；请确定我们所提供的电路板支持包。对应的预期内核版本。 完整的设备树更改：最终可用的电路板设备树 (DTS)，包括 DTSI 文件、所有设备树覆盖层/DTBO 源文件以及相关的版本配置。针对精确的电路板支持包。基线提供补丁将尤为重要。 驱动程序和固件： Wi-Fi 驱动程序版本/分支/提交、确切的 Wi-Fi/蓝牙固件文件名和版本，以及蓝牙 HAL/供应商配置，包括 UART 波特率和流控制。 其他必要的更改：您当前工作环境中使用的任何内核配置、引脚控制、稳压器、SDIO 电源/RESET 顺序、系统管理器、U-启动 或硬件更改。请明确确认是否需要对这些方面进行任何更改。 复现流程：从干净的电路板支持包。到工作镜像的步骤，包括所有补丁、构建目标、烧录步骤、开关/跳线位置以及冷上电测试期间使用的 Wi-Fi/蓝牙初始化序列。 请确认 Linux DTS RX 下拉包是否是解决此问题的唯一必要更改，或者您的工作镜像是否包含其他更改。 我们的目标仍然是 Automotive Android 15.0.0_2.1.0。我们希望评估将必要的更改移植到此 电路板支持包。中，目标是在启动和运行时保持所有必需的 SW1 部分开启的情况下，可靠地初始化 Wi-Fi 和蓝牙。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 亲爱的卫东， 我无法在此处上传原理图文件，因此我分享一下NXP的官方页面，其中包含这两个设计包： https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19 请从“设计文件” 下 下载： SPF-87753-B — i.MX 95 19EVK 底板设计文件 SPF-87754-B — i.MX 95 19EVK 计算模块设计文件 这些是我们在 i.MX95 19×19 EVK 设置中使用 u-blox JODY-W263-00B (88W8987) 模块时所用的原理图参考。 请您将它们与您测试过的硬件进行比较，特别是 SW1/LPUART5 路由、M.2 接口和模块电源/RESET 电路？请与我们联系，告知是否有任何差异可以解释在固件初始化期间需要断开 SW1 触点 7-8 的原因，并就所需的更改提出建议。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 看来你的 i.MX95-EVK 可能和我的不一样。请问您有采用 B0 硅片的 i.MX95 19×19 EVK 的电路图吗？您能否也分享给我一份，以便我进行比较？     谢谢！ 顺祝商祺！ 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 你好@Rakesh_Kumar_Thakur ， 我也用到了原理图。 但我这边没问题。 能否将您的 8987 Wi-Fi 模块寄给我？我想在我这边测试一下。     谢谢！ 顺祝商祺！ 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 首先，请问您的u-blox JODY-W263-00B是否使用26MHz的参考时钟？ 如果使用的是 26 MHz，则 IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e 应该是正确的设置。 请尝试以下步骤： 将四个 SW1 开关全部设置为ON并保持 ON 状态。 将 IMX95_PAD_DAP_TDI__LPUART5_RX 设置为 0x31e 。 完全关闭板电源，然后再重新开启电源。 检查WLAN固件是否可以成功初始化。 请把结果告诉我。 谢谢！ 此致， 卫东

S32K144 RTD 3.0.0:S32DS構成ツールとEBトレソスの違い こんにちは、   S32K144、S32 Design Studio 3.6.0、RTD SW32K1_S32M24x_RTD_R21-11_3.0.0_D2503、EB tresos Studio 29.0.0。 高レベルのAUTOSARドライバのみ。   EB tresosでは、PortとMCUは手作業で入力されます。S32の設定ツールでは、ピンとクロックがそれらのドライバと一緒に使われます。S32DS Dioの例では、ピンはPinsで設定され、PortPinPcrでPortに追加されます。Directionおよび関連するフィールドはPinsから入力されます。クロックツリーはClocksで設定され、MCUはその構成を名前でのみ参照します。   ピンやクロックをこのように使った後、PortやMCU、または関連モジュールで何を設定すればよいのでしょうか? 他の高レベルのドライバについてですが、設定項目や生成される結果はEB Tresosと同じですか? ピンやポート、クロックやMCU以外で、EBのトレソと設定動作が異なる場所はありますか? Re: S32K144 RTD 3.0.0: differences between S32DS Configuration Tools and EB tresos こんにちは、@Julián_AragónM さん。 詳細かつ分かりやすい説明をありがとうございました！HLD（MCAL）用に生成されるコードが全く同じで、主な違いは構成フォーマットだけだと知って安心しました。 私のプロジェクトは、独自のカスタムBSWを使用したMCALに特化したベアメタル環境であるため、EB Tresosのワークフローに厳密に従い、S32DSはコンパイルのみに使用します。 「すべてはシナリオ通りに進んでいる。」（計画通り） ご協力ありがとうございました！ よろしくお願いします、 チャオファン Re: S32K144 RTD 3.0.0: differences between S32DS Configuration Tools and EB tresos こんにちは@chaofan さん S32DSは、主にピン、クロック、ペリフェラル、DCD(デバイス構成データ)、IVT(画像ベクターテーブル)、QuadSPI、eFUSE、ICE、GTM、など、デバイス構成の編集のための視点を提供します。 DDRです。 しかし、S32K1(およびS32K MCU)はピン、クロック、ペリフェラルのみをサポートしています。設定ツールの概要からこれが確認できます: Config Tools OverviewConfig Tools Overview設定ツールの概要 高レベルドライバー(HLD)用に生成されるすべてのファイルは、S32DSとEB Tresos間で同じです。これら2つのツールの主な違いは、EB TresosはAUTOSARフォーマット(AUTOSARスキーマXML形式など)を使用しているのに対し、S32DSは.mexを使用している点ですASRスキーマ形式には従いませんが、このインターフェースを通じてNXPデバイスのプログラミングがより容易です。 よろしくお願いします、 ジュリアン Re: S32K144 RTD 3.0.0: differences between S32DS Configuration Tools and EB tresos こんにちは@chaofanさん 問題ありません。頑張ってください！ よろしくお願いします、 ジュリアン

IW610Fを同時使用モードとして使用する こんにちは、NXPチームの皆様。 IW610Fを同時使用モードで使用することについて質問があります。（村田製作所製Type2KLモジュールにて） → 「AP（Wi-Fi）」モードと「STA（Wi-Fi）」モードと「BLE」を同時に使用します。 切断せずに、3つの機能すべてを同時に使用することは可能ですか？ APとSTAモードは5G信号を同時に使うべきで、BLEは2G信号を使うべきだと思います。 この状態でも使用可能ですか？ → 村田のType2KLデータシートを見ると、 5Gと2Gを分けるフィルターがあります。    SO、 BLEは2G周波数を使うので、Wi-Fiは使えないと思います。     ですので、 APモードとSTAモードは5G周波数を一緒に使うべきだと思います。 → 私の認識では 、APは接続を保持すべきなので、STAを同時に使うのは難しいでしょう。（私の考えの背景） また、私の認識に何かおかしな点があれば、お知らせください。 IW611 エンドノード-マター-WI-FI  よろしくお願いします。 水曜日おめでとう。 Re: Using IW610F as concurrent mode こんにちは、ダニエルです。 ご返信いただき、本当にありがとうございます。 あなたが共有してくれたリンクを確認しましたが、いくつか疑問点があります。 1.「並行処理」と「共存」の機能は少し違うと思います。 そして、NXPのサイトに記載されているように、IW610シリーズは「共存」をサポートしているようです。    これにより、お客様は異なる機能を同時に使うことができます。（正確には同時ではない） 私の認識は正しいですか？ 2. 共存に関する部分を確認したところ、「AP + STA + BLE」の使用に関する具体的なコメントはありませんでした。 IW610シリーズが「AP + STA + BLE」の共存をサポートしているのは問題ないのでしょうか?    添付画像をご覧ください。「BLE + Wi-Fi」としか書かれていないので、私の考えとは合っていないと思うので、確認したいです。 また、あなたが共有してくれた別のページも確認してみました。 (mwifiex/doc/Release_Notes/Linux_RN/topics/coexistence.md at doc_WCT_release · nxp-imx/mwifiex ·GitHub) IW610シリーズは「AP+BLE」または「STA+BLE」をサポートしているようです。 ただ、「 AP+STA+BLE」についてはコメントがないので確認したいです。IW610シリーズはこれをサポートしています。 3. また、 NXPがリリースしたすべてのFW(またはSW)は、これらのページに記載されているように、この共存をサポートしているのでしょうか? あるいは、 特定のFWがこの共存をサポートしているのでしょうか? よろしくお願いします。 良い１日を。 Re: Using IW610F as concurrent mode こんにちは、 サポートされている共存シナリオについては、以下のリリースノートを参照してください。 FreeRTOS Linux よろしくお願いいたします。 ダニエル

使用 CLRC663 作为 P2P 设备 你好， 我们希望将 CLRC663 plus用作点对点 (P2P) 设备。根据数据表，CLRC663 支持符合 ISO/IEC 18092 标准的被动启动器模式下的 P2P 模式。 但这又引发了一系列问题： 两个 CLRC663 设备之间可以相互通信吗？ 如果不行，CLRC663 是否应该与其他设备组合使用？哪种更推荐？ 如何激活 ISO 18092 协议？对于其他协议，我发现AN12657至少描述了如何使用 CLRC633 上的LoadProtocol功能激活一些其他协议，但数据手册缺少有关 ISO 18092 协议的任何信息。从数据手册中也完全不清楚另外两个功能的激活方式，但可以从本应用说明中推断出来。 两个设备能否在被动启动器模式下通信？ 我几乎已经查看了论坛上所有与此相关的帖子，但没有找到任何有用的信息。我也看过 NFC读取器库，但找不到任何关于 P2P 的有用信息。 亲切的问候 Re: Using CLRC663 as P2P device 你好， 感谢您对恩智浦半导体产品的关注，也感谢您给我们提供支持的机会。 CLRC663 不完全符合 NFC Forum 标准，并且是为读写器模式设计的。因此，CLRC663 可以与支持所需目标模式的不同 NFC 设备一起使用（即 ）。HCE）。对于标准的 ISO/IEC 18092 P2P 连接，您可以考虑评估PN5190 。 但是，这种硬件方面的考虑也必须与可用的支持结合起来评估。请注意， NXP NFC读取器库声明其 P2P 功能维护已停止。虽然早期的库版本包含对传统 P2P 的支持，但我们当前的软件基线不支持 P2P 功能。 此致， 阿隆德拉 Re: Using CLRC663 as P2P device 你好， 谢谢你的回复。 我们也会研究一下PN5190。 我们有一个使用PN7150芯片的Mikroe USB Dongle ，它是否也可以用来测试这项功能？ 我主要关心的是在 CLRC663 上设置 ISO 18092 标准。对于其他协议，我已经找到了启用此功能的设置，但对于 ISO 18092 却没有。 是否可以使用两个PN5190集成电路来实现它们之间的通信？或者说，使用两个PN5190集成电路或许会更容易一些？ 顺便提一下，NFC P2P 似乎有点“过时”了，Android 大约在 7 个版本前就停止支持它了，NXP 似乎也把它视为过时的技术。这真的值得一试吗？ 亲切的问候 Re: Using CLRC663 as P2P device 你好， 请注意，Mikroe USB Dongle 不是 NXP 的产品。因此，应用程序的实现和兼容性将完全取决于加密狗制造商提供的功能和支持。 此外，不建议在新设计中使用 PN7150。NXP 已停止对 PN7150 的 Android 维护，并且不打算为更新的 Android 版本提供支持。 基于 ISO/IEC 18092 的 P2P 通信正在停止，NXP 不再提供支持。 当考虑两个 PN5190 设备时，情况也类似。由于不再支持 P2P，建议将一个 PN5190 配置为 NFC 读卡器，并将第二个设备配置为卡模拟模式，而不是实现 P2P 配置。 对于新设计，我们建议使用当前支持的 NFC 操作模式和解决方案。 顺祝商祺！ Re: Using CLRC663 as P2P device 你好， 再次感谢，您确实为我们指明了正确的方向。很明显，P2P 不是正确的发展方向。

Looking for S32_Power_Win32_v1.0_b151127 Installer (Legacy Version) Hello NXP Community, I am currently maintaining a legacy project that specifically requires S32 Design Studio for Power Architecture v1.0. I already have the installer file, but unfortunately, the .exe file is corrupted and can no longer be executed. The exact file name I need is: S32_Power_Win32_v1.0_b151127.exe I have checked the current NXP official download page, but I can only find newer versions (v1.2, v2.1, etc.). The legacy version v1.0 seems to be removed from the public download list. Could anyone (NXP staff or community members) please provide a valid download link or an archived copy of this specific version? I understand it is an old version, but it is critical for my current task. Any help would be greatly appreciated! Thank you in advance.