- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- 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 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Accepting this as a solution!!
- 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
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.