- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My setup:
- ARM host processor running 5.10 Linux.
- Murata 1MW BT/Wi-Fi combo chip (BCM43455) over SDIO
- Wi-Fi firmware: version 7.45.249
- Using linux/hostapd patch sets from "cypress-fmac-v5.10.9-2022_0511"
The issue:
After removing the brcmfmac kernel module, Bluetooth performs very poorly (drops active connections, scan no longer detects devices, sco audio is extremely crackly if the connection does not drop, etc.). This is only observed if Wi-Fi was associated to an AP within 3 seconds of kernel module removal. Re-inserting the module always corrects the issue.
Example steps to reproduce the issue:
- Start with brcmfmac modules loaded and associated to an AP, then run the following in a script:
ifdown wlan0
modprobe -r brcmfmac
- Bluetooth performs poorly
Then, I ran the following test:
- Start with brcmfmac modules loaded and associated to an AP, then run the following in a script:
wpa_cli disconnect
sleep 3
ifdown wlan0
modprobe -r brcmfmac
- Bluetooth functions normally.
Once I realized a 3 second delay after disconnect prevented the issue, I investigated to see how late in the module removal the delay could be placed before the issue began to occur again. I tried moving the delay into the kernel module itself and found that as long as the 3 second delay is put before the call to brcm_chip_set_passive() made in brcmf_sdio_remove(), then the issue is avoided. If I place it after that call, then I experience the poor Bluetooth performance.
It seems like the module is left in a state where Bluetooth is in low priority. Perhaps the module is still attempting to disassociate with the network when the chip is placed in passive mode? I am trying to understand what is happening so that I can avoid this issue properly, rather than inserting a long delay and hoping it is always sufficient.
Any insight as to what is happening would be greatly appreciated. It is difficult to find information on the BT/Wi-Fi coexistence mechanism used by this chip.
Thank you,
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @tstutter you can ifconfig wlan0 up/down instead of insmod/rmmod of WLAN driver. Please let us know if you need more assistance on the case. ?
regards
Vivek.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @tstutter , Thank you for the detailed explanation of the issue, this help to understand the issue better
Could you also share with us the NVRAM file used? i.e cyfmac43455-sdio.txt file located in /lib/firmware/cypress/ ?
Also can you please try adding the below coex parameter in the "cyfmac43455-sdio.txt" file if there are not present and check if the issue persists?
btc_mode=1
btc_params8=0x4e20
btc_params1=0x7530
btc_params50=0x972c
If the issue persists i can bring up the setup on my side.
Regards
Vivek.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the suggestion. I have attached the NVRAM file I am using. It looks like all those parameters are already defined in there.
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
i tried the following on the Raspberry pi with the following files attached and i could not reproduce the issue even with multiple connects and disconnects on 2.4Hhz on the WLAN and the BT receiving music with any noticeable performance drop
Could you please try the following and let us know the result
-> As a test could you please build the fmac driver as a loadable kernel module and try to rmmod and insmod brcmfmac.ko and check if the issue exists?
-> Does the issue of poor bt performance seen when only wpa_cli disconnect is called with calling the modeprobe -r brcmfmac ?
-> Could you please try the hcd file attached?
Regards
Vivek.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i tried the following on the Raspberry pi with the following files attached and i could not reproduce the issue even with multiple connects and disconnects on 2.4Hhz on the WLAN and the BT receiving music with any noticeable performance drop
Is the module (brcmfmac) being removed when you disconnect? This is critical when reproducing the issue. Simply connecting/disconnecting to the AP will not reproduce the issue on my setup either.
-> As a test could you please build the fmac driver as a loadable kernel module and try to rmmod and insmod brcmfmac.ko and check if the issue exists?
If I run rmmod/insmod instead of modprobe, it makes no difference. It is important to note that simply removing brcmfmac.ko while actively connected will not reproduce the issue. The issue occurs only when you remove brcmfmac immediately ( < 3 seconds) after disconnecting from an AP. Typically this happens by calling "ifdown wlan0".
Running the below script while connected to an AP will reproduce the issue.
#!/bin/sh
ifdown wlan0 (NOTE: will trigger a disconnect)
modprobe -r brcmfmac
Running the below script while connected to an AP will NOT reproduce the issue.
#!/bin/sh
ifdown wlan0 (NOTE: will trigger a disconnect)
sleep 3
modprobe -r brcmfmac
-> Does the issue of poor bt performance seen when only wpa_cli disconnect is called with calling the modeprobe -r brcmfmac ?
Yes, the issue only occurs when brcmfmac is removed immediately ( < 3 seconds) after a disconnect. In my actual use case, this disconnect is caused when I call "ifdown wlan0". I was simply using "wpa_cli disconnect" to illustrate the issue.
-> Could you please try the hcd file attached?
I was able to reproduce the issue with the hcd provided.
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @tstutter , i was able to reproduce the issue when rmmod brcmfmac.ko and Bluetooth resume to play music as soon as the brcmfmac.ko is loaded.
I am doing more tests and will get back to you soon on this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@tstutter , Could you please let us know more details of the application?
-> If the application is not using WiFi, the application could call "ifdown wlan0" instead of removing the brcmfac driver itself
->Does the application uses 43455 as only BT device ?
Regards
Vivek
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Vivek_gunapati wrote:-> If the application is not using WiFi, the application could call "ifdown wlan0" instead of removing the brcmfac driver itself
->Does the application uses 43455 as only BT device ?
The application is such that the user can enable/disable Bluetooth and/or WiFi on the device.
Currently, I am removing modules when the user turns off Wi-Fi for 2 reasons:
1) My experience with other designs using different Wi-Fi modules (not Broadcom/Infineon chips). Removing/re-inserting the kernel modules will avoid cases where Wi-Fi is "stuck" in a bad state due to driver or device firmware failures. Re-loading the modules will re-load both the driver and device firmware. However, I have not seen these issues yet on the 43455.
2) I want to save as much power as possible when Wi-Fi is not on. I assumed that removing the modules would put the chip in the lowest power state. I think I was wrong to assume this. I have done tests recently where the chip will draw much less current with the modules inserted and WiFi off (wlan0 down) than with with modules removed.
Summary:
I am willing to change my Wi-Fi off processing so that the modules are not removed. However, I would still like to know what is happening and how it can be reliably avoided.
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @tstutter , Sorry for the delay in response,
Our internal team was able to find the root cause of the issue and found out that RF switch control lines are going into an unknown state when the issue is seen. For now, the recommendation is to bring down the wlan0(ifconfig wlan0 down) when not in use and bring up wanl0 (ifconfig wlan0 up) when needed instead of insmod/rmmod the WLAN driver itself.
Regards
vivek.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @tstutter you can ifconfig wlan0 up/down instead of insmod/rmmod of WLAN driver. Please let us know if you need more assistance on the case. ?
regards
Vivek.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was able to modify my solution to use ifup/down. The system is stable and this change is acceptable.
Thank you for your support.