Bluetooth disconnections possibly due to coexistence

[arthur-proglove]

Hello,

We are experiencing BLE connectivity issues with the Raspberry Pi 0 W.
The Pi is used as a central and for no apparent reason the connection is randomly dropping between the Pi and the BLE peripheral.

What we have noticed is that this seems to happen only when a Wi-Fi connection is active which leads us to think it might be a coexistence issue between the 2 chips. Maybe the Wi-Fi part is taking the antenna too long and the Bluetooth connection times out?
Maybe we could change the NVRAM parameters but we have no idea what they are.

We have checked the power and tried with a direct USB connection to a computer or with a power supply, the issue happens in both cases.
We enabled the Bluetooth HCI and the brcmfmac modules trace logging but this did not show up any errors.
We also tried to increase the BLE connection supervisor timeout but the disconnections still happen.

Could someone please help us finding out what could be the root cause of the issue?

Thank you

[pelwell]

The NVRAM parameters are black boxes to us - we don't have descriptions of their functions or legal values - but you could try commenting out the end of brcmfmac43430-sdio.txt to see if it changes the behaviour in either direction:

# Improved Bluetooth coexistence parameters from Cypress
#btc_mode=1
#btc_params8=0x4e20
#btc_params1=0x7530

Can you also report the kernel and firmware versions you are running;

$ uname -a
$ vcgencmd version
$ dmesg | grep brcmf

[arthur-proglove]

Hi,

pi@rpi-54A4DD64:~ $ uname -a
Linux rpi-54A4DD64 5.15.32 #1 Mon Sep 26 09:42:09 UTC 2022 armv6l GNU/Linux

pi@rpi-54A4DD64:~ $ vcgencmd version
Mar 24 2022 13:20:54 
Copyright (c) 2012 Broadcom
version e5a963efa66a1974127860b42e913d2374139ff5 (clean) (release) (start)

pi@rpi-54A4DD64:~ $ dmesg | grep brcmf
[   13.193476] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[   13.346856] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[   13.348091] usbcore: registered new interface driver brcmfmac
[   13.348867] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,model-zero-w.bin failed with error -2
[   13.673994] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[   13.674215] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[   13.685340] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Jul 19 2021 03:24:18 version 7.45.98 (TOB) (56df937 CY) FWID 01-8e14b897
[   23.123203] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

pi@rpi-54A4DD64:~ $ journalctl -u hciuart.service 
-- Journal begins at Thu 2023-02-16 14:17:02 GMT, ends at Mon 2023-02-20 15:03:36 GMT. --
Feb 16 14:17:12 rpi-54A4DD64 systemd[1]: Starting Configure Bluetooth Modems connected by UART...
Feb 16 14:17:18 rpi-54A4DD64 btuart[350]: bcm43xx_init
Feb 16 14:17:18 rpi-54A4DD64 btuart[350]: Flash firmware /lib/firmware/brcm/BCM43430A1.hcd
Feb 16 14:17:18 rpi-54A4DD64 btuart[350]: Set BDADDR UART: b8:27:eb:0e:77:ce
Feb 16 14:17:18 rpi-54A4DD64 btuart[350]: Set Controller UART speed to 3000000 bit/s
Feb 16 14:17:18 rpi-54A4DD64 btuart[350]: Device setup complete
Feb 16 14:17:18 rpi-54A4DD64 systemd[1]: Started Configure Bluetooth Modems connected by UART.

I will try to disable the btc settings and see if that helps.

[arthur-proglove]

More details about our setup: we are connecting to Wi-Fi using NetworkManager and rely on BlueZ via D-Bus for the Bluetooth connection.

Could you maybe advise us on any tools we could use/acquire to find out what is exactly happening so that we can understand exactly why this issue is happening?

btmon/hcidump are useful but only show that a disconnection happened with "Timeout" as a reason.

[pelwell]

btmon and friends show the entirety of the interaction with the BT modem. Looking any deeper requires an over-the-air sniffer - something even we don't have.

Can you give any details of the Bluetooth setup:

• Is it BLE or regular Bluetooth?
• How many devices?
• What is the data rate?
• How frequently are they contacted?

[arthur-proglove]

To clarify our use case: we use the Raspberry Pi to connect to BLE barcode scanners. The scanners are sending their barcode data via BLE and the Raspberry Pi is then used to send via HID (using the usb-gadget module) or over Wi-Fi the barcode to a terminal.

So, to answer your questions:

• We're using BLE only
• We connect to up to 5 devices simultaneously but
• The issue happens when only one device is connected as well
• The frequency varies but we can assume there is some BLE activity every 10 seconds
• The data exchanged is in the range 10-500 bytes for every scan

[pelwell]

Understood.

I think it would be helpful to post/link to a btmon capture of such a disconnection event and any contemporary traffic, if you have one. If you have one showing the entire connection lifetime that would be great, but I don't think it's vital.

It would also be good to get a feel for:

• whether the disconnection only affects one device or do others continue unaffected
• what remedial action is necessary to get the system back to a usable state, i.e. can you just reconnect to the dropped device?

[arthur-proglove]

I do not have logs to provide yet but the pattern we see is:

• The disconnection happens
• The peripheral starts advertising automatically immediately
• The Raspberry Pi tries to connect to it
• The connection is established but immediately fails with a 0x3E error: Connection Failed to be Established
• Over and over until it can reconnect after some time (1-5 mins) and can be operational again

Worth to mention:

• The Raspberry Pi and the peripheral are never more than 3m apart
• The Raspberry Pi is permanently doing an active scan even when the connection is active
• The scanning is stopped before trying to establish a connection and restarted afterwards

I cannot tell about more devices as we are only trying and seeing this issue with only one device connected.

[pelwell]

I think the combination of timeout and subsequent failures, coupled with a log, might be enough to send to Infineon (previously Cypress). Anything you can do to demonstrate that there's nothing wrong with the device itself (e.g. connecting in from another Pi) and that the controller is in a bad state (e.g. failing to connect to a different device) would strengthen the case.

[arthur-proglove]

It seems like we just managed to reproduce it manually.

I have 3 peripherals connected to the Pi.

Steps to reproduce:

• Have 2 Wi-Fi access point/repeater using the same SSID
• Shut down the AP the Raspberry Pi is connected to
• The 3 peripherals disconnect immediately

Bonus: The Raspberry Pi keeps failing to reconnect to those devices with 0x3e error. As soon as I disconnect from the Wi-Fi they reconnect and work again.

What would be the process to share this with Infineon?

[pelwell]

Interesting. This sounds a lot like another problem that manifests as the Zero 2 W WiFi firmware crashing - see raspberrypi/firmware#1768. I wonder if the affected Zero 2 W's would also be experiencing Bluetooth failures but just haven't noticed?

Do you think this failure mode is likely to account for the problems that you've seen, i.e. is roaming between APs likely to have occurred?

We have the support relationship with Infineon, so if you gather as much information as you can and either post it here or email it to me - [email protected] - I'll open a ticket.

[pelwell]

If it's at all feasible to run with just a single AP and no repeater, or with separate SSIDs, then I suggest you do that to confirm that the Bluetooth failures go away when you do.

[arthur-proglove]

I'll test soon with two AP with 2 different names and see but so far with only one AP the issue does not happen.

With one repeater, I reproduced the issue and enabled the logging.
You can find attached the btmon logs and the dmesg logs with the bluetooth and Wi-Fi modules extra logging.

btmon.log
dmesg.log

• The Pi is connected to one repeater
• The repeater is switched off to force the Pi to connect to the original AP
• The peripheral disconnects and has issues reconnecting

The disconnect happened at 15:43:04 immediately after I switched off the repeater the Pi was connected to.

> HCI Event: Disconnect.. (0x05) plen 4  #183 [hci0] 2023-02-21 15:43:04.931911
        Status: Success (0x00)
        Handle: 64
        Reason: Connection Timeout (0x08)

Then we can see it tries to reconnect and fails with 0x3e

< HCI Command:... (0x08|0x000d) plen 25  #195 [hci0] 2023-02-21 15:43:07.143390
        Scan interval: 60.000 msec (0x0060)
        Scan window: 60.000 msec (0x0060)
        Filter policy: White list is not used (0x00)
        Peer address type: Random (0x01)
        Peer address: C2:BD:C5:68:39:F3 (Static)
        Own address type: Public (0x00)
        Min connection interval: 30.00 msec (0x0018)
        Max connection interval: 50.00 msec (0x0028)
        Connection latency: 0 (0x0000)
        Supervision timeout: 420 msec (0x002a)
        Min connection length: 0.000 msec (0x0000)
        Max connection length: 0.000 msec (0x0000)
> HCI Event: Command St.. (0x0f) plen 4  #196 [hci0] 2023-02-21 15:43:07.144222
      LE Create Connection (0x08|0x000d) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta E.. (0x3e) plen 19  #197 [hci0] 2023-02-21 15:43:07.160917
      LE Connection Complete (0x01)
        Status: Success (0x00)
        Handle: 64
        Role: Master (0x00)
        Peer address type: Random (0x01)
        Peer address: C2:BD:C5:68:39:F3 (Static)
        Connection interval: 48.75 msec (0x0027)
        Connection latency: 0 (0x0000)
        Supervision timeout: 420 msec (0x002a)
        Master clock accuracy: 0x00
@ MGMT Event: De.. (0x000b) plen 44  {0x0001} [hci0] 2023-02-21 15:43:07.161231
        LE Address: C2:BD:C5:68:39:F3 (Static)
        Flags: 0x00000008
          Unknown device flag (0x00000008)
        Data length: 31
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
        128-bit Service UUIDs (complete): 1 entry
          Vendor specific (edeb0000-eb7d-4f49-b749-4a78607395dd)
        Name (short): PGGW-015
< HCI Command: L.. (0x08|0x0016) plen 2  #198 [hci0] 2023-02-21 15:43:07.162041
        Handle: 64
> HCI Event: Command St.. (0x0f) plen 4  #199 [hci0] 2023-02-21 15:43:07.164561
      LE Read Remote Used Features (0x08|0x0016) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta E.. (0x3e) plen 12  #200 [hci0] 2023-02-21 15:43:07.479147
      LE Read Remote Used Features (0x04)
        Status: Connection Failed to be Established (0x3e)
        Handle: 64
        Features: 0x1f 0x00 0x00 0x08 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Slave-initiated Features Exchange
          LE Ping
          Remote Public Key Validation
< HCI Command: D.. (0x01|0x0006) plen 3  #201 [hci0] 2023-02-21 15:43:07.480259
        Handle: 64
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Disconnect.. (0x05) plen 4  #202 [hci0] 2023-02-21 15:43:07.481600
        Status: Success (0x00)
        Handle: 64
        Reason: Connection Failed to be Established (0x3e)
@ MGMT Event: Dev.. (0x000c) plen 8  {0x0001} [hci0] 2023-02-21 15:43:07.481922
        LE Address: C2:BD:C5:68:39:F3 (Static)
        Reason: Unspecified (0x00)

[arthur-proglove]

Just tried with 2 access point with 2 different name.
If I switch off one, the Pi will connect to the other one without causing a disconnect of Bluetooth

[pelwell]

Great, thanks. I'll throw that over the wall to Infineon, and in the meantime I hope you can use those findings to create a workaround.

[arthur-proglove]

I could reproduce the issue on a regular Raspberry Pi 0W without any modification from our side (just to highlight that the issue is not coming from our side).

Steps to reproduce

• Flash a Raspberry Pi with the latest Raspbian image
• Connect it to a Wi-Fi access point with at least one repeater using NetworkManager
• wpa_supplicant alone will not work as we need the software to try to hop to the next available access point (roaming)
• Connect to a BLE device with bluetoothctl
• Switch off the access point the Pi is connected to
• The Bluetooth device disconnects

[arthur-proglove]

Just an update on my configuration that produced the issue 100% of the time so far:

• One access point router
• One TPLink Range Extender AC750 RE200
• Connect the Raspberry Pi to this range extender (by forcing the BSSID)
• Connect a Bluetooth device with bluetoothctl
• Power of the extender
• The connection to the Bluetooth peripheral drops

Let me know if you need anything else

[pelwell]

I'm currently waiting for a response from Infineon. I'll update you when I hear back.

[arthur-proglove]

Thank you for the reply Phil, is there any way we can be put in the loop?

[pelwell]

We've had the first significant response from Infineon, with their suggestion being to ensure that btcxlescan=1 is present in the "NVRAM" file. It isn't currently, so can you run this command to add it?:

$ echo btcxlescan=1 | sudo tee -a /lib/firmware/brcm/brcmfmac43430-sdio.txt
$ tail  /lib/firmware/brcm/brcmfmac43430-sdio.txt

A reboot is required for the change to take effect.

They then went on to say:

Meanwhile could you please let us know what profile is running on the BT side?

I'm not convinced this would be relevant since it doesn't appear that you need any BLE data traffic to observe the disconnections, but to keep the dialogue going what would you say is your profile?

[arthur-proglove]

Hi Phil and thank you for the answer.

btcxlescan is definitely not set in the txt file (we're using the default Raspberry Pi one).
I'll set it and see if that improves anything. Do you know what is it related to?

Regarding the profile, we are acting as a central and there is actually no need to have a lot of traffic to see the disconnect happening.

[pelwell]

Do you that "we are acting as a central" is a phrase they are likely to understand?

[pelwell]

It's not inconceivable that their firmware does some tuning based on profiles, so as complete an answer as possible is recommended.

[arthur-proglove]

Sorry, I am not sure I understand exactly what you mean by "profile".
We are connecting to a device over BLE but there is not need to even subscribe to any special characteristics to see the disconnect.
Otherwise our normal usage would be a single GATT characteristic that we subscribe to to receive events from and write to. No special Bluetooth profile like HID is used.

[pelwell]

GATT is an acronym for the Generic ATTribute Profile, so the profile in your case is GATT.

[pelwell]

And the btc in btcxlescan stands for BlueTooth Coexistence - beyond that I don't know.

[arthur-proglove]

GATT is an acronym for the Generic ATTribute Profile, so the profile in your case is GATT.

You are right, we're using the GATT profile to exchange data.
I'll test the new settings.

[arthur-proglove]

Hi Phil,

We just tried with btcxlescan=1 but unfortunately the disconnect still happened.

[pelwell]

I'll see what they say about that.

[pelwell]

I've finally received a substantive response, which is the suggestion to try the most recent stock firmware.
You can download it from here: https://drive.google.com/file/d/1elivJ12TykQV0O5YOKwoMNh3axNd6ynn/view?usp=share_link

To install:

$ sudo mv /lib/firmware/brcmfmac/brcmfmac43430-sdio.bin /lib/firmware/brcmfmac/brcmfmac43430-sdio.bin.orig
$ sudo cp brcmfmac43430-sdio.bin.230314 /lib/firmware/brcmfmac/brcmfmac43430-sdio.bin

To revert:

$ sudo mv /lib/firmware/brcmfmac/brcmfmac43430-sdio.bin.orig /lib/firmware/brcmfmac/brcmfmac43430-sdio.bin

Note that the backing up of the firmware may actually be renaming a symbolic link, depending on the image you are using, but that shouldn't make any difference.

[arthur-proglove]

Thanks a lot Phil, I will test this today and come back to you :-)

[arthur-proglove]

I just tried the new firmware with and without btcxlescan=1. In both cases the disconnect still happens

[pelwell]

Thanks for the quick response - I had a feeling that was going to be the case.

[pelwell]

There are signs somebody is starting to think about the problem, in the shape of some questions. Quoting directly:

1. Can you confirm this only happens in the case where device is connected to extender, extender is powered off/out of range?

2. In case number 1, we are assuming the device will try to reconnect with AP, correct? Since we do not have OTA logs could you print something out to verify this?

3. Does reconnect to AP work after disconnect from extender and WiFi connection is established – what is state of Wifi connection?

4. After device Wifi disconnects from AP can it reconnect? Do BLE connections work after Wifi has been disconnected/reconnected to AP?

From what you've told me my answers would be:

1. Yes.
2. (I'd try and bluff my way out of this, but perhaps you have something)
3. Yes - the AP connection works.
4. Yes.

Is that correct? Do you have anything to add?

[arthur-proglove]

Hi Phil,

There are signs somebody is starting to think about the problem, in the shape of some questions. Quoting directly:

That's actually great news ;-)

1. Can you confirm this only happens in the case where device is connected to extender, extender is powered off/out of range?

Actually, no. We have first noticed the disconnections at some of our customers that are using other types of Wi-Fi devices.
The repeater disconnection is a trigger to enter this faulty state, but not the only case that the random disconnection happens. We have not yet narrowed down all the scenarios that trigger this behavior.
But yes, definitely using this specific repeater we are able to trigger the Bluetooth disconnect by switching it off.

2. In case number 1, we are assuming the device will try to reconnect with AP, correct? Since we do not have OTA logs could you print something out to verify this?

I will provide you as much logs as I can tomorrow.

3. Does reconnect to AP work after disconnect from extender and WiFi connection is established – what is state of Wifi connection?

Yes, a reconnect to a different AP works.

4. After device Wifi disconnects from AP can it reconnect? Do BLE connections work after Wifi has been disconnected/reconnected to AP?

After the Pi disconnects from the AP, it can reconnect to the BLE device but with some difficulties. It needs multiple retries with the error Connection Failed to be Established (0x3e).

From what you've told me my answers would be:

1. Yes.
2. (I'd try and bluff my way out of this, but perhaps you have something)
3. Yes - the AP connection works.
4. Yes.

Is that correct? Do you have anything to add?

[arthur-proglove]

Hi Phil,

I captured some logs during the following scenario

• Start NetworkManager
• Wait for the Pi to connect to the AP
• Start bluetoothctl
• Connect to my BLE device
• Unplug the AP
• The BLE device disconnects

Please find attached the NetworkManager and btmon logs.
Let me know if you need anything more.

NetworkManager.log
btmon.log

[pelwell]

More questions from Infineon:

Thank you for the logs. It looks like the chip tries to reconnect to AP once it loses connection but it’s unclear if it keeps trying afterwards. Can you confirm if you continue to try connecting to the same AP? Could you keep the logs recording until chip is able to reestablish connection with the same AP?

Regarding #3, is Bluetooth able to connect without issues once connection to different AP is established?

For #4, is the chip able to reestablish connection to the same AP once disconnected, and if so is Bluetooth able to connect without issues once this is established? In the logs you sent us it does not show it connecting to the same AP connection again.

Also some additional questions,

5.Do you have a full picture of the test setup?

6.What are settings of AP?
a.SSID?
b.DHCP Enabled?
c.NAT enabled?

7.How is Extender connected to AP?
a.Does it use same SSID as AP?
b.Does it just copy settings from AP during setup? (SSID, PW, etc) Or is it an actual router connected to AP and has DHCP, NAT etc disabled?

8.After initial AP/extender connection failed is it a manual step to reconnect to the 1st AP? or is it trying to auto-connect?

9. Are you testing in lab with lots of 2.4G devices? Then there would be a lot of RF noise and connections could fail. Could you test in a clean environment?
   ===========================

I feel you've answered some of these already, but I'm relaying them all for completeness and to avoid something getting misconveyed.

[arthur-proglove]

Hi,

More questions from Infineon:

Thank you for the logs. It looks like the chip tries to reconnect to AP once it loses connection but it’s unclear if it keeps trying afterwards. Can you confirm if you continue to try connecting to the same AP? Could you keep the logs recording until chip is able to reestablish connection with the same AP?

I will do that and provide the logs. I only recorded until the switch off of the AP.

Regarding #3, is Bluetooth able to connect without issues once connection to different AP is established?

For #4, is the chip able to reestablish connection to the same AP once disconnected, and if so is Bluetooth able to connect without issues once this is established? In the logs you sent us it does not show it connecting to the same AP connection again.

We forced the BSSID in the NetworkManager configuration so that it will only connect to this particular AP that we switch off.
The Raspberry Pi will not try to connect to another AP even if they have the same SSID.
I will also test just setting the SSID, it's just harder to trigger the disconnect as we cannot control to which AP the Pi will connect to first.

Also some additional questions,

5.Do you have a full picture of the test setup?

No, I can provide photos and videos.

6.What are settings of AP? a.SSID? b.DHCP Enabled? c.NAT enabled?

DHCP is enabled, the encryption is WPA personal. I dot know about NAT.
Here is the repeater information:
repeater.txt

7.How is Extender connected to AP? a.Does it use same SSID as AP? b.Does it just copy settings from AP during setup? (SSID, PW, etc) Or is it an actual router connected to AP and has DHCP, NAT etc disabled?

The repeater is just copying the settings from the AP and does not have an internal DHCP server.

8.After initial AP/extender connection failed is it a manual step to reconnect to the 1st AP? or is it trying to auto-connect?

If we replug the repeater, the Pi will reconnect to it automatically with NetworkManager

9. Are you testing in lab with lots of 2.4G devices? Then there would be a lot of RF noise and connections could fail. Could you test in a clean environment?

We are testing this in an office with a lot of 2.4G noise around (BLE devices and connected to Wi-Fi 2.4 GHz).
The issue does not happen in quiet environment.

I feel you've answered some of these already, but I'm relaying them all for completeness and to avoid something getting misconveyed.

Is there a possibility to include us in the ticket opened with Infineon?

[pelwell]

I've passed on those answers. For the avoidance of any doubt, can you confirm that the answer to question 3 should be Yes?

Is there a possibility to include us in the ticket opened with Infineon?

I'm not sure what you are hoping to achieve, but get yourself an Infineon login and I'll give it a try.

[pmessan]

Hello Phil, I work with @arthur-proglove and will jump in from time to time. I can confirm the answer to question 3 is yes.
For the Infineon login(s), @arthur-proglove's email is [email protected], and mine is [email protected]. Would be great if you could include us both so we can stay up to date on what happens, if any action is needed from our side.

[pelwell]

Arthur's email address is recognised by Infineon and he has been added as a collaborator. You will have to register with them first before I can add you.

[pmessan]

Mine is registered now, please try adding me again. Thanks!

[pelwell]

The Infineon site doesn't accept it:

Please advise your contact to register and login to the case management portal.

[pmessan]

The Infineon site doesn't accept it:

Please advise your contact to register and login to the case management portal.

The issue should be fixed now :)

[pelwell]

Better.

[pelwell]

A new issue (#13) has some similarities in that it covers coexistence, and there the suggestion is that setting btc_mode=4 in the "NVRAM" configuration file may help. Can you try it while we wait for more ideas from Infineon?

[pmessan]

We already tried this. The result was that Wifi performance was severely impacted, in that wifi connections took longer to establish. This ultimately however did not get rid of the issue as we were still able to reproduce the Bluetooth disconnections with the repeater with btc_mode=4

[pelwell]

Infineon have requested that you:

try dumping “wl btc_params 51” continuously when BLE connection is initiated from host?

[pmessan]

Hi Phil,
So we ran wl btc_params 51 4 times per second while establishing a BLE connection. The output of the command was constant throughout (i.e. 0x40df).
We also ran it the same way during the repeater disconnection scenario, and there the output was also the same value.

[arthur-proglove]

Hi,

As a side note. We tested with a Raspberry Pi 2W and could not reproduce the issue.
AFAIK, the chip is still a Broadcom one (43436s) but handled by Synaptics, not Infineon.

[pelwell]

That's a very useful data point. The 43438/43430, 43436s and 43436p are sister chips, the 43436p being slightly newer. It may be possible (though unsupported, and for test purposes only) to use the 43436s firmware on a 43438/43430:

$ cp /lib/firmware/brcm/brcmfmac43430-sdio.bin brcmfmac43430-sdio.bin.orig
$ sudo cp /lib/firmware/brcm/brcmfmac43436s-sdio.bin /lib/firmware/brcm/brcmfmac43430-sdio.bin

Revert with:

$ sudo cp brcmfmac43430-sdio.bin.orig /lib/firmware/brcm/brcmfmac43430-sdio.bin

[arthur-proglove]

Hi Phil,

I tried 5 times in a row and could not get it to disconnect on a Pi Zero W with the firmware of the Pi Zero 2W.
How different are the chips and would it be safe to use the firmware for production?

[pelwell]

That's not something I can advise you to do - it's not the intended firmware, and as such its use comes with no support or warranty - but I doubt it would cause any problems.

[pelwell]

Proglove people (I love prog too ;-)), did any of you try with sudo ./wl -i wlan0 btc_params 51 0x40FF, as Infineon asked?

[arthur-proglove]

Hi Phil ;-)

Yes, we tried it. We set the param 51 to 0x40ff but the disconnect still happened.
As soon as we start a BLE scan the parameter goes to 0x40bf.

[pelwell]

There's a new test firmware - test6 - that sets btc parameter 51 to 0x40ff:
https://drive.google.com/file/d/1pgQOt1X2vPK-6u2I1I7Pgp5DFasP3BYO/view?usp=share_link

It's same as the one shared on the Infineon case, I just renamed it to fit the existing naming scheme. I'm not sharing the clm_blob because we ship a tailored one already and I'd rather test with that.

[arthur-proglove]

Same thing on our side, it still disconnects :-)

[davidalo]

Following this issue as well as #13, similar problem here. Using CYW4343W in custom board. I will test some of your proposals.

You can detailed see my problem here