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.
記事全体を表示
