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
View full article
