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

Wi-Fi Bluetooth for Linux Forum Discussions

rupesh_theatro
Level 3
Level 3
10 replies posted 5 replies posted 5 questions asked

Hi All,

We are using CYW43012 chipset and here are our details:

Firmware version:
1.21 RC0.0
wl0: Feb 21 2022 07:19:28 version 13.10.271.283 (211da63 CY) FWID 01-18f4ac2
Driver Version:
Backported Linux Version v5.10.9-2022_0321-0-ga0971bc0b123

wl clmver:
API: 18.2
Data: 9.10.0
Compiler: 1.36.1
ClmImport: 1.34.1
Creation: 2019-12-13 03:26:37

As part of our device reboot process, we reset the wlan gpio to reset the power to our chipset CYW43012 without removing driver modules for proper mmc detection on the next boot.

We have observed the following errors whenever we issue reboot and the device waits continuously without rebooting:

Error #1:

brcmfmac: brcmf_sdio_read_control: read 1536 control bytes failed: -84
[ 95.450000] brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK
[ 98.000000] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[ 322.430000] brcmfmac: brcmf_sdio_rxfail: count never zeroed: last 0xffff
[ 322.440000] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
[ 322.450000] brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK
[ 558.220000] brcmfmac: brcmf_sdio_rxfail: count never zeroed: last 0xffff
[ 558.230000] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
[ 558.340000] brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK
[ 787.010000] brcmfmac: brcmf_sdio_rxfail: count never zeroed: last 0xffff
[ 787.020000] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110

We have also seen cases where device reboots but will take lot of time, atleast a minute, for the device to reboot as it waits most of the time in the below types of error cases:

Error #2:

[ 197.250000] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
[ 197.260000] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[ 197.280000] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[ 197.310000] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[ 197.330000] brcmfmac: brcmf_sdio_dpc: sdio ctrlframe tx failed err=-110
[ 197.330000] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110

Error #3:

[ 219.340000] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
[ 219.350000] brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
[ 219.440000] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
[ 219.450000] brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation 

 

We do observe that these issues doesn't occur if we rmmod all the modules before we reset the wlan gpio.

We would like to understand if this is a bug or is there a way to handle the sudden wlan power off scenario without any issues.

@raks_99 @GauravS_31 @VinayakS_26 

Regards,

Rupesh

0 Likes
1 Solution

Hi Rupesh,

As we discussed, you can kill host side supplicant, rmmod the driver and then remove power to over come the issue. Marking this issue as resolved.

Thanks

View solution in original post

10 Replies
raks_99
Moderator
Moderator
Moderator
250 replies posted 250 sign-ins 100 replies posted

Hi Rupesh,

Is this your current process:

Reset with WL_REG_ON toggle -> and then you issue the reboot command.

Which host are you using and who is the module maker? Sometimes the GPIOs are not fully reset when a soft reboot is done. Can you try with hard reboot (shutdown , remove power for couple seconds, start)

and 

>>".. for the device to reboot as it waits most of the time in the below types of error cases:"

So you mean these are acting as blockers for the reboot? These are mostly printk statements, so the host would not be waiting for these in my opinion.

0 Likes
rupesh_theatro
Level 3
Level 3
10 replies posted 5 replies posted 5 questions asked

Hi @raks_99 

We are using Linux host with Microchip's ATSAMA5D2X processor and Azurewave is the module maker.

No we are not toggling WL_REG_ON when I say reset the power, we are disabling the 1.8V power supply to our Wi-Fi chipset and then issue reboot.

>>"So you mean these are acting as blockers for the reboot? These are mostly printk statements, so the host would not be waiting for these in my opinion."

I don't know whether they are acting as blockers or not. I am just seeing those errors continuously whenever the issue happens and I am assuming the driver is trying continuously to recover/transact (which is causing the prints contiunously) is causing the issue and I might be wrong.

Any help will be deeply appreciated.

Regards,

Rupesh.

 

0 Likes
raks_99
Moderator
Moderator
Moderator
250 replies posted 250 sign-ins 100 replies posted

I made a quick check with i.MX8 and 4373. The SDIO errors are normal in this case. I did not notice a delay. Will check again with the 43012 device

Thanks,

Rakshith

0 Likes

Hi Raksith @raks_99 

I have gone through your log. Can you please remove or stop "rmmod"ing the modules while you power off the module and issue reboot. That is the usecase we are looking into.

Regards,

Rupesh

0 Likes
raks_99
Moderator
Moderator
Moderator
250 replies posted 250 sign-ins 100 replies posted

Hi @rupesh_theatro ,

The rmmod you see in the beginning is part of the load.sh script

The load.sh scripts rmmods the existing drivers and then insmods them again.

Since it was a fresh start, there are no drivers to rmmod so you see the "rmmod: ERROR: Module brcmfmac is not currently loaded" print in the log.

My process was, start the host -> load the drivers -> bring up complete -> Kill the VBAT voltage line -> Reboot..

 

 

0 Likes

Hi @raks_99 

I was referring to the print in the end of the log:

[ 106.225170] brcmfmac: brcmf_sdio_bus_stop: Failed to force clock for F2: err -110
[ 106.391655] usbcore: deregistering interface driver brcmfmac
[ 106.397371] kvm: exiting hardware virtualization
[ 106.451342] imx2-wdt 30280000.watchdog: Device shutdown: Expect reboot!
[ 106.458911] reboot: Restarting system

Based on the prints, I suspected reboot handler is unloading the module .

Also please perform the test while you are running data traffic like iperf as it simulates our device behavior.

Regards,

Rupesh

0 Likes

Hi Rupesh,

As we discussed, you can kill host side supplicant, rmmod the driver and then remove power to over come the issue. Marking this issue as resolved.

Thanks

Accepting this as a solution!!

0 Likes
rupesh_theatro
Level 3
Level 3
10 replies posted 5 replies posted 5 questions asked

Hi @raks_99 

Any update on this?

Regards,

Rupesh

0 Likes

If I understood your initial post correctly, your reboot sequence is to disable the 1.8V supply only, then issue a soft reboot.  You are leaving WL_REG_ON high during the process.  That doesn't sound valid to me.  

Please include WL_REG_ON in the reset sequence.  See the datasheet for details on reset requirements.

0 Likes