• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 41 subscribers
  • Views 3339 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Wilink8 RSSI cutoff threshold (Wifi connection dropping around -60dBm)

tvich11
Prodigy 225 points

Other Parts Discussed in Thread: WL1801MOD

Hello,

First, the information on our system.

  • TI Sitara AM335X on a custom PCB
    • custom hardware and build, no SDK really
  • Linux
  • Wilink8 WL1801MOD
  • TI part
Firmware version:
root@roadkill:~# strings /lib/firmware/ti-connectivity/wl18xx-fw-2.bin | grep Rev
FRev 8.8.0.0.13
Rev 8.2.0.0.195

Kernel module version
root@roadkill:~# modinfo wl18xx
filename:       /lib/modules/3.12.10/kernel/drivers/net/wireless/ti/wl18xx/wl18xx.ko
firmware:       ti-connectivity/wl18xx-fw-2.bin
author:         Luciano Coelho <coelho@ti.com>
license:        GPL v2
srcversion:     BEC42A20B9E32185D799C5C
alias:          platform:wl18xx
depends:        wlcore,cfg80211,mac80211
intree:         Y
vermagic:       3.12.10 mod_unload modversions ARMv6 p2v8

We are having trouble keeping our Wilink8 connected to wifi at low signal levels. It seems that as soon as the signal strength gets down to about -60dBm, the connection drops. We have done a few tests with a few different antennas both with our board and by connecting the antenna we are using with our board to a laptop, and that has not indicated that we have an antenna problem. We tried going through some of the IW commands/settings to fix the problem to no avail. Specifically, 

iw dev wlan0 cqm rssi off
This command supposedly sets or turns off an rssi threshold setting (I think)

iw dev wlan0 set txpower fixed 30mBm
This command sets the transmit power of the device. 

For both of these commands, there is no 'get' to check the status of the setting. That is, I am unable to confirm whether or not the change took place. Is there a way to check this that I'm missing?

Furthermore, on running
iw reg get

I see this
>>country 00: DFS-UNSET

And even if i try to set it
iw reg set US

Nothing happens
iw reg get
>>country 00: DFS-UNSET

Is the country code is hardcoded in the device EEPROM?  Can this be changed or verified? The country code can impact which frequencies can be communicated on, I'm wondering if this is a part of the problem.

Any ideas as to why the device is disconnecting from wifi around -60dBm? I can see signal levels down to -75dBm on my computer (Mac book air Broadcom chipset)  before disconnecting from the same network. 

The access point that I'm connected to is a cisco AIRCAP3702 and I've set the transmit power on that to the highest setting. The problem also occurs with a number of different access points as well including an apple airport extreme and airport express. 

Thanks.

Mike

  • 0
    TI__Guru* 85400 points
    Hi Mike,

    Your firmware version looks really old! Please upgrade to the latest "8.9.0.1.55".
    You can follow the instructions from: processors.wiki.ti.com/.../WiLink8_Linux_Getting_Started_Guide

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Prodigy 90 points

    Updating the firmware (and hence the entire SDK in order to get the 4.1 kernel
    capable of loading the new firmware) did indeed help.  That's a perfectly fine
    solution for boards we're currently developing.  However, we also have
    production units that have already been deployed with the older version of
    firmware that was current with the TI SDK when we started development
    approximately a year ago.

    For those units in the latter case, we cannot simply move to the newest SDK.
    The entire graphics stack was changed and appears to still be in flux even in
    the current 4.1 kernel.  Can you provide any advice for how to carry on in that
    case?  Are there any tunable parameters in wl18xx-conf.bin that are relevant?
    Can you point to what exactly changed in the newer firmware/driver that would
    have contributed to the issue being resolved?  Perhaps that is something we can
    backport.

  • 0 in reply to jsb
    TI__Guru* 85400 points
    Hi,

    The release that you are using (R 8.3) is >2 years old.
    There were three releases in between (R8.4, R8.5 & R8.6) with a lot of bug fixes.

    Can you please identify which release it was fixed (i.e. R 8.4 or R 8.5) so we can isolate the fix?

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Prodigy 90 points

    8.4, using ol_r8.a9.14 according to release notes:

    $ ./gentree.py --git-revision ol_r8.a9.14 ~/st/wl18xx/ ../ol_r8.a9.14
    Get original source files from git ...
    Apply patches ...
    Failed to apply changes from backport-adjustments/flow_dissector.patch
    > patching file compat/net-core-flow_dissector.c
    > Hunk #1 FAILED at 177.
    > 1 out of 1 hunk FAILED -- saving rejects to file compat/net-core-flow_dissector.c.rej
    Failed to apply changes from collateral-evolutions/network/83-select_queue/mac80211.patch
    > patching file net/mac80211/iface.c
    > Hunk #1 FAILED at 1067.
    > Hunk #2 FAILED at 1086.
    > 2 out of 2 hunks FAILED -- saving rejects to file net/mac80211/iface.c.rej
    Failed to apply changes from collateral-evolutions/network/83-select_queue/mwifiex.patch
    > patching file drivers/net/wireless/mwifiex/main.c
    > Hunk #1 FAILED at 746.
    > 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/mwifiex/main.c.rej
    Failed to apply changes from collateral-evolutions/network/85-hid_ll_driver/net_bluetooth_hidp_core.patch
    > patching file net/bluetooth/hidp/core.c
    > Hunk #1 succeeded at 268 with fuzz 1 (offset 45 lines).
    > Hunk #2 succeeded at 353 with fuzz 2 (offset 45 lines).
    > Hunk #3 FAILED at 396.
    > Hunk #4 succeeded at 474 with fuzz 2 (offset 65 lines).
    > Hunk #5 FAILED at 739.
    > 2 out of 5 hunks FAILED -- saving rejects to file net/bluetooth/hidp/core.c.rej
    Failed to apply changes from collateral-evolutions/network/86-qdisc_tx_busylock/ieee802154.patch
    > patching file net/ieee802154/6lowpan.c
    > Hunk #1 FAILED at 530.
    > Hunk #2 FAILED at 545.
    > 2 out of 2 hunks FAILED -- saving rejects to file net/ieee802154/6lowpan.c.rej
    Modify Kconfig tree ...
    Rewrite Makefiles and Kconfig files ...
    Done!

    Still, it does build against a 3.12 kernel based on TI's tree. However:

    ~# modprobe wlcore-sdio
    [   17.158080] wlcore_sdio: Unknown symbol wl12xx_get_platform_data (err 0)

    Relevant (I think) config for the backports:

    # CPTCFG_WL1251 is not set
    # CPTCFG_WL12XX is not set
    CPTCFG_WL18XX=m
    CPTCFG_WLCORE=m
    # CPTCFG_WLCORE_SPI is not set
    CPTCFG_WLCORE_SDIO=m
    CPTCFG_UNIFIED_WILINK_PLATFORM_DATA=y

    I'll try the others as well but I had this issue with pretty much every tag I tried from the TI backports fork using the wl18xx kernel tree.

  • 0 in reply to jsb
    TI__Guru* 85400 points
    Hi,

    Are you not using the device tree mechanism?
    I think you can take the definition from the previous release (it should be defined in: drivers/net/wireless/ti/wilink_platform_data.c).

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Prodigy 90 points

    Ah yes, we are using the dt.  Removing CPTCFG_UNIFIED_WILINK_PLATFORM_DATA=y allowed things to load correctly.  Initial testing looks good, thanks for the help!

  • 0 in reply to jsb
    TI__Guru* 85400 points
    Hi,

    Thanks for the update, I'll mark this as closed.

    Regards,
    Gigi Joseph.