Removing brcmfmac modules impacts Bluetooth performance

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
tstutter
Level 1
Level 1
First solution authored 10 sign-ins 5 replies posted

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,

0 Likes
1 Solution

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.

View solution in original post

0 Likes
11 Replies
Vivek_gunapati
Moderator
Moderator
Moderator
250 replies posted 10 likes given 50 solutions authored

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.

0 Likes
lock attach
Attachments are accessible only for community members.
tstutter
Level 1
Level 1
First solution authored 10 sign-ins 5 replies posted

@Vivek_gunapati , 

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,

0 Likes
lock attach
Attachments are accessible only for community members.
Vivek_gunapati
Moderator
Moderator
Moderator
250 replies posted 10 likes given 50 solutions authored

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.

0 Likes

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,

0 Likes

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. 

 

0 Likes

@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

 

0 Likes

@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,

0 Likes
tstutter
Level 1
Level 1
First solution authored 10 sign-ins 5 replies posted

Hi, @Vivek_gunapati 

Does Infineon plan any further investigation into this issue?

Regards,

0 Likes

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.

0 Likes

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.

0 Likes
tstutter
Level 1
Level 1
First solution authored 10 sign-ins 5 replies posted

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. 

0 Likes