Unable to open probe index1. Error: Probe not open Hello, I am trying to debug the LED Blinky example on the FRDM-MCXN947, but I am running into several errors and cannot establish a debug connection to the target. Note: Another FRDM board works correctly on the same laptop, and this FRDM-MCXN947 works on a different laptop. The issue only occurs with this specific board on this specific laptop (although I have only tested this with one other laptop and one other FRDM-MCXN947). I think I may have the same problem as described here: https://community.nxp.com/t5/MCX-Microcontrollers/unable-to-open-probe-index-1/td-p/2416776 So I tried using the MCUXpresso Secure Provisioning Tool to erase the device, but that did not work for me. Any ideas what could be causing this issue, or anything else I could try to fix it? FRDM-MCXN947 Re: Unable to open probe index1. Error: Probe not open Hello @JustinNL , Thanks for your post. Since the same FRDM-MCXN947 board works correctly on another laptop, and another FRDM board also works on this laptop, the board itself is likely OK. From the screenshots, one important error is: "Failed to communicate with debug probe." This suggests that the issue may be related to the communication between the laptop and the onboard MCU-Link debug probe, rather than the application or the MCXN947 device itself. As a first step, could you please try the following:   - Close MCUXpresso IDE and MCUXpresso Secure Provisioning Tool. - Open Windows Task Manager and check whether there are any LinkServer processes still running. If so, please end task. - Disconnect the FRDM-MCXN947 from USB, wait a few seconds, and reconnect it. - Open only MCUXpresso IDE and try debugging the LED Blinky example again. If the issue still occurs, please also try a different USB port, preferably connecting the board directly to the laptop rather than through a USB hub or docking station. If these steps do not help, we can then further check the MCU-Link firmware and Windows USB device/driver status. Could you please let me know the LinkServer version used by MCUXpresso IDE, as well as the MCU-Link firmware version on your FRDM-MCXN947 board?   Regards, Celeste Re: Unable to open probe index1. Error: Probe not open Thank you for your reply. I could not find any LinkServer processes still running after closing MCUXpresso. I tried two other USB ports (three in total), all connected directly to the laptop, but I still get the same errors as before. LinkServer version: v26.9.130 (Build 130) MCU-Link firmware version: CMSIS-DAP V3.174 (running on the MCU-LINK of the FRDM-MCXN947 board) MCUXpresso IDE v25.6.136 I have attached some screenshots/pictures and hope they will be helpful. Kind regards, Justin Re: Unable to open probe index1. Error: Probe not open Hello @JustinNL , Could you please help to further check: 1. Jumper J22 and J24: shorted; jumper J21 : open 2. Check if your MCUXpresso's linkserver path configuration is Linkserver_26.9.130. BR Celeste Re: Unable to open probe index1. Error: Probe not open The jumper J22 and J24: shorted; jumper J21 : open My MCUXpresso's linkserver path configuration is Linkserver_26.9.130. Regards, Justin Re: Unable to open probe index1. Error: Probe not open Hello, I noticed there is a warning: I think the issue appears to be related to the communication between this laptop and the onboard MCU-Link debug probe. Could you please help with the following checks? 1. Check MCU-Link in Windows Device Manager With the FRDM-MCXN947 connected, please check the MCU-Link related devices in Windows Device Manager.   2. Compare the LinkServer probe detection on the working laptop On the laptop where this FRDM-MCXN947 works correctly, please use the same LinkServer version (v26.9.130) and run: LinkServer.exe probes Please provide the complete output so we can compare it with the result from the problem laptop.   3. Try the J-Link firmware As another cross-check, please switch the onboard MCU-Link to the J-Link firmware and try debugging the LED Blinky example again. This test can help determine whether the issue is specific to the CMSIS-DAP/LinkServer communication path on this laptop.   Please let me know the results of these tests. They should help us further check the issue.   Regards, Celeste Re: Unable to open probe index1. Error: Probe not open 1. The FRDM-MCXN947 appears as: MCU-LINK FRDM-MCXN947 (r0E7) CMSIS-DAP V3.128 MCU-Link VCom Port (COM3) 2. I tested LinkServer.exe probes on the laptop where the FRDM-MCXN947 works correctly using LinkServer v26.9.130. 3.  I programmed the onboard MCU-Link with the J-Link firmware using the provided program_JLINK script (Firmware_J-Link-MCU-Link_240702.s19). now debugging the LED Blinky example works correctly.   I am happy that I can use the board again now, but I am still curious about what is causing the issue with the MCU-Link firmware. Thank you very much for all your help and support so far. I really appreciate it. Regards, Justin Re: Unable to open probe index1. Error: Probe not open I'm glad to hear that it's working now. Sometimes switching to JLink firmware can resolve the issue. I can't explain this phenomenon, perhaps it's a compatibility issue, but it doesn't happen consistently. BR Celeste

S32K311 SPIに関する問題 こんにちは、 私はs32k31XEVB-Q100を使用していますが、S32K311とFS23間のSPI通信に問題があります。 私はNon-AutosarでLPSPIとSbc_fs23_Ipドライバを使っています。 SPI自体は動作していますが、Sbc_fs23_Ipにいくつか問題があります。 int main(void) { /* Write your code here */ Clock_Ip_StatusType clockStatus; volatile Sbc_fs23_Ip_StatusType sbcStatus; Std_ReturnType eReturnValue = E_NOT_OK; clockStatus = Clock_Ip_Init(&Clock_Ip_aClockConfig[0]); if (CLOCK_IP_SUCCESS != clockStatus) { exit_code = -1; } /* Initial Pins */ Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals); /* Initial ISR */ IntCtrl_Ip_Init(&IntCtrlConfig_0); IntCtrl_Ip_EnableIrq(FlexCAN0_0_IRQn); /* already enabled in IntCtrl_Ip - Interrupt Controller */ //IntCtrl_Ip_EnableIrq(FlexCAN0_1_IRQn); //IntCtrl_Ip_EnableIrq(FlexCAN0_2_IRQn); //IntCtrl_Ip_EnableIrq(FlexCAN0_2_IRQn); OsIf_Init(NULL_PTR); // FlexCAN Init FlexCAN_Ip_Init(INST_FLEXCAN_0, &FlexCAN_State0, &FlexCAN_Config0); FlexCAN_Ip_SetRxIndividualMask(INST_FLEXCAN_0,CAN_RX_MB_IDX,0xFFFFFFFF); FlexCAN_Ip_ConfigRxMb(INST_FLEXCAN_0, CAN_RX_MB_IDX, &CAN_rx_info, CAN_Rx_MSG_ID); FlexCAN_Ip_SetStartMode(INST_FLEXCAN_0); //FlexCAN_Ip_Receive(INST_FLEXCAN_0,CAN_RX_MB_IDX,&rxData,false); // LPSPI Init lpspi_status = Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_0_Instance_0); uint8 y = 0; for (uint8 x=0; x<50; x++) { txTestSpiBuffer[0] = y++; txTestSpiBuffer[1] = y++; txTestSpiBuffer[2] = y++; txTestSpiBuffer[3] = y++; //lpspi_status = Lpspi_Ip_SyncTransmit(&MASTER_EXTERNAL_DEVICE, txBuffer, rxBuffer, NUMBER_OF_BYTES, TIMEOUT); lpspi_status = Lpspi_Ip_SyncTransmit(&MASTER_EXTERNAL_DEVICE, txTestSpiBuffer, rxTestSpiBuffer, 4, ((uint32)1000000UL)); } /* Initialize Sbc driver */ Sbc_fs23_Ip_InitDriver(&Sbc_fs23_Ip_Config); /* Call function Sbc_fs23_GoToInitState to put device into INIT state*/ eReturnValue = Sbc_fs23_Ip_GoToInitState(SBC_FS23_DEVICE_ID); y = 0; for (uint8 x=0; x<50; x++) { txTestSpiBuffer[0] = y++; txTestSpiBuffer[1] = y++; txTestSpiBuffer[2] = y++; txTestSpiBuffer[3] = y++; //lpspi_status = Lpspi_Ip_SyncTransmit(&MASTER_EXTERNAL_DEVICE, txBuffer, rxBuffer, NUMBER_OF_BYTES, TIMEOUT); lpspi_status = Lpspi_Ip_SyncTransmit(&MASTER_EXTERNAL_DEVICE, txTestSpiBuffer, rxTestSpiBuffer, 4, ((uint32)1000000UL)); } まず、Lpspi-DriverのLpspi_Ip_SyncTransmitを直接使っています。これは、SPIが全体的に正常に動作しているかどうかを確認するためのものです。 その後、Sbc_fs23_Ipドライバを使います。SPIに関していくつか問題があります。 Sbc_fs23_Ipドライバの何かが再設定されているのかと思い、またLpspi-DriverのLpspi_Ip_SyncTransmitを直接使っています。 FisrtループではLpspi-ドライバを直接使うので通信は良好です。 次に、関数Sbc_fs23_Ip_GoToInitState が呼び出されます。SPI を介して複数のコマンドが送信されますが、データが正しく送信されていないようです。 その後、Lpspi_Ip_SyncTransmitを直接再び使用したところ、通信は再び良好になったようです。 Lpspi_Ip.c 内LPSPI0のTCFフラグが設定されるまで次のデータを送信するのを待てます。これは機能するが、根本的な解決策ではない。 LOCAL_INLINE void Lpspi_Ip_PushDataToFifo(uint8 Instance, uint8 NumberOfWrites) { LPSPI_Type* Base = Lpspi_Ip_apxBases[Instance]; Lpspi_Ip_StateStructureType* State = Lpspi_Ip_apxStateStructureArray[Instance]; uint32 Data = 0u; uint8 Index = 0u; /* Default data will be sent if TX buffer is null */ Data = State->ExternalDevice->DeviceParams->DefaultData; /* To increase the performance of transfer, we will reduce the checking conditions in per "for" statement so we should have more than 1 "for" * statement here */ if (NULL_PTR != State->TxBuffer) { if (State->ExternalDevice->DeviceParams->FrameSize < 9u) { for (Index = 0; Index < NumberOfWrites; Index++) { Data = *((const uint8*)(&State->TxBuffer[State->TxIndex + Index])); Base->TDR = Data; } } else if (State->ExternalDevice->DeviceParams->FrameSize < 17u) { for (Index = 0; Index < NumberOfWrites; Index++) { Data = *((const uint16*)(&State->TxBuffer[2u * (State->TxIndex + Index)])); Base->TDR = Data; } } else { for (Index = 0; Index < NumberOfWrites; Index++) { Data = *((const uint32*)(&State->TxBuffer[4u * (State->TxIndex + Index)])); Base->TDR = Data; while ((Base->SR & LPSPI_SR_TCF_MASK) == 0U) { /* NEW, WAIT TILL TCF FLAG IS SET */ } } } } else { for (Index = 0; Index < NumberOfWrites; Index++) { Base->TDR = Data; } } State->TxIndex += NumberOfWrites; } もう一つ気づいたのは、データの順序が間違っているということです。 Sbc_fs23_Ip_GoToInitState を呼び出す際、最初のコマンドは SBC_FS23_IP_M_STATUS_ADDR (0x03) を読み取ることです。 では、送信データの最初にその0x06が起こるべきでしょうか? 何が問題なのか、アイデアはありますか?ここ数日間、これらの問題に悩まされており、全く進展がありません。 Re: S32K311 SPI Issues ハイ まず考えられるのは、SPIの設定またはデータパッキングに問題がある可能性があるということです。バイトは一般的なSPI転送中にスワップされているように見えます。これはバイト指向バッファやバイトスワッピングが無効化された32ビットSPIフレームを使用する場合に起こり得ます。また、SBCがコネクテッドの間に同じPCSを汎用SPIテストに使用するのは理想的ではありません。なぜなら、SBCもそれらのテストフレームを受け取るからです。一般的なLPSPIテスト中は、別のPCSを使用するか、SBCを切断/無効化してください。 添付の main.c は、プロジェクトがS32K3 RTD 7.0.1に基づいていることを確認します。ビルド S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 。このパッケージには Sbc_fs23_Ip が含まれていますが、ソースファイルから正確なFS23 SBCドライバパッケージのバージョンを特定することはできません。添付 Blink.mex はSBCコンポーネントも識別していますが、そのパッケージリリースは含まれていません。 比較のために、最新のFS23 SBCドライバ2.0.0はS32K3 RTD 7.0.1と併用されており、利用可能なS32K312 FS23デモでは8ビット転送やチップセレクトのアサートを含む異なるSPI設定が使われています。お使いの構成を、利用可能なFS23デモと比較することをお勧めします。特に、SPIデータ幅、チップセレクト動作、および転送シーケンスについて比較してください。 BR、ペトル

launch.json 文件中的擦除 Flash 命令 您好， 我使用的是带有 MCUXpresso 扩展的 VsCode，我们使用“运行和调试”选项卡对 MIMXRT1064 进行编程/调试。我们的 launch.json 文件中有一个用于调试的有效配置。 我的问题是：我想在刷写程序之前擦除闪存中的特定区域。我该怎么做？ 我正在使用带有 Segger GDB 服务器的 J-link 探针。 我尝试过很多方法，例如： "preLaunchCommands" : [                 “监测执行 Erase 0x70000000 0x70190000” ], 的 "gdbInitCommands" : [                 “设置远程超时时间为 600” ，                 “设置调试文件目录” ，                 “不停地启动”， “flash-erase” ], 另外，`gdbInitCommands` 和 `preLaunchCommands` 中可以写入的内容有什么区别？除了 MCUX 官方文档之外，还有其他包含示例的 VSCode 文档吗？我已经阅读了配置部分的调试说明，但我仍然找不到答案。   谢谢您！ Re: Erase Flash command in launch.json file 嗨@loicING ， 非常感谢您对我们产品的关注以及对我们社区的使用。 关于您的问题，请注意，gdbInitCommands 在连接到目标之前运行，而 preLaunchCommands 在连接到目标之后立即运行。 更多详情，请参考以下链接： 1：调试 — 适用于 VS Code 的 MCUXpresso 2：Flash — 适用于 VS Code 的 MCUXpresso 对于范围擦除，请查看与您安装的版本相匹配的 SEGGER J-Link GDB 服务器文档，以确认支持的命令和语法。 您还可以在 launch.json 中启用以下日志记录选项，以检查命令响应和执行顺序： "showDevDebugOutput": "both", "showDevDebugTimestamps": true。   顺祝商祺！ 刘梅

launch.json ファイル内の Flash 消去コマンド こんにちは、 私はMCUXpresso拡張機能を搭載したVS Codeを使用しており、「実行とデバッグ」タブを使ってMIMXRT1064のプログラミングとデバッグを行っています。launch.json ファイルには、デバッグ用の有効な設定が含まれています。 私の問題は、プログラムを書き込む前に、特定のフラッシュメモリ領域を消去したいということです。どうすればいいのでしょうか? 私はJ-linkプローブとSegger GDBサーバーを使用しています。 私は次のような様々な方法を試しました。 「preLaunchCommands」 : [                 「モニター実行 消去 0x70000000 0x70190000」             ], の "gdbInitCommands" : [                 「set remotetimeout 600」 、                 「デバッグファイルディレクトリを設定」 、                 「ノンストップでオフに設定」                「フラッシュ消去」             ], また、「gdbInitCommands」と「preLaunchCommands」で書ける内容の違いは何ですか?VsCodeのMCUXドキュメント以外に例付きのドキュメントはありますか?設定のDebugセクションに赤字を入れましたが、まだ答えが見つかりません。   よろしくお願いします！ Re: Erase Flash command in launch.json file こんにちは、 @loicING さん。 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 ご質問に関してですが、gdbInitCommandsはターゲットにアタッチする前に実行されますが、preLaunchCommandsはアタッチ直後に実行されることにご注意ください。 より詳しい情報については、以下のリンクをご参照ください。 1: デバッグ — MCUXpresso for VS Code 2: フラッシュ — MCUXpresso for VS Code レンジ消去については、インストールされたバージョンに一致するSEGGER J-Link GDB Serverのドキュメントを確認し、サポートされているコマンドや構文を確認してください。 コマンドの応答や実行順序を確認するには、launch.json ファイルで以下のログ記録オプションを有効にすることもできます。 "showDevDebugOutput": "両方", "showDevDebugTimestamps": true 。   よろしくお願いいたします。 メイ・リウ

S32E288-975EVB:モーター制御GPIO、eMIOS、SAR ADCインターフェースは3.3V対応で構成可能 私は S32E288-975EVBをS32X-MBマザーボード で使用しており、 EVLキットを3.3Vのロジックレベルで動作する外部カスタムボードとインターフェースしたいと考えています。 当用途では、S32E288-975EVBの モーター制御部/コネクタ から得られる信号を使用することを望んでいます。EVBの回路図から、モーター制御セクションにはAE GPIOやレベル変換回路、さらにVDDIOD、P5V0、MOTOR1_3V3、MOTOR1_5V、MOTOR2_3V3、MOTOR2_5V供給ネットが含まれていることがわかります。 モーター制御/AEセクションPBA_GPIO[0]からPBB_GPIO[12]までのGPIOを検討しています。 eMIOS0_CH1/CH2/CH3はPWM関連機能に使用され、eMIOS1_WSC8とeMIOS1_WSC10は速度検出入力に使用されます。 1. これらのGPIOインターフェースは、EVBジャンパーの設定を変更することで、 外部モーター制御コネクタで5Vではなく3.3Vの論理レベルで動作可能か? 2. これらのeMIOSチャネルに選択された物理ピンは、3.3Vの論理レベルでEVB外部/モーター制御コネクタにも引き寄せられますか?   目標とする設定は以下のとおりです。 S32E288-975EVB + S32X-MB →モーター制御/外部コネクタ→外部カスタムボード 私たちの目標は、EVLキットのGPIO、eMIOS/PWM、速度検出およびADCインターフェースを3.3Vの外部基板と互換性のあるものに設定することです。できればジャンパーの交換のみで基板の再ワークなしで。 必要なジャンパーの構成を教えていただけますか? Re: S32E288-975EVB: Can Motor Control GPIO, eMIOS and SAR ADC interfaces be configured for 3.3V こんにちは、vishal_HoneywellAerospace 1. VDDIODはレベル変換を制御し、5Vまたは3.3Vのどちらを使用するかを決定するためにジャンパー接続が必要です。 2. モーター制御信号はPCIEインターフェースを介してS32X-MBマザーボードJ51にコネクテッドされます。変換ケーブルはお持ちですか？ 3. モーターや制御基板の動作方法について、もう少し詳しく教えていただけますか?制御する必要のあるモーターの数はいくつですか？S32E288はいくつのPWM制御信号を提供する必要があり、どの信号を収集すべきでしょうか？ BR ジョーイ Re: S32E288-975EVB: Can Motor Control GPIO, eMIOS and SAR ADC interfaces be configured for 3.3V こんにちは、 アプリケーションは「運転モーター」ではありません。 必要な要件は、PWMピン3個、ADCピン10個、GPIOピン9個、WSCピン2個です。 1. アダプタが現在入手できない場合、これらの信号はS32MX-MBのGeneralヘッダーで利用できますか？チャネル設定を変更するために開いてください。 2. 注文用のアダプター購入リンクを共有してもらえますか?

i.MX95 Neutron NPU：INT16 Conv2D 在图块边界处输出错误；是否支持 INT16？ 在 i.MX95（FRDM-IMX95、电路板支持包。 LF6.12.49_2.2.0、eIQ Neutron SDK 2.2.2）上，INT8 模型在 NPU 上运行正常，但 INT16 激活卷积会给出错误的结果。 最小测试：一个 3×3 CONV_2D（16→16 通道，输入 1×32×64×16，SAME 填充，ReLU）。我使用 NXP 的 tflite-profiler 和 tflite-quantizer（INT16 激活，INT8 权重）对其进行了量化，并使用 neutron-变流器 --target imx95 对其进行了编译。 INT8：正确。 INT16 对称：输出第 6-8 行、第 14-16 行和第 22-24 行错误；所有其他行都正确。这些是 4 个 NPU 单元边界处的行（--dump-tile-ir 显示 4 个区域，每个区域 8 行）。 INT16 不对称：所有行都错误。 将同一层重写为 1×3 卷积（单元之间不共享行）：正确。 使用 SDK 2.2.2 运行时和 SDK 3.3.0 运行时，结果相同。在 LF6.18 运行时上。 SDK 2.2.2 SupportedOperatorsS.md将 N3/N3+ 上的 Conv2DDense 内核的输入/输出列为 Int16（i.MX95 列为 N3+），但 SDK 3.3.0 SupportedOperatorsS.md将 CONV_2D、MUL、ADD 和 CONCATENATION 列为仅 INT8。 问题： i.MX95 NPU 是否支持 INT16 激活 CNN 层？ 这是已知问题吗？ Re: i.MX95 Neutron NPU: INT16 Conv2D gives wrong output at tile boundaries; is INT16 supported? 你好@SwethaRaghavendran 由于 SDK 版本之间存在差异，这是一个已知问题；因此，请参阅最新 SDK 中的文档，了解有关 CONV_2D、MUL、ADD 和 CONCATENATION 支持的量化类型的信息。 此致， 志明

无法打开探针索引1。错误：探针未打开 你好， 我正在尝试调试 FRDM-MCXN947 上的 LED 闪烁示例，但我遇到了几个错误，无法与目标建立调试连接。 注意：另一块 FRDM 板在同一台笔记本电脑上工作正常，而这块 FRDM-MCXN947 在另一台笔记本电脑上工作正常。这个问题只出现在这台特定笔记本电脑上的这块特定主板上（尽管我只在另一台笔记本电脑和另一块 FRDM-MCXN947 上测试过）。 我觉得我可能遇到了和这里描述的问题一样的问题： https://community.nxp.com/t5/MCX-Microcontrollers/unable-to-open-probe-index-1/td-p/2416776 所以我尝试使用 MCUXpresso 安全配置工具来擦除设备，但这对我不起作用。 有没有人知道可能是什么原因导致这个问题？或者还有什么其他方法可以解决这个问题？ FRDM-MCXN947 Re: Unable to open probe index1. Error: Probe not open 你好@JustinNL ， 感谢您的帖子。 由于同一块 FRDM-MCXN947 板在另一台笔记本电脑上工作正常，而另一块 FRDM 板在这台笔记本电脑上也能工作，因此该板本身可能没问题。 从截图中可以看出，一个重要的错误是： “无法与调试探针通信”。 这表明问题可能与笔记本电脑和板载 MCU-Link 调试探针之间的通信有关，而不是与应用程序或 MCXN947 设备本身有关。 首先，请您尝试以下操作：   - 关闭 MCUXpresso IDE 和 MCUXpresso 安全配置工具。 - 打开 Windows 任务管理器，检查是否还有 LinkServer 进程在运行。如果可以，请结束任务。 - 将 FRDM-MCXN947 从 USB 断开，等待几秒钟，然后重新连接。 - 只打开 MCUXpresso IDE，然后再次尝试调试 LED 闪烁示例。 如果问题仍然存在，请尝试使用不同的 USB 端口，最好将板直接连接到笔记本电脑，而不是通过 USB 集线器或扩展坞连接。 如果以上步骤无效，我们可以进一步检查MCU-Link固件和Windows USB设备/驱动程序的状态。请问您能否告知我 MCUXpresso IDE 使用的 LinkServer 版本，以及 FRDM-MCXN947 板上的 MCU-Link 固件版本？   此致， 塞莱斯特 Re: Unable to open probe index1. Error: Probe not open 感谢您的回复。 关闭 MCUXpresso 后，我找不到任何仍在运行的 LinkServer 进程。 我尝试了另外两个 USB 端口（总共三个），全部直接连接到笔记本电脑，但仍然出现与之前相同的错误。 LinkServer 版本： v26.9.130（内部版本 130） MCU-Link 固件版本： CMSIS-DAP V3.174（运行于 FRDM-MCXN947 板的 MCU-LINK 上） MCUXpresso IDE v25.6.136 我附上了一些截图/图片，希望对您有所帮助。 亲切的问候， 贾斯汀 Re: Unable to open probe index1. Error: Probe not open 你好@JustinNL ， 请您帮忙进一步核实一下： 1. 跳线 J22 和 J24：短路；跳线 J21：断开 2. 检查您的 MCUXpresso 的链路服务器路径配置是否为 Linkserver_26.9.130。 BR 塞莱斯特 Re: Unable to open probe index1. Error: Probe not open 跳线 J22 和 J24：短路；跳线 J21：断开 我的 MCUXpresso 的 linkserver 路径配置是 Linkserver_26.9.130。 问候， 贾斯汀 Re: Unable to open probe index1. Error: Probe not open 你好， 我注意到有一条警告： 我认为问题似乎与这台笔记本电脑和板载 MCU-Link 调试探针之间的通信有关。 请您帮忙进行以下核查？ 1. 在 Windows 设备管理器中检查 MCU-Link 连接 FRDM-MCXN947 后，请在 Windows 设备管理器中检查与 MCU-Link 相关的设备。   2. 对比工作笔记本电脑上的 LinkServer 探测结果 在 FRDM-MCXN947 工作正常的笔记本电脑上，请使用相同的 LinkServer 版本 (v26.9.130) 并运行以下命令： LinkServer.exe 探测 请提供完整的输出结果，以便我们将其与出现问题的笔记本电脑的结果进行比较。   3. 尝试使用 J-Link 固件 作为另一项交叉检查，请将板载 MCU-Link 切换到 J-Link 固件，然后再次尝试调试 LED 闪烁示例。 此测试可以帮助确定问题是否仅限于此笔记本电脑上的 CMSIS-DAP/LinkServer 通信路径。   请告知我这些测试结果。他们应该协助我们进一步调查这个问题。   此致， 塞莱斯特 Re: Unable to open probe index1. Error: Probe not open 1. FRDM-MCXN947 的外观如下： MCU-LINK FRDM-MCXN947 (r0E7) CMSIS-DAP V3.128 MCU-Link VCom 端口 (COM3) 2. 我在笔记本电脑上测试了 LinkServer.exe 探测，FRDM-MCXN947 在该笔记本电脑上使用 LinkServer v26.9.130 可以正常工作。 3. 我使用提供的 program_JLINK 脚本（Firmware_J-Link-MCU-Link_240702.s19）对板载 MCU-Link 进行了 J-Link 固件编程。 现在调试 LED 闪烁示例程序可以正常工作了。 @Smartling Language Service 我很高兴现在又能使用这块板了，但我仍然很好奇是什么原因导致了 MCU-Link 固件的问题。非常感谢您迄今为止给予的所有帮助和支持。我非常感谢。 问候， 贾斯汀 Re: Unable to open probe index1. Error: Probe not open 很高兴听到它现在可以正常工作了。有时切换到 JLink 固件可以解决问题。我无法解释这种现象，也许是兼容性问题，但它并非总是发生。 BR 塞莱斯特

S32K311 SPI 问题 你好， 我正在使用 s32k31XEVB-Q100，但在 S32K311 和 FS23 之间建立 SPI 通信时遇到了一些问题。 我在非Autosar环境下使用Lpspi和Sbc_fs23_Ip驱动程序。 SPI 本身工作正常，但我在使用 Sbc_fs23_Ip 时遇到了一些问题。 int main(void) { /* Write your code here */ Clock_Ip_StatusType clockStatus; volatile Sbc_fs23_Ip_StatusType sbcStatus; Std_ReturnType eReturnValue = E_NOT_OK; clockStatus = Clock_Ip_Init(&Clock_Ip_aClockConfig[0]); if (CLOCK_IP_SUCCESS != clockStatus) { exit_code = -1; } /* Initial Pins */ Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals); /* Initial ISR */ IntCtrl_Ip_Init(&IntCtrlConfig_0); IntCtrl_Ip_EnableIrq(FlexCAN0_0_IRQn); /* already enabled in IntCtrl_Ip - Interrupt Controller */ //IntCtrl_Ip_EnableIrq(FlexCAN0_1_IRQn); //IntCtrl_Ip_EnableIrq(FlexCAN0_2_IRQn); //IntCtrl_Ip_EnableIrq(FlexCAN0_2_IRQn); OsIf_Init(NULL_PTR); // FlexCAN Init FlexCAN_Ip_Init(INST_FLEXCAN_0, &FlexCAN_State0, &FlexCAN_Config0); FlexCAN_Ip_SetRxIndividualMask(INST_FLEXCAN_0,CAN_RX_MB_IDX,0xFFFFFFFF); FlexCAN_Ip_ConfigRxMb(INST_FLEXCAN_0, CAN_RX_MB_IDX, &CAN_rx_info, CAN_Rx_MSG_ID); FlexCAN_Ip_SetStartMode(INST_FLEXCAN_0); //FlexCAN_Ip_Receive(INST_FLEXCAN_0,CAN_RX_MB_IDX,&rxData,false); // LPSPI Init lpspi_status = Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_0_Instance_0); uint8 y = 0; for (uint8 x=0; x<50; x++) { txTestSpiBuffer[0] = y++; txTestSpiBuffer[1] = y++; txTestSpiBuffer[2] = y++; txTestSpiBuffer[3] = y++; //lpspi_status = Lpspi_Ip_SyncTransmit(&MASTER_EXTERNAL_DEVICE, txBuffer, rxBuffer, NUMBER_OF_BYTES, TIMEOUT); lpspi_status = Lpspi_Ip_SyncTransmit(&MASTER_EXTERNAL_DEVICE, txTestSpiBuffer, rxTestSpiBuffer, 4, ((uint32)1000000UL)); } /* Initialize Sbc driver */ Sbc_fs23_Ip_InitDriver(&Sbc_fs23_Ip_Config); /* Call function Sbc_fs23_GoToInitState to put device into INIT state*/ eReturnValue = Sbc_fs23_Ip_GoToInitState(SBC_FS23_DEVICE_ID); y = 0; for (uint8 x=0; x<50; x++) { txTestSpiBuffer[0] = y++; txTestSpiBuffer[1] = y++; txTestSpiBuffer[2] = y++; txTestSpiBuffer[3] = y++; //lpspi_status = Lpspi_Ip_SyncTransmit(&MASTER_EXTERNAL_DEVICE, txBuffer, rxBuffer, NUMBER_OF_BYTES, TIMEOUT); lpspi_status = Lpspi_Ip_SyncTransmit(&MASTER_EXTERNAL_DEVICE, txTestSpiBuffer, rxTestSpiBuffer, 4, ((uint32)1000000UL)); } 首先，我直接使用 Lpspi-Driver 中的 Lpspi_Ip_SyncTransmit。这只是为了确认SPI总体上是否正常工作。 然后我使用 Sbc_fs23_Ip 驱动程序。我这里SPI接口有些问题。 因为我怀疑 Sbc_fs23_Ip 驱动程序中可能存在某些重新配置的情况，所以我再次直接使用了 Lpspi-Driver 中的 Lpspi_Ip_SyncTransmit。 在第一循环中，我直接使用 Lpspi-Driver，通信看起来不错。 然后调用函数 Sbc_fs23_Ip_GoToInitState。同时，通过 SPI 发送了多个命令，但数据似乎没有正确发送。 之后我再次直接使用了 Lpspi_Ip_SyncTransmit，通信看起来又正常了。 在 Lpspi_Ip.c我可以等到 LPSPI0 的 TCF 标志位被设置后再发送下一条数据。这种方法可行，但不应该作为最终解决方案。 LOCAL_INLINE void Lpspi_Ip_PushDataToFifo(uint8 Instance, uint8 NumberOfWrites) { LPSPI_Type* Base = Lpspi_Ip_apxBases[Instance]; Lpspi_Ip_StateStructureType* State = Lpspi_Ip_apxStateStructureArray[Instance]; uint32 Data = 0u; uint8 Index = 0u; /* Default data will be sent if TX buffer is null */ Data = State->ExternalDevice->DeviceParams->DefaultData; /* To increase the performance of transfer, we will reduce the checking conditions in per "for" statement so we should have more than 1 "for" * statement here */ if (NULL_PTR != State->TxBuffer) { if (State->ExternalDevice->DeviceParams->FrameSize < 9u) { for (Index = 0; Index < NumberOfWrites; Index++) { Data = *((const uint8*)(&State->TxBuffer[State->TxIndex + Index])); Base->TDR = Data; } } else if (State->ExternalDevice->DeviceParams->FrameSize < 17u) { for (Index = 0; Index < NumberOfWrites; Index++) { Data = *((const uint16*)(&State->TxBuffer[2u * (State->TxIndex + Index)])); Base->TDR = Data; } } else { for (Index = 0; Index < NumberOfWrites; Index++) { Data = *((const uint32*)(&State->TxBuffer[4u * (State->TxIndex + Index)])); Base->TDR = Data; while ((Base->SR & LPSPI_SR_TCF_MASK) == 0U) { /* NEW, WAIT TILL TCF FLAG IS SET */ } } } } else { for (Index = 0; Index < NumberOfWrites; Index++) { Base->TDR = Data; } } State->TxIndex += NumberOfWrites; } 我还发现数据顺序错误。 调用Sbc_fs23_Ip_GoToInitState 时，第一个命令是读取 SBC_FS23_IP_M_STATUS_ADDR (0x03) 所以 0x06 应该位于传输数据的开头吗？ 你知道可能是什么问题吗？这些问题已经困扰我好几天了，我一直无法取得任何进展。 Re: S32K311 SPI Issues HI 初步猜测，可能是 SPI 配置或数据打包不正确。在通用 SPI 传输过程中，字节似乎发生了交换，这种情况在使用面向字节的缓冲区且禁用字节交换的 32 位 SPI 帧时可能会发生。此外，当 SBC 连接时，使用同一个 PCS 进行通用 SPI 测试并不理想，因为 SBC 也会接收到这些测试帧。请在进行通用 LPSPI 测试时使用单独的 PCS 或断开/禁用 SBC。 附件 main.c 确认该项目基于S32K3 RTD 7.0.1 ，版本 S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 。它包含并使用 Sbc_fs23_Ip ，但无法从源文件中确定确切的 FS23 SBC 驱动程序包版本。附件 Blink.mex 也标识了 SBC 元器件，但没有包含其软件包版本。 为了进行比较，最新的 FS23 SBC 驱动程序 2.0.0 与 S32K3 RTD 7.0.1 一起使用，而可用的 S32K312 FS23 演示程序使用了不同的 SPI 设置，包括 8 位传输和片选信号保持钳位。我建议您将您的配置与可用的 FS23 演示进行比较，特别是 SPI 数据宽度、片选行为和传输序列。 BR，彼得

S32E288-975EVB：电机控制GPIO、eMIOS和SAR ADC接口能否配置为3.3V 我正在使用S32E288-975EVB 和 S32X-MB 主板，并且想将 EVL 套件与工作在3.3 V 逻辑电平的外部定制板连接。 对于我们的应用，我们更倾向于使用 S32E288-975EVB 的电机控制部分/连接器提供的信号。从EVB原理图可以看出，电机控制部分包括AE GPIO和电平转换电路，以及VDDIOD、P5V0、MOTOR1_3V3、MOTOR1_5V、MOTOR2_3V3和MOTOR2_5V电源网络。 我们正在考虑电机控制/AE部分的GPIO，从PBA_GPIO[0]到PBB_GPIO[12]， eMIOS0_CH1/CH2/CH3 用于 PWM 相关功能，而 eMIOS1_WSC8 和 eMIOS1_WSC10 将用于速度感知输入。 1. 能否通过改变 EVB 跳线配置，使这些 GPIO 接口在外部电机控制连接器处以 3.3V 逻辑电平（而不是 5V）运行？ 2. 能否将这些 eMIOS 通道选择的物理引脚也以 3.3V 逻辑电平 引至 EVB 外部/电机控制连接器 ？   我们的目标设置是： S32E288-975EVB + S32X-MB → 电机控制/外部连接器 → 外部定制板 我们的目标是配置 EVL 套件，使GPIO、eMIOS/PWM、速度感知和 ADC 接口与 3.3 V 外部板兼容，最好仅通过跳线更改而无需对电路板进行返工。 请问能否提供所需的跳线配置？ Re: S32E288-975EVB: Can Motor Control GPIO, eMIOS and SAR ADC interfaces be configured for 3.3V 您好，vishal_HoneywellAerospace 1.VDDIOD 控制电平转换，需要跳线连接来确定应该使用 5V 还是 3.3V。 2.控制电机的信号通过PCIE接口连接到S32X-MB主板J51。你有转接线吗？ 3.请问能否提供关于贵公司电机和控制板工作原理的更详细信息？需要控制多少台电机？S32E288 需要提供多少个 PWM 控制信号，需要采集哪些信号？ BR 乔伊 Re: S32E288-975EVB: Can Motor Control GPIO, eMIOS and SAR ADC interfaces be configured for 3.3V 您好， 该应用程序并未驱动电机。 要求是 3 个 PWM、10 个 ADC、9 个 GPIO 和 2 个 WSC。 1. 由于目前没有适配器，这些信号是否在 S32MX-MB 的通用标头中可用？打开以更改频道配置。 2. 能否分享一下适配器的购买链接以便我下单？

IMX8QXP Differential/ Partial OTA development Hi Team, IMX8QXP - Scarthgap  - L 6.6.52 Can you please share the document or reference for differential OTA/ Partial OTA development for IMX8QXP yocto.  Thanks & regards, VKS i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: IMX8QXP Differential/ Partial OTA development Hi, One approach worth looking at for differential OTA updates is OSTree. At Toradex, we use OSTree in Torizon OS to manage OS updates, transferring only the objects that aren't already available on the device instead of downloading the entire rootfs. It's not a ready-made solution for your specific Yocto setup, but our update architecture might be a useful reference: https://developer.toradex.com/torizon/torizon-platform/torizon-updates/torizon-updates-architecture/ Best regards, Daniel Morais Re: IMX8QXP Differential/ Partial OTA development Hi, Currently I am doing like this ### Partial 1: Initial Full OTA (1) to Full OTA (2 - Full OTA (1): Base version. - Full OTA (2): Target version. Take the diff between Full OTA (1) and Full OTA (2) to identify the changed files. Developed the SWU file containing the changed rootfs files along with other required files. During the update: 1. Mount the inactive (next) slot. 2. Copy the changed files to their respective locations in the inactive slot. 3. Unmount the slot. 4. Reboot the device from the updated slot. After switching from the current slot to the next slot, synchronize both slots to the same configuration. This ensures that both slots are aligned and ready for the upcoming differential OTA update. ## Partial 2: Full OTA (2) to Full OTA (3) - Full OTA (2): Base version. - Full OTA (3): Target version. Use the updated Full OTA (2) as the base and Full OTA (3) as the target. Take the diff between both versions to identify the changed files. Generate the differential SWU package containing the changed files and required update components. Apply the update to the inactive slot, reboot from the updated slot, and synchronize both slots to the same configuration. ## Partial 3: Full OTA (3) to Full OTA (2) - Full OTA (3): Base version. - Full OTA (2): Target version. Use the updated Full OTA (3) as the base and Full OTA (2) as the target. Take the diff between both versions to identify the changed files. Generate the differential SWU package containing the changed files and required update components. Apply the update to the inactive slot, reboot from the updated slot, and synchronize both slots to the same configuration. ## Overall Update Flow Full OTA (1) Initial Base Differential OTA (1 → 2) Full OTA (2) Updated Base Differential OTA (2 → 3) Full OTA (3) Updated Base Differential OTA (3 → 2) Full OTA (2) Back to Previous Version Key point: After every successful OTA update, synchronize both slots so that the next differential OTA can be generated using the currently updated version as the base. Can you please check my approach. Thanks & regards, VKS

DD_COREコネクティビティ MCX Nシリーズの172HDQFPパッケージには2本のVDD_COREピン(ピン16とピン105)があります。LDOモードではピン16が出力、DCDCモードではピン105が入力のようです。 BGAパッケージを使用する評価ボードの回路図では、2つのVDD_COREピンが基板上でショートしますが、これは2つのボールがパッケージ内で隣接しているため問題ありません。しかし、172ピンパッケージでは、ピン16とピン105の2本がパッケージの反対側にあり、ボード上のVDD_COREピン2本をショートさせる予定はありません。 LDOモードでボード上で2つのVDD_COREピンがコネクテッドでなければ問題になりますか?各VDD_COREピンにはコンデンサが付けられており、UG10092ハードウェア設計ガイドで説明されています。 よろしくお願いいたします。 サティシュ MCX N パワー

Using wwdt0 mcxa145vll Hello, I’m using the MCXA145VLL microcontroller and I have a question about the WWDT0. These are my settings: I use it to reset the firmware after 250 ms in case it freezes. In certain parts of my firmware, I deliberately include a `while(1)` loop to allow for this reset. Is it the right choice to use the windowed watchdog? I’ve noticed that the watchdog works correctly with an hardware but not with another – is there anything that might be blocking the WWDT, or is there anything I need to be aware of? Thanks in advanced. Best regards. Re: Using wwdt0 mcxa145vll Hello @Transidico , Thanks for your post. Using the WWDT this way is fine. When you say “the watchdog works correctly on one hardware platform but not on another,” do you mean two different boards? I suggest checking the WWDT0 clock configuration first. Use CLOCK_GetWdtClkFreq(0) to get the configured watchdog clock frequency, and compare the result on both boards. Also compare the relevant clock registers after WWDT initialization. Checking the reset-cause flags can help confirm whether a watchdog reset occurred. I also recommend using the WWDT demo in our SDK as a reference: I hope this helps. BR Celeste

正在寻找批量采购的 NTAG215 11x21MM 湿式镶嵌件 我正在寻找NXP NTAG215 11x21MM湿式镶嵌贴纸的批量货源，但除了速卖通之外，很难找到提供批发价格的网站。 我找到一个网站，1000 件售价为每件 0.12 美元。 但是这些是 NTAG213，而我需要的是密码保护。 如果问错地方了，我先道个歉。不过我觉得这里应该有人知道，而且我也读到过恩智浦（NXP）是兼容性最广的芯片组。 感谢您抽出时间。 Re: Trying to source NTAG215 11x21MM wet inlay in bulk 如果你需要的话，我可以推荐给你。 Re: Trying to source NTAG215 11x21MM wet inlay in bulk 你好， 感谢您对恩智浦半导体产品的关注，也感谢您给我们提供支持的机会。 请注意，NXP 不销售成品镶嵌贴纸等最终解决方案。在NTAG 215 产品页面的“工程服务”部分，您可以找到我们的授权合作伙伴，他们可以帮助您处理嵌体贴纸的请求。 我们建议您联系这些授权合作伙伴之一，因为从未经授权的渠道购买的 NXP 产品可能是假冒产品、损坏的产品或其他不适合使用的产品。 希望这些信息能帮助您找到适合您应用场景的解决方案。 此致， 阿隆德拉

Trying to source NTAG215 11x21MM wet inlay in bulk I am trying to source a bulk order of NXP NTAG215 11x21MM wet inlay stickers but am having trouble finding a site with wholesale pricing besides aliexpress.  I have found one site offering 1000pc for $0.12USD/pc however those are NTAG213 and I am looking for password protection. I apologize if this is not an appropriate place to ask, however I figured someone here would know, as well as I had read that NXP is the most widely compatible chip base.| Thank you for your time. Re: Trying to source NTAG215 11x21MM wet inlay in bulk If you need it, I can recommend it to you. Re: Trying to source NTAG215 11x21MM wet inlay in bulk Hello, Thank you for your interest in NXP Semiconductors products and for the opportunity to support you. Please note that NXP does not sell end solutions such as finished inlay stickers. On the NTAG 215 product page, under Engineering Services, you can find our authorized partners who may assist you with your request for inlay stickers. We recommend contacting one of these authorized partners, as NXP products purchased from unauthorized sources may be counterfeit, damaged, or otherwise unsuitable for use. I hope this information helps you find the right solution for your application. Best regards, Alondra

使用 wwdt0 mcxa145vll 你好， 我正在使用 MCXA145VLL 微控制器，我对 WWDT0 有一个疑问。我的设置如下： 我用它来在固件死机后 250 毫秒内 RESET 固件。在我的固件的某些部分，我特意加入了一个 `while(1)` 循环，以便进行这种 RESET。使用窗口式看门狗是正确的选择吗？ 我注意到看门狗在一个硬件上工作正常，但在另一个硬件上却不行——是不是有什么因素阻碍了 WWDT，或者我有什么需要注意的地方？ 先谢谢了。 顺祝商祺！ Re: Using wwdt0 mcxa145vll 你好@Transidico ， 感谢你的帖子。 这样使用 WWDT 是可以的。 当你说“看门狗在一个硬件平台上工作正常，但在另一个硬件平台上工作不正常”时，你指的是两个不同的板吗？ 我建议先检查 WWDT0 时钟配置。使用 CLOCK_GetWdtClkFreq(0) 获取配置的看门狗时钟频率，并比较两个板上的结果。此外，还要比较 WWDT 初始化后的相关时钟寄存器。检查 RESET 原因标志可以帮助确认是否发生了看门狗 RESET。 我还建议参考我们 SDK 中的 WWDT 演示： 希望这能帮到你。 BR 塞莱斯特

IW612 bluetooth crash after a few days Hello, One of our users reported us a bug with the murata LBES5PL2EL-923 (IW612 core) bluetooth functionality, where the bluetooth stack crashes after a few days connected to a device over bluetooth static RFCOMM/SPP (The original report is public and available in Japanese at https://armadillo.atmark-techno.com/forum/armadillo/31772 ) Are there any known bugs about this? Software setup: * linux 6.12 based on lf-6.12.49-2.2.0 (exact source tree: https://github.com/atmark-techno/linux-6.12-at/tree/6.12.105-r0 ) this is a BT problem but in case it matters the wireless driver is based on mwifiex lf-6.12.49-2.2.0 * firmware updated to the latest from the imx-firmware repo at lf-6.18.20_2.0.0 https://github.com/nxp-imx/imx-firmware/tree/lf-6.18.20_2.0.0/FwImage_IW612_SD * BlueZ stack (currently confirming the exact version, sorry I forgot to ask) * the board is connected to a single device over *bluetooth classic* (not BLE), with RFCOMM/SPP. Every 60 seconds the application sends a message and gets a reply (simple polling). After a few days there is a command timeout and the BT driver restarts I've attached a firmware dump (obtained from /sys/class/bluetooth/hci0/devcoredump/data after crash happened), assuming it can be useful, there is no message in dmesg until the crash (I'm sorry it's truncated before the "Start FW dump" message so there is no timestamp for these, my understanding is that it was immediately afterwards) The FW reloading mechanism works, but this requires a reconnection so would be better addressed if possible. [ 0.000000] Linux version 6.12.105-0-at (builder@71056255c5a6) (aarch64-alpine-linux-musl-cc (Alpine 15.2.0) 15.2.0, GNU ld (GNU Binutils) 2.45.1) #1-Alpine SMP PREEMPT Mon Aug 24 07:48:35 UTC 2026 [...] [ 9.321032] wlan: version = SDIW612---18.99.8.p52-MM6X18540.p33-GPL-(FP92) [...] [ 10.349326] Bluetooth: hci0: FW already running. [ 38.303160] Bluetooth: MGMT ver 1.23 [170117.376944] Bluetooth: hci0: command tx timeout Bluetooth: hci0: ==== Start FW dump === Bluetooth: hci0: ==== FW dump complete === Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se Bluetooth: hci0: FW Download Complete: 412940 bytes If there is any other information that would be useful for analysis please ask Thank you Re: IW612 bluetooth crash after a few days > 1.Is it possible to provide us the HCI logs as well as that will help to identify which command is getting timeout for which the firmware dump is getting generated. Could you clarify what you mean with this? Is there a command that can be run after the fact, or should we run hcidump or equivalent to dump all commands while the process is running? > 3.To get Wi-Fi driver loading parameters, you can provide us the: /lib/firmware/nxp/wifi_mod_para.conf We do not use this file so default parameters should be used here as well. We've reduced the log level from the default values so dmesg will not be of much help here either (I sent a link to dmesg in the previous reply) I'll check with our user if they use wifi at all during this time Re: IW612 bluetooth crash after a few days Hi, @martinetd  1.Is it possible to provide us the HCI logs as well as that will help to identify which command is getting timeout for which the firmware dump is getting generated. 2.Can you please provide the WLAN based use case as WLAN is running then check if WLAN is working fine during the firmware dump is getting generated? 3.To get Wi-Fi driver loading parameters, you can provide us the: /lib/firmware/nxp/wifi_mod_para.conf  or you can provide us a normal booting dmesg logs which including the whole process that WiFi/bluetooth loading. We can get the info from dmesg logs. 4.Currently, we do not have newer public github FW release than the one you are using: imx-firmware/FwImage_IW612_SD at lf-6.18.20_2.0.0 · nxp-imx/imx-firmware · GitHub So, I do not think this is an known issue. We prefer to have more info related to the use case and hci logs to track what happened or reproduce steps so that we can reproduce the issue locally. So if you have any further other info related to the issue, please share with us. Best regards, Christine. Re: IW612 bluetooth crash after a few days Hi @Christine_Li thank you for the quick reply > 1. If you are using btnxpuart driver, please help to provide me btnxpuart.c. We are using the btnxpuart provided in https://github.com/nxp-imx/linux-imx based on version lf-6.12.49-2.2.0 , you can find the exact file here https://github.com/atmark-techno/linux-6.12-at/blob/6.12.105-r0/drivers/bluetooth/btnxpuart.c > 2. Are you using Wi-Fi and Bluetooth/802.15.4 combo FW? Or you are using separate FW? We are using both: the wifi driver loads the combo FW at boot, and after crash the separate FW is reloaded (hence log naming the separate FW) When this crash happened the combo FW was loaded (first crash after boot) but my understanding is that it reproduces with both > 3. Can you please help to provide your Wi-Fi and Bluetooth driver load parameters? The only wifi parameter we explicitly set is drv_mode = 0x3 to disable the wifi direct interface we do not use; we do not set any bluetooth parameter. If you can tell me how to dump the exact settings I can ask our user to run commands to get the info for us. > 4.Can you please let me know your detailed reproduce steps? Since this is based on a user report I can't say much more than the description I gave (RFCOMM connection polled every 60s for a few days); I'm afraid it might depend on the actual sub device the chip is connected to. I'll try to find a device that can be pinged over RFCOMM and reproduce locally to provide you with a test script if that helps, but for now I couldn't find any release note with known bugs for the firmware/btnxpuart driver so I'd like to confirm if there is a known bug (and hopefully if you can get any information from the firmware dump) Thank you Re: IW612 bluetooth crash after a few days Hi, @martinetd  1.Are you using our nxp's btnxpuart driver for bluetooth? or you are using Linux Open Source Uart driver? If you are using btnxpuart driver, please help to provide me btnxpuart.c. 2.Are you using Wi-Fi and Bluetooth/802.15.4 combo FW? Or you are using separate FW? Because I see your log as below, so I just suspect you are using separate FW, need to double confirm with you. hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se 3.Can you please help to provide your Wi-Fi and Bluetooth driver load parameters? 4.Can you please let me know your detailed reproduce steps?  Best regards, Christine. Re: IW612 bluetooth crash after a few days > * BlueZ stack (currently confirming the exact version, sorry I forgot to ask) in case it matters, the BlueZ version is 5.82 Re: IW612 bluetooth crash after a few days Hi, @martinetd  1.For btmon: ==>Yes, if we could record the whole process for size reason, then I think the method you recommend would be a good idea. And also, we have not other better ideas than that one. 2.For FW dump: I will recommend to load driver with drvdbg=0xa0037, it can record more fw dump and also driver dump logs for analysis.   issue happened   logs will automatically save in this directory like below:   ======================================== [ 4221.173141] Create directory /data/dump_4220 error, try create dir in /var [ 4221.173147] Wakeup device... [ 4221.173231] Create directory /var/dump_4220 successfully [ 4221.173232] Directory name is /var/dump_4220 [ 4221.173233] === START DRIVER INFO DUMP=== [ 4221.173289] DRV dump data in /var/dump_4220/file_drv_info [ 4221.173306] Wakeup device... [ 4221.173889] SDIO Func0 (0x0-0x9): 43 03 06 00 07 00 00 02 03 00 [ 4221.175173] SDIO Func1 (0x4-0xb): 00 00 00 00 ff ff ff ff [ 4221.175879] SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00 [ 4221.176284] SDIO Func1 (0xc0-0xca): dc fe 96 00 31 11 00 37 37 02 20 [ 4221.177301] | [ 4221.275861] SDIO Func1 (0xc0-0xca): dc fe a1 00 3b 00 00 37 37 02 20 [ 4221.276501] Drv info total bytes = 263150 (0x403ee) [ 4221.276503] === DRIVER INFO DUMP END===Wakeup device... [ 4221.276555] ==== DEBUG MODE OUTPUT START: 4220.878602 === ====================================================   If the dump is not auto-generated at "/var" or "/data" it can be collected manually using below "cat /proc/mwlan/adapter0/fw_dump > file_fw_dump" command.     2. If you check it doesn't print the directory in dmesg logs or in your case, you decrease the log level, then please get it in below way:   - echo debug_dump > /proc/mwlan/adapter0/config - Wait for some time (1 or 2 min) for fw_dump: - cat /proc/mwlan/adapter0/fw_dump > file_fw_dump for drv_dump: cat /proc/mwlan/adapter0/drv_dump > file_drv_dump   For such kind of FW crash issue, btmon log is the extended logs to better understand customer's use case and also issue scenarios. FW_dump is the most important logs for us.    And also, as discussed before, please also ask your customer about wifi use case during this test.   Best regards, Christine. Re: IW612 bluetooth crash after a few days > btmon Thank you for clarifying The crash takes a couple of days to reproduce, and I'm afraid it might not be practical to store/share a full log given how big it gets (I see 100KB after a minute so ~300MB in 2 days) Unfortunately btmon does not seem to have a "cyclic recording" mode like tcpdump, but if you're only interested in the few minutes before the crash then I can request our customer logs alternating two files every e.g. 5 minutes so we can get the last 5 minutes? Would something like (untested) be acceptable, sending the last samples? (note there is a small window between runs where events are not logged...) I=0; while ! [ -e /sys/class/bluetooth/hci0/devcoredump/data ]; do timeout 300s btmon -K -t -w log.$I; I=$((I+1%3)); done > coredump not readable Ok, this is a shame but there is not much to do about it. The file was obtained reading from /sys/class/bluetooth/hci0/devcoredump/data after the FW dump complete message, if that is not appropriate or there is a better way to get useful data I'll be happy to oblige but let's focus on the btmon traces for now. Thank you Re: IW612 bluetooth crash after a few days Ok for btmon, I will request that (and ask about wifi usage) I'd like to confirm fw dump first though: the dump I obtained was a bluetooth dump, but you seem to describe a wireless dump. In the traces from customer the wifi driver did not seem to crash, so I believe drvdbg= will not be effective there? Also in case you do need the wireless firmware in the combined firmware case (with `echo debug_dump > /proc/mwlan/adapter0/config`), the problem is that the BT driver automatically reloads a new firmware and restarts the adapter, so we would need to disable the firmware loading for this to work I agree having a dump is useful for analysis so if it's possible to fix the way the dump is obtained I'd like to know first, I'll ask our customer everything at once after we're clear on what to do Thanks Re: IW612 bluetooth crash after a few days Hi, @martinetd  Could you clarify what you mean with this? Is there a command that can be run after the fact, or should we run hcidump or equivalent to dump all commands while the process is running? ==>hci log can be captured after enabled Bluetooth/BLE with below commands: btmon -w failed_snoop.log & Then customer execute their reproduce steps, and try to reproduce this issue. The failed_snoop.log will record all of the process of bluetooth/BLE. Once issue is reproduced, we can check this log to see what kind of commands/events are executing, so that we will have some related suspects. It is not a command to run and capture the failed logs after FW crash. By the way, I requested our internal expert team help to decrypt the provided fw dump bin file: fw_devcorecump.bin, but unfortunately, it is not getting decrypted  successfully. It seems like file is corrupt or not having enough data so not able to decrypt. Best regards, Christine. Re: IW612 bluetooth crash after a few days Hi, @martinetd  Yes, you are right.  Because the issue is difficult to reproduce, we also prefer to capture full logs that we need. I checked with our internal team that from BSP 6.12.34 onward, the btnxpuart kernel module detects that IW612 narrowband firmware is stuck. It proceeds automatically with a recovery process by resetting the narrowband CPU and downloading it again. The BT FW dump will automatically generate. When command timeout happens, at that time it will generate. So, you are right. Do not need to provide Wi-Fi dump and only provide BT FW dump and also hci logs if possible. And also about WiFi use case and scenarios, please also help to provide. Best regards, Christine. Re: IW612 bluetooth crash after a few days hi @Christine_Li  Sorry for the slow reply we're in the middle of public holidays here > Because the issue is difficult to reproduce, we also prefer to capture full logs that we need. Ok, I will try to get as much as possible from the customer and also see if I can reproduce myself over the next week or two > I checked with our internal team that from BSP 6.12.34 onward, the btnxpuart kernel module detects that IW612 narrowband firmware is stuck. It proceeds automatically with a recovery process by resetting the narrowband CPU and downloading it again. The BT FW dump will automatically generate. When command timeout happens, at that time it will generate. > So, you are right. Do not need to provide Wi-Fi dump and only provide BT FW dump and also hci logs if possible. And also about WiFi use case and scenarios, please also help to provide. Thank you for confirming the Wi-Fi dump is not needed, but that leaves me in a pinch about the BT dump: The dump I sent in the original post comes from what the btnxpuart module automatically generated, and I have no reason to believe it was truncated (the size is similar to what I get when I artificially generate a dump by writing 1 to /sys/class/bluetooth/hci0/device/coredump ) The way it was obtained was just reading (cat) from the data file after the crash was complete: cat /sys/class/bluetooth/hci0/devcoredump/data > fw_dump Is there a more appropriate way to get the dump? Also, please forgive the naive question, but was the dump I sent opened as a BT dump? I'll recap everything to our customer tomorrow regardless of this point, but I'm quite worried that we'll just send a new dump that won't be openable again, so it'd be great to clear this up. Thank you Dominique Re: IW612 bluetooth crash after a few days Hi, @martinetd  Thanks for your feedback.  About FW dump. Yes, I totally understood your concerns about FW dump. So, I double checked with our internal team and also double checked our Application Note document: AN14710. The procedure followed by you to capture FW dump appears to be correct, specifically for the BTNXPUART driver. I will check with our internal expert team to see if they can identify any useful information from the current your shared dump file.  There might be something else need to be done which I am not aware so I will check with core R&D team. For HCI log. In the meantime, please also help obtain the HCI logs from your end customer. This will allow us to analyze the HCI command sequence and determine whether we can reproduce the issue on our side. For Driver and FW version: Besides, to double confirm the FW and Driver version, please also help to read it from board. I know you already mentioned that you are using: Driver: mwifiex lf-6.12.49-2.2.0 FW: lf-6.18.20_2.0.0 https://github.com/nxp-imx/imx-firmware/tree/lf-6.18.20_2.0.0/FwImage_IW612_SD But if you can read it from the board dmesg logs, it will double confirm for us. Thanks a lot. dmesg | grep wlan Then it will show the WiFi and FW version like below: [ 7.573794] wlan: version = SDIW612---18.99.8.p52--MM6X18543.p18-GPL-(FP92) Other info. Also for your information, we do not encourage to use the mismatched Driver and FW. For example: you are using driver based on lf-6.12.49-2.2.0, but FW is based on: lf-6.18.20_2.0.0. Instead, we encourage to use the matched FW and driver version with same tag. Best regard, Christine. Re: IW612 bluetooth crash after a few days Thank you for the quick reply, I'll come back to you with the hcilog when our customer can provide it Regarding the version, I agree with you, we've only upgraded to the latest version in case it was fixed there and it's easier to upgrade just the firmware on a test machine; the problem also occurred with the 6.12.49-2.2.0 firmware. The version from our user's dmesg (with the original coredump) is as follow: [ 9.321032] wlan: version = SDIW612---18.99.8.p52-MM6X18540.p33-GPL-(FP92) Thanks Re: IW612 bluetooth crash after a few days Hi, @martinetd  Thanks for your quick reply to provide us the requested driver and FW version info. So from your side, please help to provide HCI logs + WiFi and Bluetooth use case and FW dump together. From my side, I will request our internal team to check current FW dump. Once have any updates from our each side, please share together here. Thanks and Regards, Christine. Re: IW612 bluetooth crash after a few days Hi @Christine_Li  Thank you for checking with the firmware team about the dump, it's great to read that they were able to decrypt it! I'm curious about the watchdog timer, the dmesg we obtained from the customer had a timestamp of 170117s (= 1 day 23 hours 15 minutes 17 seconds) so I'm surprised, but I will ask our customer About the precise reproduction step I've actually been busy with another unrelated issue and haven't found time to try to reproduce myself, I'll hopefully get back to you by the time you're back from holidays. I'll also send logs as soon as I get them (unfortunately no ETA, but feel free to put the issue on hold until you hear back from me if that helps internally) Thank you, Dominique Re: IW612 bluetooth crash after a few days Hi, @martinetd  Did you get any chance to receive the HCI logs together with FW dumps and also requested info from your customer? Best regards, Christine. Re: IW612 bluetooth crash after a few days Hello, @martinetd  Our internal team has been able to decrypt the firmware dump, and below are the findings.   WDOG_TIMEOUT after 7.5 days uptime - no fault, no corruption, valid code executing when watchdog expired. 2 BT links and both in SNIFF mode - no active BT traffic at crash   So from this it looks like there is a difference between what your customer is saying and what we are seeing from the dump. Please help to get feedback for below: HCI dump logs (btsnoop/hcidump) from your customer around crash time. Exact test steps- number of devices, profiles (SPP/A2DP/HFP), what triggers every 60 seconds, payload size, single vs 2 devices? Also, can you help to get the ETA for the logs? Without logs, it will be hard to find the root cause of the issue. And for your info, I will start my public National holiday from tomorrow(Oct 1st to Oct 7th) for 7 days, will come back to office on Oct 8th. During this period, please allow me have delay reply. And for sure, I will have a back up in our Mexico team during this period. She/he will continue to support for urgent issue. Sorry for the inconvenience to you. Best regards, Christine. Re: IW612 bluetooth crash after a few days Hi, @martinetd  Thanks for your reply. Sure, no ETA is ok, thanks for your honest and take your time. Then we will put it in hold status and wait for your feedback. Best regards, Christine. Re: IW612 bluetooth crash after a few days Hi, @martinetd  I prefer to leave this message to you to let you know that I am already back to office. So if you already have reproduce the issue or received logs from your customer, please do not hesitate to let me know. If still not yet, please also feel free and do not feel that I am pushing you, just take your time. We will be always happy to support you at any time! Best regards, Christine. Re: IW612 bluetooth crash after a few days Hi, @martinetd  Thanks for providing the useful info. Sure, we will just wait for the btmon logs and related dump. BR, Christine. Re: IW612 bluetooth crash after a few days Thank you for keeping me updated. I've just heard back from our customer; they agreed to provide a trace and I'll send it here once available but until then can confirm a few things: - wifi is not used (our OS normally triggers a scan every few minutes but this is disabled according to customer, so it should not be used at all) - the crash happens when connecting to a single device or multiple devices, the connection is in bluetooth classic SPP/RFCOMM mode, no active scan is done once connected. There is a ping every 5 seconds and more data every 60 seconds (will confirm exact size when we get a trace). I'll update here again with btmon and associated coredump/dmesg once available. Thanks Re: IW612 bluetooth crash after a few days hi @Christine_Li  our customer could reproduce with traces enabled, I'm attaching you traces: - btmon_stripped.2 contains btmon traces at the moment of the crash; the other two files contain the previous 10 minutes of data to get an idea of messages sent. Unfortunately the transmitted data contained sensitive information for our customer, so I've rewritten ascii data as 'x' in EVENT, ACL TX, ACL RX and CTRL_EVENT packets... I've checked the file is readable/sensible with btmon -r but if I messed something up please let me know; I can also probably get permission to share the original traces privately if needed. - dmesg.log includes dmesg up to crash (the btmon concerns the second occurence) - fw_devcoredump.bin was taken after the second crash, but unfortunately I'm not sure if the mechanism works properly to update the dump when crash happens again... I'm sorry if the data doesn't match but at least hopefully it'll be a sample point. Please ask if I need to request our customer reproduces again. Thanks Re: IW612 bluetooth crash after a few days hi @Christine_Li Have you had a chance to look at the traces I provided 2 weeks ago? Thanks Re: IW612 bluetooth crash after a few days Hi, @martinetd  Sorry for my delay reply. Our cases system did not sync your updates successfully from  the community.  Let me check it now and will reply to you ASAP. At the same time, I will reopen the related case in our case system so that we can track your updates in time and avoid such kind of delay replying scenarios because of our system. BR, Christine. Re: IW612 bluetooth crash after a few days Hi, @martinetd  I already provided the logs to our internal expert team to decode the fw dump. Once have any updates, I will let you know. BR, Christine. Re: IW612 bluetooth crash after a few days Hi, @martinetd  We have analyzed the logs you provided and our findings are below. From the dmesg log: At 17,904 s and 17,915 s (about 5 h of uptime), two hci0: command tx timeout messages appear (failure 1). From 17,936 s to 17,961 s, Start FW dump and FW dump complete appear. The firmware nxp/uartspi_n61x_v1.bin.se is then reloaded. At 55,551 s and 55,562 s (about 10.4 h after the reload), the same two command tx timeout messages appear (failure 2). From 55,567 s to 55,592 s, the same FW dump and firmware reload sequence repeats.   From the HCI log(btmon_stripped.2) HCI#227 and #228: the last events from the controller. They are two Mode Change events (sniff mode, 50 ms interval) for the two connection handles, 0x0001 and 0x0002. HCI#230: the host sends HCI_Exit_Sniff_Mode for handle 0x0002. The controller never responds with the complete event. HCI#231: command tx timeout after 2 s. HCI#234: the host sends HCI_Exit_Sniff_Mode for handle 0x0001. The controller again does not respond. HCI#235: command tx timeout after 2 s. HCI#237: Start FW dump. Frame #238: the controller sends an HCI Hardware Error event (code 0xB0). HCI#250 #251: the firmware is reloaded. HCI#252: the host sends HCI Reset and initialization completes.   From these logs, the controller stops responding to HCI commands and currently we are checking with our internal team more on this. In the meantime, please help us with these questions: What are the exact steps to reproduce the issue locally? We prefer to see whether can reproduce on our local side. What is the issue reproduction frequency? I only know it is very low until now. If you can provide more details, would be appreciated. What is your exact use case, and is sniff mode required for your application? In the logs we are seeing 2 devices connected whereas you mentioned only 1 device connected. So we need to double confirm with you. BR, Christine. Re: IW612 bluetooth crash after a few days Thanks for the reply > What are the exact steps to reproduce the issue locally? We prefer to see whether can reproduce on our local side. I'm sorry I still haven't had try to reproduce on my end; I only have as much information as you do at this point. I actually did try to setup a test with two devices I control but I couldn't figure how to setup sniff mode from the bluez stack and ran out of time for now... As far as I can tell it should be something like what we see from btmon, that is setup a link with RFCOMM that enables sniff mode when idle, and some small messages (5-66 bytes) are exchanged regularily (I was told there should be a keepalive every 5 seconds, but I have 10 more minutes of logs and there doesn't seem to be. I see small bursts every 60s) I'm actually not familiar with how to operate sniff mode, is it something the user program is toggling (enter/exit sniff mode) manually everytime they transmit data? Or does the bluez stack automatically take care of it, and re-enters sniff mode on idle? I'll try to make time to retry in the next few days... > What is the issue reproduction frequency? I only know it is very low until now. If you can provide more details, would be appreciated. I was told "once every few days", but from the logs it looks like it happens a bit more often, that might be because they switched their setup from 1 to 2 devices. > What is your exact use case, and is sniff mode required for your application? In the logs we are seeing 2 devices connected whereas you mentioned only 1 device connected. So we need to double confirm with you. They're using sniff mode to save battery and I was explicitly told this is a hard requirement (the target device they're connecting to does not support BLE so they're using sniff mode to limit the time slots during which it has to listen to save battery) I'm told the problem happens with one or multiple devices, I didn't specify the number of devices to retry for the btmon traces. Thanks Re: IW612 bluetooth crash after a few days Hi, @martinetd  Thanks for providing the info. Sure, if you can reproduce this issue, please also share to us the detailed steps. And at the same time, our internal team is analyzing the firmware dump. Once have any updates, let us keep updates each other. BR, Christine. Re: IW612 bluetooth crash after a few days Hi, @martinetd  Thanks for your patience. We received one PVT FW today from our internal team, as we are not able to reproduce the issue locally, please help to check and confirm whether the issue is resolved with the shared PVT FW or not.   Firmware details: FW Name: PVT_FW_1_combo.bin.se MD5SUM: c9eb78febccafa4772ed6c216215362a Note: This firmware is only for the verification purpose only and not used for any official release. Please help to check and help to share the require FW dump, btmon logs with dmesg log in case of any further issue observed. BR, Christine. Re: IW612 bluetooth crash after a few days Thank you! I'll ask our customer to install PVT_FW_1_combo.bin.se as /lib/firmware/nxp/sduart_nw61x_v1.bin.se on target and see if they reproduce, if they do provide logs & more details on the reproducer. (After installing the firmware as such I have this version in dmesg: [ 8.853049] wlan: version = SDIW612---18.92.8.p52.2, -1-gc524d609-Test--MM6X18543.p18-GPL-(FP92) )

S32K358:フラッシュプログラミングの失敗/CPU停止できない(PEmicroおよびJ-Link) NXPチーム/コミュニティの皆様、こんにちは。 PEmicro(S32 Design Studio内)またはSEGGER J-Link Commanderを使っても、S32K358ボードをフラッシュしたり復元したりできない問題が発生しています。デバッガはARM CoreSight DAPと通信できますが、フラッシュプログラミングが失敗し、CPUは停止できません。 1. 環境： MCU: NXP S32K358 IDE: S32 Design Studio for S32 プラットフォーム v3.6.6 デバッグプローブ: PEmicro Multilink / OpenSDA (プラグインバージョン 6.2.4) SEGGER J-Link Lite V9 (DLL v9.90) インターフェース: SWD(500 kHz / 1000 kHz) プロジェクト: FreeRTOSのLED切り替えサンプル 2. 症状と観察された行動： A. S32 Design StudioのPEmicro: デバッグセッションを起動すると、PEmicroはSWDインターフェースに接続し、DAP ID(0x6BA02477)を検証しますが、フラッシュプログラミングは失敗します。 情報: DAP IDCODE = 0x6BA02477 PEmicro GDB 起動失敗: フラッシュプログラミング中にエラーが発生しました。デバッグセッションを終了します。            PEエラー: デバイスへのダウンロード中にエラーが発生しました。デバッグセッションを終了します。   S32DSで「フルチップ消去によるデバイスリカバリ」オプションを使用しようとすると、PEmicroは以下を返します。 「警告 - 一括消去はサポートされていません。」サポートはPEmicroにお問い合わせください。" B. セガー J-Link コマンダー: J-Link Commanderでは、プローブがDAPを検出し、デバイスのロックを解除します。 InitTarget() start SDA_AP detected Unlocking device if necessary... Locked device detected. Proceeding with the unlock procedure... Device successfully unlocked Found SW-DP with ID 0x6BA02477 CPUID register: 0x411FC272 Found Cortex-M7 r1p2, Little endian. しかし、CPUを停止しようとしたり、消去を実行しようとしたりすると、次のようになります。 SetupTarget() start WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1. Initializing ECC RAM... Timeout while initializing ECC RAM WARNING: CPU could not be halted ****** Error: Could not start CPU core. (ErrorCode: -1) Cannot read register 0 (R0) while CPU is running J-Link> erase 'erase': Performing implicit reset & halt of MCU. WARNING: CPU could not be halted ****** Error: Failed to halt CPU. Erasing device... WARNING: CPU could not be halted Cannot access the watchdog SWT0 instance. ****** Error: Failed to preserve target RAM @ 0x20000000-0x20007FFF. ERROR: Erase returned with error code -1. 3．確認された事項： ハードウェアのSWD接続と電源は正常に機能しています（DAP ID = 0x6BA02477、CPUID = 0x411FC272が正しく読み取られています）。 このデバイスは恒久的に保護されているわけではありません（J-Linkは、デフォルトパスワードでデバイスのロックが解除されたことを確認します）。 PEmicroのデフォルトアルゴリズムnxp_s32k358_1x32x2036k_hse_disabled.arpが選択されました。 4. 質問: フラッシュメモリの内容が原因で即座にハードフォルト/ロックアップまたはウォッチドッグリセットループが発生したS32K358を停止させるための推奨される復旧手順は何ですか？ S32K3ではマス消去がサポートされていないのですが、コアがRAMに停止しない場合、PEmicroやJ-Linkを使ってフラッシュセクターを強制消去するにはどうすればよいのでしょうか? S32K358が早期アプリケーション実行を回避してフラッシュアクセスを復元するために、特定のリセットシーケンスやスクリプトが必要ですか? ご協力ありがとうございました。   Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) こんにちは、@shreevalya135 さん。 このThreadの解決策を試してみていただけますか: https://community.nxp.com/t5/S32-SDK/failed-to-power-up-dap-after-program-s32k312-with-pll0-equal/td-p/1609010 ログは異なりますが、SWDの代わりにJTAGを使い、MCUをリセットしたままにすることで問題が解決するのか気になっています。 よろしくお願いいたします。 ダニエル Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) こんにちは、 @danielmartynek さん、 ご提案ありがとうございます。JTAGとSWDの両方のインターフェースを1000kHzでテストし、リセットラインはアサート(r0)と解放(r1)の両方を行いました。 ハードウェアおよびデバッグ構成： 基板: FRDM-S32K358 EVK MCU/コア:S32K358 / S32K358_M7_0 IDE: S32 Design Studio 3.6.6 オンボードデバッガー: J11 USB-C 外部デバッガー：SEGGER J-Link Lite V9 (V8.88) 外部接続：J9（JP11は取り外されています） 目標電圧：3.3V テスト結果： 設定結果 JTAG + リセットがアサートされました 失敗しました SWD + リセットがアサートされました 失敗しました（DAP電源投入エラー） JTAG + リセットがリリースされました 失敗しました SWD + Reset リリース SW-DPおよびCortex-M7検出の成功 SWDはターゲットを正常に検出するものの、ECC RAMの初期化に失敗する。 追加検査： NoDTCM0Initスクリプト： ECC RAMの初期化が依然として0x20000010でタイムアウトし、その後CPU停止失敗が発生します。 NoRAMInitスクリプト: ターゲット初期化は完了しましたが、CPUは停止できません。報告されたPCは 0x200002B8です。 メモリアクセス:0x00400000での内部フラッシュ読み取りは成功しますが、0x20400000でのSRAM読み取り は失敗します。 J11 USB-C経由のオリジナルプログラミングエラー オンボードデバッガを使用したプログラミングは、以下のエラーで失敗します。 CRCコマンドがタイムアウトしました フラッシュの現在の内容がプログラム対象のアプリケーションと一致しません デバイスのフラッシュメモリ消去中にエラーが発生しました HSEを無効にした状態と有効にした状態の両方で.arpフラッシュプログラミングアルゴリズムをテストしましたが、問題は解決しませんでした。 サポートが必要です: 以下の点についてご助言いただければ幸いです。 以前は正常に動作していたボードが、オンボードのJ11デバッガによるフラッシュプログラミングを突然サポートしなくなったのはなぜですか？ CRCコマンドのタイムアウトやフラッシュ消去エラーの原因は何でしょうか? NoDTCM0Initスクリプトを使用しても、ECC RAMの初期化が失敗する理由は？ なぜデバッガはNoRAMInitでターゲットを初期化できるのにCPUを停止できないのでしょうか? このEVK向けに推奨されるS32K358専用のJ-Linkスクリプトやデバッガー設定はありますか？ オンボードデバッガと通常のフラッシュプログラミングを復元するための推奨される復旧手順はありますか？ ご支援ありがとうございます。皆様からのご提案をお待ちしております。 Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) こんにちは、@shreevalya135 さん。 詳細を教えていただきありがとうございます。 2 & 3. デバッガは、SEGGER社およびPEmicro社独自のアルゴリズムを使用しています。ログの詳細については、彼らにお問い合わせするのも良いでしょう。 1. 何とも言えません。搭載されているデバッガもPEmicroデバッガです。理論的には、SRAMが損傷し、デバッガがMCUの消去やプログラムに必要なデータやプログラミングルーチンを読み込めなくなる可能性があります。 4 & 5. 推奨するスクリプトはありません。J-Link Commanderを使ってMDM-APの状態レジスタやコントロールレジスタにアクセスできますか? // Select MDM-AP SWDWriteDP 2, 0x06000000 // Read MDMAPSTTS and MDMAPCTL SWDReadAP 0 SWDReadAP 0 SWDReadAP 1 SWDReadAP 1 // Write MDMAPCTL SWDWriteAP 1 0x100 // Cortex-M7_0 debug request よろしくお願いいたします。 ダニエル Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) こんにちは、 @danielmartynek さん、 ご回答とご提案をいただき、ありがとうございます。 私はFRDM-A-S32K358ボードのJ9コネクタにコネクテッドされた外部のSEGGER J-Link Lite V9を使用しています 。推奨されたデバッグとMDM-APアクセステストは実施済みです。以下に接続の詳細と結果をまとめます。 1. J-Link接続出力の完全版 実行されたコマンド: exec ForceAttachTarget=1 device S32K358_M7_0 si SWD speed 800 connect 接続出力: Device "S32K358_M7_0" selected. Connecting to target via SWD ConfigTargetSettings() start ConfigTargetSettings() end - Took 63us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Debug access is not enabled yet. Performing enable debug access sequence... Debug access enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 144ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found CPUID register: 0x411FC272 Found Cortex-M7 r1p2, Little endian. CoreBaseAddr manually set by user: 0x40250400 SetupTarget() start -- Attach mode active. Skipping halting core & work RAM init (https://kb.segger.com/NXP_S32K3xx#ECC_RAM). SetupTarget() end - Took 87us Memory zones: Zone: "Default" Description: Default access mode Cortex-M7 identified. 2. CPUおよびメモリアクセス結果 接続後、 hとregsを実行すると、無効なCPUレジスタ値が表示されます。 PC = CDCDCDCD SP = FFFFFFFD XPSR = CDCDCDCD IPSR = 00D (Reserved) メモリアクセステスト: 住所結果 0x00400000 成功 0x00402000 失敗しました 0x20000000 成功 0x20400000 失敗しました 3. MDM-APレジスタアクセス結果 提案されたMDM-AP操作も試してみました。 SWDWriteDP 2, 0x06000000 SWDReadAP 0 SWDReadAP 1 SWDWriteAP 1, 0x100 MDM-APレジスタの読み取りと書き込みを含む、すべての操作でエラーが返されました。 4．追加の観察 アタッチモードがない場合、J-LinkはECC RAMの初期化中に失敗し、以下のエラーを報告します。 Could not start CPU core. (ErrorCode: -1) 5．復旧に関するガイダンスが必要 以下の点についてアドバイスいただけますか? なぜMDM-APアクセスは、SW-DPの検出やデバッグアクセスのイネーブルメントが成功しているのに失敗するのでしょうか? ECC RAMの初期化が失敗したとき、Cortex-M7_0コアをどうやって復旧できますか? 内部フラッシュはCPUを正常に起動せずにハードウェアレベルのリカバリー機構で消去・再プログラムすることは可能でしょうか? 基板を交換せずに、通常のデバッグ機能とフラッシュプログラミング機能を復元するための推奨手順はありますか？ 私たちの目標は、FRDM-A-S32K358ボードを復旧させ、通常のデバッグ機能とフラッシュプログラミング機能を復元することです。 この問題の原因を特定し、適切な回復手順を推奨するために、皆様のサポートとご指導をお願いいたします。ご協力やご提案をいただければ大変ありがたく存じます。 お時間をいただき、サポートありがとうございます。 よろしくお願いします、 シュリーヴァリヤ Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) こんにちは、@shreevalya135 さん。 なぜイメージを読み込めるのにMDM-APレジスタを読み取れないのか説明できません。 スクリプトはS32K358上で正常に実行できます。 device S32K358 si SWD speed 4000 connect sleep 100 // Select MDM-AP, bank 0 SWDWriteDP 2, 0x06000000 sleep 20 // Read MDMAPSTATUS and MDMAPCTL SWDReadAP 0 SWDReadAP 0 SWDReadAP 1 SWDReadAP 1 RESET_Bピンが定期的にアサートされているかどうかを測定できますか? ありがとうございました。 ダニエル Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) こんにちは、 @danielmartynek さん、 ご提案と継続的なサポートに感謝します。FRDM-A-S32K358ボードの復旧にあたり、引き続きご協力をお願いいたします。 念のため説明すると、私は外部の SEGGER J-Link Lite Cortex-M デバッガを使っています。 製品リンク:https://www.segger.com/products/debug-probes/j-link/models/j-link-lite/j-link-lite-cortex-m/ J-LinkはJ9コネクタにコネクテッドされており、JP11ジャンパーは外していて、SWDインターフェースを使っています。 J-Flash Lite V8.88 と J-Link Commander V9.90 を試してみました 。 J-Flash Liteを使って、SDKs LED Blinkyのサンプルファイルをプログラム.bin しました。成功した消去とプログラミング(「アプリケーションが正常にダンプされました」)を報告しましたが、基板上でLEDブリンキーアプリケーションは実行されません。 さらに、前回の回答で提案されたMDM-APコマンドも試してみました。 SWDWriteDP 2, 0x06000000 SWDReadAP 0 SWDReadAP 1 SWDWriteAP 1, 0x100 しかし、すべてのコマンドがエラーを返し、MDM-APレジスタにアクセスできませんでした。 しかし、外部のJ-Linkを使用した場合でも、この問題は解消されません。デバッガはターゲットを検出しますが、ECC RAMの初期化が失敗し、CPUは停止できません。 S32K358の復旧に適したおすすめのJ-Linkモデルや代替の外部デバッガをご存知いただけますか?また、CPUが停止できずMDM-APアクセスが失敗した場合に、代替の復旧手順はありますか? 引き続きご支援いただきありがとうございます。 Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) こんにちは、 @danielmartynek さん、 ご返信と継続的なサポートに感謝します。 FRDM-A-S32K358ボードのRESET_Bピンの電圧を測定しました。リセットボタンを押したときの電圧は0.0V、ボタンを離したときの電圧は3.3Vでした。 さらに、外部のSEGGER J-Linkをボードにコネクテッドし、デバッガ接続がリセット関連の問題を引き起こしていないか同じ測定を繰り返しました。結果は同じで、 押すと0.0V、離すと3.3Vでした。 基板のさらなる診断と回復のための次のステップについてご案内いただけますか? よろしくお願いします。 よろしくお願いします、 シュリーヴァリヤ Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) こんにちは、 @shreevalya135 さん。 現時点では、利用可能な情報から正確な根本原因を特定することはできません。デバッガはSW-DPとCortex-M7を識別できますが、CPUを停止したり、ECC RAMを初期化したり、MDM-APにアクセスすることはできません。 デバッガのリセットシーケンスは、プログラム前にMCUをリセット状態に戻す必要があります。したがって、以前にデバイスにプログラムされたアプリケーションが、たとえ誤ったシステムクロックの設定やJTAG/SWDピンの再設定をしていても、RESET_Bとデバッグインターフェースが正しく動作していれば、回復を永久に妨げることはありません。また、電源オンリセット後にMCUが繰り返しRESET_Bを主張していることも測定されていません。 PEmicroとSEGGER J-Linkの両方で同様の挙動が観察され、MDM-APアクセスが利用できないことから、MCUが...現時点での証拠に基づき、この装置を復元するためのさらなるソフトウェアやデバッグ手順を推奨することはできません。 同じデバッガ、接続、設定、アプリケーションイメージを使って複数のS32K358ボード上で問題を再現できない場合、デバッガ、イメージ、共通の設定を主な原因として合理的に除外できます。その場合、影響を受けたMCUは損傷したとみなされるべきです。理論的には、この損傷はESDイベントや他の電気的過負荷イベントによって引き起こされた可能性があります。 よろしくお願いいたします。 ダニエル

IW612のBluetoothが数日後にクラッシュする こんにちは、 ユーザーの一人から、murata LBES5PL2EL-923(IW612コア)のBluetooth機能に関するバグを報告がありました。BluetoothスタックがBluetooth静的RFCOMM/SPPでデバイスにコネクテッドすると数日後にクラッシュする現象です （元のレポートは公開されており、日本語版はhttps://armadillo.atmark-techno.com/forum/armadillo/31772で閲覧可能です。）） これに関して既知のバグはありますか？ ソフトウェアのセットアップ： * Linux 6.12 は lf-6.12.49-2.2.0 に基づく(正確なソースツリー:https://github.com/atmark-techno/linux-6.12-at/tree/6.12.105-r0) これはBTの問題ですが、参考までにワイヤレスドライバーはmwifiex lf-6.12.49-2.2.0をベースにしています。 * ファームウェアをimx-firmwareリポジトリの最新版lf-6.18.20_2.0.0にアップデートしました。https://github.com/nxp-imx/imx-firmware/tree/lf-6.18.20_2.0.0/FwImage_IW612_SD * BlueZスタック（正確なバージョンを確認中です。申し訳ありませんが、確認し忘れていました。） * 基板は*Bluetooth classic*(BLEではない)で単一のデバイスに接続され、RFCOMM/SPPで接続されています。60秒ごとにアプリケーションはメッセージを送信し、返信(簡単なポーリング)を受け取ります。数日後にコマンドタイムアウトが入り、BTドライバが再起動します クラッシュ後に/sys/class/bluetooth/hci0/devcoredump/dataから取得したファームウェアダンプを添付しました。役に立つと仮定して、クラッシュまではdmesgにメッセージはありません(すみません、「FWダンプ開始」の前に短縮されているためタイムスタンプがなく、クラッシュ直後だったと理解しています)。 FWのリロード機構は動作しますが、再接続が必要なので、可能であれば対応が良いでしょう。 [ 0.000000] Linux version 6.12.105-0-at (builder@71056255c5a6) (aarch64-alpine-linux-musl-cc (Alpine 15.2.0) 15.2.0, GNU ld (GNU Binutils) 2.45.1) #1-Alpine SMP PREEMPT Mon Aug 24 07:48:35 UTC 2026 [...] [ 9.321032] wlan: version = SDIW612---18.99.8.p52-MM6X18540.p33-GPL-(FP92) [...] [ 10.349326] Bluetooth: hci0: FW already running. [ 38.303160] Bluetooth: MGMT ver 1.23 [170117.376944] Bluetooth: hci0: command tx timeout Bluetooth: hci0: ==== Start FW dump === Bluetooth: hci0: ==== FW dump complete === Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se Bluetooth: hci0: FW Download Complete: 412940 bytes 分析に役立つその他の情報があれば、お尋ねください。 よろしくお願い申し上げます。 Re: IW612 bluetooth crash after a few days 1. HCIログも提供していただければ、どのコマンドがタイムアウトし、ファームウェアダンプが生成されているかを特定するのに役立ちます。 この件で具体的にどういう意味か教えていただけますか?実行後から実行できるコマンドはありますか?それともプロセスが実行されている間にhcidumpや同等のコマンドを実行すればよいのでしょうか? Wi-Fiドライバーの読み込みパラメータを入手> 3.To、/lib/firmware/nxp/wifi_mod_para.conf を教えてください。 このファイルは使わないので、ここでもデフォルトのパラメータを使うべきです。ログレベルをデフォルト値から下げたので、DMESGもあまり役に立たないでしょう(前回の返信でdmesgのリンクを送りました)。 この期間中にWi-Fiを使っているかどうか、ユーザーに確認してみます Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd 1. HCIログも提供していただければ、どのコマンドが タイムアウトし、ファームウェアダンプが生成されているかを 特定するのに役立ちます 。 2. WLANが稼働している間にWLANベースのユースケースを教えてくれますが、ファームウェアダンプが生成されている間にWLANが正常に動作しているか確認してもらえますか? 3.To get Wi-Fiドライバー loading parameters, you can provide us the: /lib/firmware/nxp/wifi_mod_para.conf または、WiFiやBluetoothの読み込み全過程を含む 通常の起動DMESGログ を提供してもらえます。DMESGのログから情報を得ることができます。 4.現在、お客様が使用されているものよりも新しい公開されているGitHubファームウェアリリースはありません。 imx-firmware/FwImage_IW612_SD (lf-6.18.20_2.0.0) · nxp-imx/imx-firmware · GitHub ですので、これは既知の問題ではないと思います。 私たちは、ユースケースに関する情報やHCIログを多めに持っておきたいので、何が起こったかを追跡したり手順を再現したりして、ローカルで問題を再現できるようにしたいと考えています。 もしこの問題に関する他に情報があれば、ぜひ教えてください。 よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @Christine_Li さん、迅速なご返信ありがとうございます。 > 1.もしbtnxpuartドライバーを使っているなら、btnxpuart.cを教えてください。 私たちは、 https://github.com/nxp-imx/linux-imxで提供されている btnxpuart を使用しています。バージョン lf-6.12.49-2.2.0 に基づいており、正確なファイルはこちらでご覧いただけます https://github.com/atmark-techno/linux-6.12-at/blob/6.12.105-r0/drivers/bluetooth/btnxpuart.c 2. Wi-FiとBluetooth/802.15.4のコンボファームウェアを使用していますか？それとも、別々のファームウェアを使用していますか？ 両方使っています:起動時にWi-FiドライバーがコンボFWを読み込み、クラッシュ後に別のFWをリロードします(だからログで別FWの名前を付けています)。 このクラッシュが発生したとき、コンボファームウェアがロードされていました（起動後の最初のクラッシュ）が、両方のファームウェアで再現すると理解しています。 >  3.Wi-FiとBluetoothドライバーの負荷パラメータを教えてもらえますか? 明示的に設定している唯一のWiFiパラメータはdrv_mode = 0x3で、使っていないWiFiダイレクトインターフェースを無効化します。Bluetoothパラメータは設定していません。もし正確な設定のダンプ方法を教えていただければ、ユーザーにコマンドを実行してもらい、情報を取得してもらうよう頼めます。 > 4.詳細な再現手順を教えていただけますか? これはユーザー報告に基づくものなので、説明したこと(数日間60秒ごとにRFCOMM接続をポーリングする)以上のことは言えません。チップが接続されているサブデバイスによって異なるのではないかと心配しています。 RFCOMM経由でpingを送ってローカルで再現できるデバイスを探してテストスクリプトを提供してみますが、今のところファームウェアやBTNXPUARTドライバの既知のバグが記載されたリリースノートは見つからなかったので、既知のバグがあるかどうか(そしてできればファームウェアのダンプから何か情報が得られるか)を確認したいです。 よろしくお願い申し上げます。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd 1. Bluetooth用にNXPのBTNXPUARTドライバーを使っていますか?それともLinuxのオープンソースUartドライバを使っていますか? もしbtnxpuartドライバーを使っているなら、btnxpuart.cを教えてください。 2. Wi-FiとBluetooth/802.15.4のコンボファームウェアを使用していますか？それとも、個別のファームウェアを使用していますか？ ログが下にあるのを見ているので、別のFWを使っているのではないかと疑っています。確認が必要です。 hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se 3. Wi-FiとBluetoothドライバーの負荷パラメータを教えてもらえますか? 4. 詳細な再現手順を教えていただけますか? よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days > * BlueZスタック（正確なバージョンを確認中です。申し訳ありませんが、確認し忘れていました。） 参考までに、BlueZ版は5.82です Re: IW612 bluetooth crash after a few days > btmon ご説明いただきありがとうございます。 クラッシュの再現には数日かかり、ログが大きくなるため、完全なログを保存・共有するのは現実的ではないかもしれません(1分で100KB見えるので、2日で約300MBになります)。 残念ながらbtmonにはtcpdumpのような「巡回記録」モードはないようですが、クラッシュ直前の数分だけに興味があるなら、顧客のログを5分ごとに2ファイル交互に表示して、最後の5分を記録できるようにリクエストできます。 （未テスト）といった形で、最後のサンプルを送ることは許容範囲でしょうか？(ただし、ランの間にイベントが記録されない短いウィンドウがあります...) I=0; while ! [ -e /sys/class/bluetooth/hci0/devcoredump/data ]; do timeout 300s btmon -K -t -w log.$I; I=$((I+1%3)); done > コアダンプが読み取れません 残念ですが、どうしようもありません。 このファイルは、FW ダンプ完了メッセージの後に /sys/class/bluetooth/hci0/devcoredump/data から読み取ったものです。もしこの方法が適切でない場合や、より有用なデータを取得する方法があれば喜んで対応しますが、今は btmon トレースに焦点を当てましょう。 よろしくお願い申し上げます。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd 1. btmonの場合： ==>はい、サイズの都合で全工程を記録できれば、あなたが提案した方法が良いと思います。それに、それ以外に良いアイデアはありません。 2. ファームウェアダンプの場合： drvdbg=0xa0037でドライバーを読み込むことをおすすめします。これにより、より多くのfwダンプやドライバーのダンプログを記録して分析できます。   問題が発生しました   ログは以下のようにこのディレクトリに自動的に保存されます。   ======================================== [4221.173141]ディレクトリ /data/dump_4220 の作成エラー。/var にディレクトリを作成してみてください。 [4221.173147]ウェイクアップデバイス... [4221.173231]ディレクトリ /var/dump_4220 の作成に成功しました。 [4221.173232]ディレクトリ名は /var/dump_4220 です [ 4221.173233] === ドライバ情報開始 ダンプ=== [4221.173289]DRVダンプデータは/var/dump_4220/file_drv_infoにあります。 [4221.173306]ウェイクアップデバイス... [4221.173889]SDIO Func0 (0x0-0x9): 43 03 06 00 07 00 00 02 03 00 [4221.175173]SDIO 機能 1 (0x4-0xb): 00 00 00 00 ff ff ff ff [4221.175879]SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00 [4221.176284]SDIO 機能 1 (0xc0-0xca): DC fe 96 00 31 11 00 37 37 02 20 [ 4221.177301] | [4221.275861]SDIO Func1 (0xc0-0xca): DC fe a1 00 3b 00 00 37 37 02 20 [4221.276501]ドライブ情報の合計バイト数 = 263150 (0x403ee) [ 4221.276503] === ドライバー情報ダンプ 終了===ウェイクアップ装置... [ 4221.276555] ==== デバッグモード出力開始: 4220.878602 === ====================================================   ダンプが「/var」や「/data」で自動生成されていない場合は、以下の「cat /proc/mwlan/adapter0/fw_dump > file_fw_dump」コマンドを使って手動で収集できます。     2. DMESGログにディレクトリが印刷されていないか、あなたの場合はログレベルが下がっている場合は、以下の方法で登録してください:   - echo debug_dump > /proc/mwlan/adapter0/config しばらく（1～2分）お待ちください。 fw_dumpの場合： - cat /proc/mwlan/adapter0/fw_dump > file_fw_dump drv_dumpの場合： cat /proc/mwlan/adapter0/drv_dump > file_drv_dump   このようなFWクラッシュ問題に対して、btmonログはお客様のユースCASEや問題シナリオをよりよく理解するための拡張ログです。FW_dumpは私たちにとって最も重要なログです。   また、前述の通り、このテスト中にお客様にWi-Fiのユースケースについても尋ねてください。   よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days BTmonについては了解しました。リクエストしてみます（Wi-Fiの使用状況についても質問します）。 まずファームウェアのダンプについて確認させてください。私が取得したダンプはBluetoothのダンプでしたが、あなたが説明しているのはワイヤレスのダンプのようですね。 お客様からのトレースではWiFiドライバはクラッシュしなかったので、drvdbg=は効果がないのではないかと思います。 また、結合ファームウェアの場合(「echo debug_dump > /proc/mwlan/adapter0/config」)でワイヤレスファームウェアが必要な場合、問題はBTドライバーが自動的に新しいファームウェアをリロードし、アダプターを再起動してしまうため、これを動作させるにはファームウェアの読み込みを無効にする必要があることです ダンプは分析に有用だと思います。もしダンプの入手方法を修正できるなら、まず知りたいです。何をすべきかが明確になったら、一度にお客様にすべて尋ねます よろしくお願いします。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd この件で具体的にどういう意味か教えていただけますか?実行後から実行できるコマンドはありますか?それともプロセスが実行されている間にhcidumpや同等のコマンドを実行すればよいのでしょうか? ==>hciログは、以下のコマンドでBluetooth/BLEを有効にする後にキャプチャ可能です: btmon -w failed_snoop.log & その後、顧客は再現手順を実行し、この問題を再現しようとします。 failed_snoop.log には、Bluetooth/BLE のすべてのプロセスが記録されます。 問題が再現されたら、このログを確認して実行されているコマンドやイベント情報を把握し、関連する疑いを見つけることができます。 これは、ファイアウォールがクラッシュした後に失敗したログを実行して取得するためのコマンドではありません。 ところで、提供された fw ダンプ bin ファイルfw_devcorecump.binを復号化するために、社内の専門家チームに協力を依頼しました。しかし残念ながら、復号がうまく解読できていません。ファイルが破損しているか、データが不足しているため復号できないようです。 よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd はい、おっしゃる通りです。 この問題の再現が難しいため、必要なログをすべて取得することを推奨します。 社内チームに確認したところ、BSP 6.12.34以降では、btnxpuartカーネルモジュールがIW612ナローバンドファームウェアが停止していることを検出するとのことです。狭帯域CPUをリセットして再度ダウンロードすることで、自動的に復旧プロセスが開始されます。BTファームウェアのダンプは自動的に生成されます。コマンドのタイムアウトが発生した時点で生成されます。 だから、あなたの言う通りです。Wi-Fiダンプは不要です。BTファームウェアダンプと、可能であればhciログのみを提供してください。また、WiFiのユースケースやシナリオについても、ぜひご協力ください。 よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @Christine_Li 返信が遅くなり申し訳ありません。現在、祝日期間中です。 >  この問題は再現が難しいため、必要なログをすべて取得することを希望します。 わかりました。できるだけ多くの情報をお客様から得て、今後1〜2週間で自分で再現できるかも確認してみます >  社内チームに確認したところ、BSP 6.12.34 以降では、btnxpuart カーネルモジュールが IW612 ナローバンドファームウェアが停止していることを検出するとのことです。狭帯域CPUをリセットして再度ダウンロードすることで、自動的に復旧プロセスが開始されます。BTファームウェアのダンプは自動的に生成されます。コマンドのタイムアウトが発生した時点で生成されます。 > つまり、あなたの言う通りです。Wi-Fiダンプは不要です。BTファームウェアダンプと、可能であればhciログのみを提供してください。また、WiFiのユースケースやシナリオについても、ぜひご協力ください。 Wi-Fi ダンプが不要であることを確認していただきありがとうございます。しかし、BT ダンプについては困ったことになっています。最初の投稿で送信したダンプは、btnxpuart モジュールが自動的に生成したもので、切り詰められたとは考えられません (サイズは、/sys/class/bluetooth/hci0/device/coredump に 1 を書き込んで人為的にダンプを生成したときに得られるものと似ています)。 その入手方法は、クラッシュ完了後にデータファイルから（catコマンドで）読み取るだけだった。 cat /sys/class/bluetooth/hci0/devcoredump/data > fw_dump ダンプを取得するもっと適切な方法はありますか？ また、初歩的な質問で恐縮ですが、私が送ったダンプファイルはBTダンプとして開封されたものでしょうか？ この時点では明日お客様にすべてをまとめますが、新しいダンプが送られてしまい、再び開けられなくなるのではとかなり心配なので、この点をはっきりさせていただきたいです。 よろしくお願い申し上げます。 ドミニク Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd ご意見ありがとうございます。 ファームウェアのダンプについて。はい、ファームウェアのダンプに関するあなたの懸念は十分に理解しています。 そこで、社内チームとアプリケーションノートAN14710 を再確認しました。あなたがFWダンプを取得する手順は、特にBTNXPUARTドライバに関して正しいようです。 内部の専門家チームに確認して、現在の共有ダンプファイルから有用な情報を見つけられるか確認してみます。ここで何か他にやるべきことがあるかもしれませんが、私はそれを知らないので、コアの研究開発チームに確認します。 HCIログ用。 その間、エンドカスタマーから HCIログ の取得もお手伝 いください 。これにより、 HCIコマンドシーケンスを分析し、問題を自社側で再現できるかどうか判断できます。 ドライバおよびFW版について: それに、FW版とドライバを二重に確認するために、ボードから読み上げるのも手伝ってください。 あなたは既に、以下のものを使用していると述べていましたね。 ドライバ:mwifiex lf-6.12.49-2.2.0 FW: lf-6.18.20_2.0.0 https://github.com/nxp-imx/imx-firmware/tree/lf-6.18.20_2.0.0/FwImage_IW612_SD しかし、ボードのDMESGログから読めば、二重に確認できます。どうもありがとう。 dmesg | grep wlan すると、以下のようにWiFiとファームウェアのバージョンが表示されます。 [ 7.573794] wlan: バージョン = SDIW612---18.99.8.p52--MM6X18543.p18-GPL-(FP92) その他の情報。 また、ドライバとFWの不一致は推奨しません。 例えば、あなたは lf-6.12.49-2.2.0 ベースのドライバーを使っていますが、FW は lf-6.18.20_2.0.0 に基づいています。 代わりに、同じタグでマッチしたFWとドライバーのバージョンを使うことを推奨しています。 宜しくお願いします、 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd 迅速な返信で、要求されたドライバとFWのバージョン情報を教えてくれてありがとうございます。 ですので、あなたの側からは、HCIログ+WiFiとBluetoothのユースケース、そしてFWダンプを一緒に提供するのを手伝ってください。 私としては、社内チームに現在のファームウェアダンプを確認するよう依頼します。 双方から何か新しい情報がありましたら、こちらで共有してください。 よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days 迅速なご返信ありがとうございます。お客様がHCIlogを提供できたらまたご連絡します バージョンについては同意します。最新バージョンにアップグレードしたのは、テストマシンでファームウェアだけをアップグレードする方が簡単だからです。この問題は6.12.49〜2.2.0のファームウェアでも発生しました。 ユーザーのDMESG(元のコアダンプ付き)からのバージョンは以下の通りです: [ 9.321032] wlan: version = SDIW612---18.99.8.p52-MM6X18540.p33-GPL-(FP92) ありがとう Re: IW612 bluetooth crash after a few days こんにちは、 @Christine_Li さん。 ファームウェアチームにダンプについて確認していただき、ありがとうございます。彼らがそれを解読できたと聞いて大変嬉しく思います！ ウォッチドッグタイマーについて気になっています。お客様から入手したDMESGのタイムスタンプは170117s(=1日23時間15分17秒)だったので驚いていますが、お客様に聞いてみます 再現手順についてですが、実は別の問題で忙しく、自分で再現を試みる時間が取れていません。休暇から戻られる頃には、ご連絡できると思います。 ログを入手次第、お送りします（残念ながらお届け予定日は未定ですが、社内で対応がスムーズに進むようでしたら、私からの返信があるまでこの問題を保留にしていただいても構いません）。 ありがとうございました。 ドミニク Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd 社内チームはファームウェアのダンプを解読することに成功しました。以下にその結果を示します。   7.5日間の稼働後にWDOG_TIMEOUTが発生しました。障害や破損はなく、ウォッチドッグが期限切れになった時点で有効なコードが実行されていました。 2つのBTリンクがあり、両方ともSNIFFモードになっているが、クラッシュ時にはアクティブなBTトラフィックはなかった。   これからすると、お客様の発言と私たちがダンプから見ているものには違いがあるようです。下記に関するフィードバックにご協力ください。 クラッシュ時のお客様からのHCIダンプログ(btsnoop/hcidump)を。 具体的なテスト手順：デバイスの数、プロファイル（SPP/A2DP/HFP）、60秒ごとにトリガーされるもの、ペイロードサイズ、デバイスが1台か2台か？ また、ログの到着予定時刻を手伝ってもらえますか? ログがないと、問題の根本原因を特定するのは困難です。 参考までにお知らせしますが、私は明日（10月1日）から7日間、国民の祝日をいただきます。10月8日にオフィスに戻ります。この期間中は、返信が遅れる場合がございますのでご了承ください。そしてもちろん、この期間中はメキシコ代表チームにバックアップメンバーを用意しておくつもりです。彼女/彼は緊急の問題に対して引き続きサポートを行います。ご迷惑をおかけして申し訳ございません。 よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd ご返信ありがとうございます。 もちろん、到着予定時刻がなくても大丈夫です。正直に言ってくれてありがとう。ゆっくりで構いませんよ。 その後、保留状態にして、お客様からのフィードバックをお待ちいたします。 よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd HCIログやFWダンプ、そしてお客様からのリクエストされた情報を受け取る機会はありましたか? よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd このメッセージは、私が既に職場復帰したことをお知らせするために残しておきます。 もしすでに問題を再現しているか、お客様からログを受け取った場合は、遠慮なくお知らせください。 まだ決めていないのであれば、遠慮なく、私があなたを急かしていると思わないでください。ご自身のペースで進めてください。 いつでも喜んでサポートいたします! よろしくお願いいたします。 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd 有益な情報を提供していただきありがとうございます。 はい、btmonのログと関連するダンプを待ちます。 BR、 Christine。 Re: IW612 bluetooth crash after a few days 最新情報をお知らせいただきありがとうございます。 先ほどお客様から返事がありました。追跡情報を提供してくれることに同意してくれました。利用可能になったらこちらに送りますが、それまではいくつか確認できることがあります。 - Wi-Fiが使われていない(通常、OSは数分ごとにスキャンをトリガーしますが、顧客の意見では無効とされているため、使うべきではありません) - コネクテッド時に単一のデバイスまたは複数のデバイスに接続した際にクラッシュが発生します。コネクテッド時はBluetooth classicのSPP/RFCOMMモードで接続し、一度アクティブなスキャンは行われません。5秒ごとにpingが送信され、60秒ごとにデータが送信されます（トレースを取得したら正確なサイズを確認します）。 btmonと関連するcoredump/dmesgが入手でき次第、こちらで再度更新します。 ありがとう Re: IW612 bluetooth crash after a few days こんにちは、 @Christine_Li お客様はトレースを有効にして再現できます。トレースを添付します: - btmon_stripped.2はクラッシュ時のBTMONトレースを含み、他の2つのファイルには送信されたメッセージのイメージを把握するための直近10分間のデータが含まれています。残念ながら、送信されたデータにはお客様向けの機密情報が含まれていたため、ASCIIデータをイベント情報、ACL TX、ACL RX、CTRL_EVENTパケットで「x」に書き換えました...btmon -rでファイルが読み取れる/意味合いがあるか確認しましたが、もし何か間違えていたら教えてください。必要なら元のトレースをプライベートで共有する許可も得られると思います。 - dmesg.logにはクラッシュまでのdmesgログが含まれています（btmonは2回目の発生に関するものです） - fw_devcoredump.bin は 2 回目のクラッシュ後に取得されましたが、残念ながら、クラッシュが再び発生したときにダンプを更新するメカニズムが正しく機能するかどうかはわかりません... データが一致しない場合は申し訳ありませんが、少なくともサンプルポイントとして役立つことを願っています。お客様に再度複製をお願いする必要がある場合は、ぜひご連絡ください。 よろしくお願いします。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd 返信が遅くなり申し訳ありません。CASEシステムがコミュニティからの更新を正常に同期できませんでした。 今すぐ確認して、できるだけ早く返信します。 同時に、関連するCASEはCASEシステムで再開し、更新をタイムリーに追跡し、システムによる遅延対応を回避できるようにします。 BR、 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @Christine_Li 2週間前に私が提供したトレースデータはご覧いただけましたか？ ありがとう Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd ファームウェアダンプの解析のため、既にログを社内の専門チームに提供しました。 何か新しい情報があれば、お知らせします。 BR、 Christine。 Re: IW612 bluetooth crash after a few days 返信ありがとうございます > この問題を地域で再現するための具体的な手順は何ですか?私たちは、地元の側で再現できるかどうかを試したいと考えています。 申し訳ありませんが、まだこちら側で再現を試みることができていません。現時点では、私もあなたと同じ情報しか持っていません。実は、私が制御する2台のデバイスを使ってテストを試みてみたのですが、BlueZスタックからスニフモードを設定する方法が分からず、時間もなくなってしまいました…。 私の理解では、BTMONのようなもので、RFCOMMでリンクを設定してアイドル時にスニッフモードを有効にし、5〜66バイト程度の小さなメッセージを定期的にやり取りするものです(5秒ごとにキープリブがあると言われましたが、あと10分分のログがあるのにそうは思えません)。60秒ごとに小さな爆発が見られます。 実はスニッフモードの操作方法には詳しくありませんが、ユーザープログラムがデータを送信するたびに手動で(スニッフモードの入り/退出)切り替えているのでしょうか?それとも、bluezスタックが自動的に処理して、アイドル状態になると再びスニッフィングモードに戻るのでしょうか？ 数日中に時間を作って再挑戦してみます。 >問題は再生頻度の何なのでしょうか?今のところ非常に低いと知っています。もし詳しい情報を提供していただけるとありがたいです。 「数日に一度」と言われましたが、ログを見る限り、少し頻度が増えているようで、セットアップが1台から2台に変わったためかもしれません。 > あなたの具体的なユースCASEは何で、スニッフモードはアプリケーションに必須ですか?ログでは2台の デバイスがコネクテッドなのに対し、あなたは1台しかコネクテッドしていないと言っていました。ですので、再度確認する必要があります。 バッテリー節約のためにスニッフモードを使っており、これは明確に必須だと聞きました(接続先のデバイスはBLEをサポートしていないため、スニッフモードを使ってバッテリーを節約するために受信時間制限しているのです)。 問題は1台または複数のデバイスで発生すると聞いていますが、btmonトレースで再試行するデバイスの数は指定していません。 よろしくお願いします。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd ご提供いただいたログを分析した結果は以下のとおりです。 dmesgログより： 17,904秒と17,915秒（約5時間の稼働時間）に、hci0: command tx timeoutメッセージが2つ表示されます（障害1）。 17,936秒から17,961秒にかけて、「Start FW dump」と「FW dump complete」が表示されます。その後、ファームウェアnxp/uartspi_n61x_v1.bin.seが再ロードされます。 55,551秒と55,562秒（リロード後約10.4時間）に、同じ2つのコマンド送信タイムアウトメッセージが表示されます（失敗2）。 55,567秒から55,592秒まで、同じファームウェアダンプとファームウェア再ロードのシーケンスが繰り返されます。   HCIログ(btmon_stripped.2)より HCI#227および#228:コントローラからの最後のイベント情報。これらは2つの接続ハンドル、0x0001と0x0002に対して2つのモード変更イベント情報(スニッフモード、50ms間隔)です。 HCI#230: ホストがハンドル 0x0002 に対して HCI_Exit_Sniff_Mode を送信しました。コントローラはイベント情報全体を返しません。 HCI#231: コマンド送信タイムアウトが2秒後に発生しました。 HCI#234: ホストがハンドル 0x0001 に対して HCI_Exit_Sniff_Mode を送信します。コントローラは再び反応しません。 HCI#235: コマンド送信タイムアウトが2秒後に発生しました。 HCI#237: FWダンプを開始します。フレーム#238:コントローラがHCIハードウェアエラーイベント情報(コード0xB0)を送信します。 HCI#250 #251: ファームウェアが再ロードされました。HCI#252: ホストがHCIリセットを送信し、初期化が完了しました。   これらのログから、コントローラはHCIコマンドに応答しなくなり、現在は内部チームに確認を進めています。その間、以下の質問にご協力をお願いします。 この問題がローカル環境で再現するための具体的な手順を教えてください。私たちは地元の側でCAN繁殖するかどうかを見たいと思っています。 問題の再現頻度はどのくらいですか？今のところ、非常に低いということしか分かっていません。もし詳細を教えていただけるとありがたいです。 あなたの具体的なユースCASEは何で、スニッフモードはアプリケーションに必須ですか?ログでは2台の デバイスがコネクテッドされているのに対し、あなたは1台しかコネクテッドしていないと言っていました。ですので、再度確認する必要があります。 BR、 Christine。 Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd 情報提供ありがとうございます。 もちろん、この問題を再現できるなら、詳細な手順も教えてください。 同時に、社内チームがファームウェアのダンプを分析しています。 何か新しい情報があれば、お互いに共有しましょう。 BR、 Christine。 Re: IW612 bluetooth crash after a few days ありがとうございます! お客様にPVT_FW_1_combo.bin.seをターゲットに/lib/firmware/nxp/sduart_nw61x_v1.bin.seとしてインストールしてもらい、再現できるか確認し、ログや詳細を提供してもらうつもりです。 （ファームウェアをインストールした後、dmesgにはこのバージョンが表示されました。） [ 8.853049] wlan: バージョン = SDIW612---18.92.8.p52.2, -1-gc524d609-Test--MM6X18543.p18-GPL-(FP92) ） Re: IW612 bluetooth crash after a few days こんにちは、 @martinetd ご辛抱いただきありがとうございます。 本日、社内チームからPVTファームウェアを1つ受け取りました。弊社ではローカル環境で問題を再現できないため、共有されたPVTファームウェアで問題が解決するかどうかをご確認いただけますでしょうか。   ファームウェアの詳細： FW名: PVT_FW_1_combo.bin.se MD5SUM: c9eb78febccafa4772ed6c216215362a 注：このファームウェアは検証目的のみに使用されるものであり、公式リリースには使用されません。 追加の問題が見られた場合に備え、必須のFWダンプやbtmonログとdmesgログの共有を手伝ってください。 BR、 Christine。

Security Vulnerability CVE-2026-98432 – Impact on NXP Linux Kernels 5.4 and 5.15 Hello NXP Support Team, We are currently using the following Linux kernels: - linux-fslc-imx 5.4 - linux-fslc-imx 5.15 - linux-imx 5.15 We would like to know whether these kernel versions are affected by the critical security vulnerability CVE-2026-98432 (CVSS 9.8). CVE reference: https://nvd.nist.gov/vuln/detail/CVE-2026-98432 Could you please clarify the following points? 1. Are these kernel versions affected by this vulnerability? 2. If so, have security patches already been released for the affected kernel branches? 3. Which kernel versions or releases include the fix? 4. Could you please provide the corresponding patch or commit references? Thank you in advance for your support. Best regards Re: Security Vulnerability CVE-2026-98432 – Impact on NXP Linux Kernels 5.4 and 5.15 Hello, Yes, all three listed kernel baselines should be considered affected unless the specific vendor branch already contains a backport of the fix.   Have patches been released? Upstream and maintained stable branches have patches. Linux 5.4 requires a vendor or local backport because it no longer has an upstream maintained stable release. Which versions include the fix? For the relevant maintained branch, Linux 5.15.223 and later 5.15.y releases include it. For 5.4, there is no universal upstream fixed version, only vendor-specific packages or branches can be declared fixed. What is the corresponding patch? The primary reference is e3f33b0a1d89d738e2b913dab519226eaf76e15b, titled ipv4: free inet_opt and ireq_opt after an RCU grace period.

iMX95 CA 位交换 你好，恩智浦、 LPDDR5 是否允许 CA[6:0] 引脚的位交换？ 除了 EVK 的映射之外，还有什么成功的位映射可以用于 iMX95 吗？ 谢谢！ 西蒙 Re: iMX95 CA bit swapping 你好@simonng、 由于 i.MX95 仍在减产阶段，我们没有硬件设计供应。但根据以前的产品经验， 不支持 CA[6:0] 引脚互换。 希望能对您有所帮助 祝您有美好的一天 顺祝商祺！ Rita Re: iMX95 CA bit swapping 你好@simonng、 对于已经发布的 i.MX95版本，允许对 LPDDR5 的命令/地址 (CA[6:0]) 引脚进行位交换。 希望能对您有所帮助 祝您有美好的一天 顺祝商祺！ Rita