• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 43 subscribers
  • Views 4608 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL18xx does not work after a warm reboot

Stéphane Charette
Prodigy 120 points
Other Parts Discussed in Thread: WL1835

I'm using a BBGW (BeagleBone Green Wireless): TI AM335x with TI WL18xx. I've noticed that when the device is first powered up, the wifi works fine. But if I perform a warm reboot (such as issuing the command "sudo reboot" or "sudo shutdown -r now") then when it boots up, WIFI no longer works.

Instead, after a warm boot, "ifconfig" only shows the loopback interface, and I'm seeing messages such as these on the serial console every few seconds:

[ 612.676285] wlcore: ERROR firmware boot failed despite 3 retries
[ 620.458410] wlcore: ERROR timeout waiting for the hardware to complete initialization
[ 622.558761] wlcore: ERROR timeout waiting for the hardware to complete initialization
[ 624.634344] wlcore: ERROR timeout waiting for the hardware to complete initialization

Syslog also has error messages like this:

beaglebone kernel: [ 32.857933] ------------[ cut here ]------------
beaglebone kernel: [ 32.858199] WARNING: CPU: 0 PID: 1781 at drivers/net/wireless/ti/wlcore/main.c:797 wl12xx_queue_recovery_work.part.8+0x46/0x48 [wlcore]()
beaglebone kernel: [ 32.858207] Modules linked in: arc4 wl18xx wlcore mac80211 snd_soc_evm snd_soc_wilink8_bt omap_aes_driver omap_sham omap_rng rng_core snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap wlcore_sdio snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore evdev uio_pdrv_genirq uio usb_f_acm u_serial usb_f_rndis g_multi usb_f_mass_storage u_ether libcomposite cfg80211 rfkill
beaglebone kernel: [ 32.858314] CPU: 0 PID: 1781 Comm: irq/54-wl18xx Not tainted 4.4.19-ti-r41 #1
beaglebone kernel: [ 32.858321] Hardware name: Generic AM33XX (Flattened Device Tree)

I'm not sure where to go from here. Is this a known issue with the BBGW, that WIFI doesn't work after a warm reboot? If so, where can I find additional information, or is there perhaps a bug ticket I can subscribe to?

The build I'm using is this one: https://rcn-ee.com/rootfs/bb.org/testing/2016-09-04/seeed-iot/BBGW-blank-debian-8.5-seeed-iot-armhf-2016-09-04-4gb.img.xz 

If there is a better build or distro I should be using, please let me know.

  • 0
    TI__Mastermind 35795 points
    hi , We have received your query . We will get back to you shortly
    Saurabh
  • 0 in reply to S
    TI__Mastermind 20285 points
    No sure about this specific build.
    The image I have on my BBGW board (4.4.9-ti-r25 kernel based) doesn't show this issue.
    Better to address this with the BBGW forum.

    beagleboard.org/support
  • 0 in reply to Eyal Reizer
    Prodigy 120 points

    What builds are the official BBGW installation builds we should be using?

  • 0 in reply to Stéphane Charette
    TI__Mastermind 20285 points
    wl18xx is only one part of the BBGW release and we don't have this updated info.
    I suggest addressing this with the SeeedStudio BeagleBone Green Wireless team directly.
    See this link:
    beagleboard.org/green-wireless

    BR
    Eyal
  • 0
    Intellectual 425 points
    I have a similar problem, documented in this long thread: http://bit.ly/2d4nIYc

    My problem is primarily that I can't bring up wifi when bluetooth is enabled and vice versa. Also watch out for what looks to be a hardware error on the BT_EN and WL_EN signals that may or may not damage the BBGW.
  • 0 in reply to Jonatan Magnusson
    Prodigy 10 points

    Hello I am seeing same behavior of the wlcore failing in dmesg to wake up and as a result wlan0 is absent on BBGW. The BBGW has Linux distro version:

    user@beaglebone:~$ uname -a
    Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux

    We are seeing a random problem upon power up where the BBGW has an error with 'wlcore' and it appears the TI wifi module/driver does not start correctly and no wlan0 device is created as a result.
    First we see in dmesg:
    [   18.141777] wlcore: ERROR ELP wakeup timeout!
    and then it appears to re-attempt and this error is seen several times:

    [  358.866889] wlcore: ERROR timeout waiting for the hardware to complete initialization
    [  385.969657] wlcore: ERROR timeout waiting for the hardware to complete initialization
    [  412.859937] wlcore: ERROR timeout waiting for the hardware to complete initialization
    [  412.877118] wlcore: ERROR firmware boot failed despite 3 retries

     
     
    user@beaglebone:/opt/spa$ lsmod | grep wlcore
    wlcore                189892  1 wl18xx
    mac80211              486884  2 wl18xx,wlcore
    cfg80211              418909  3 mac80211,wl18xx,wlcore
    wlcore_sdio             8077  0 
    The BBGW is plugged in via it's micro-usb port to Windows and Mac workstation usb ports. This problem happens intermittently, probably 30% of power cycle instances result in this state.
    Are there any known issues with BBGW and the TI WiLink module not starting up correctly due to power draw over USB? 

     

  • 0 in reply to shawn reuland
    TI__Mastermind 20285 points

    I believe we have found the root cause for the BBGW wifi related issues.
    Bottom line is that BT_AUD_OUT from wl1835 has to be pulled low when WL_EN is activated.
    in case it isn't, wilink8 ends up in one of the test modes that introduces various issues (elp wakeup timeouts etc.)
    On the BBGW this pin is routed through the level shifter (U21) that introduces a pullup on the line and wilink8 ends up in a bad state.
    To work around this, I have used a gpio hog to force this pin low.
    An alternative may be adding an external pulldown on U21 pin 4 but this would require an ECO.

    Please see section 10.4 in the following document:
    www.ti.com/.../swru437.pdf

    You can see that AUD_OUT_BT has to be 0 when BT or WLAN enable bit is set to high.

    In addition, please make sure to use startup-delay-us=<70000> as below:

    	wlan_en_reg: fixedregulator@2 {
		compatible = "regulator-fixed";
		regulator-name = "wlan-en-regulator";
		regulator-min-microvolt = <1800000>;
		regulator-max-microvolt = <1800000>;
		startup-delay-us= <70000>;

		/* WL_EN */
		gpio = <&gpio3 9 0>;
		enable-active-high;
	};

    BR,
    Eyal

  • 0 in reply to Eyal Reizer
    Intellectual 425 points
    Can you confirm that using a gpio-hog has solved the problem for you? I've not been able to test it myself yet, but I recall using a DTS from Seeed Studio with this workaround in place some weeks ago but with same result.

    It looks like the Beaglebone Black Wireless, that is soon to be available, has BT_AUD_OUT configured the same way with no pull-down.
  • 0 in reply to Jonatan Magnusson
    TI__Mastermind 20285 points
    Yes it did. The hog I refer to is a different hog that just went in starting 4.4.26-ti-r59

    Please check the following patch:
    github.com/.../e7368daedc4d7a126b5cd4686b75a04fb0451d85

    The hog I talk about is this part:
    ...
    ++/* BT_AUD_OUT from wl1835 has to be pulled low when WL_EN is activated. */
    ++/* in case it isn't, wilink8 ends up in one of the test modes that */
    ++/* intruces various issues (elp wkaeup timeouts etc.) */
    ++/* On the BBGW this pin is routed through the level shifter (U21) that */
    ++/* introduces a pullup on the line and wilink8 ends up in a bad state. */
    ++/* use a gpio hog to force this pin low. An alternative may be adding */
    ++/* an external pulldown on U21 pin 4. */
    ++
    ++&gpio3 {
    ++ bt_aud_in {
    ++ gpio-hog;
    ++ gpios = <16 GPIO_ACTIVE_HIGH>;
    ++ output-low;
    ++ line-name = "MCASP0_AXR0";
    ++ };
    + };
    +--
    +2.9.3
    +

    The startup delay of the wlan-en-regulator is also important:
    ...
    + startup-delay-us= <70000>;
    ...

    BBBW doesn't have the same issue as the BBGW because the BT_AUD_OUT is not connected (routed to a TP only) and hence pulled down internally in the wl18xx module.

    BR,
    Eyal