The Platform Data Set (PDS) file is used by the customer to fine tune the WF(M)200 usage according to his design or/and application.

When the TEST_FEATURE_CFG field is in the PDS file then it allows to do RF tests with the WFx200 (without WLAN protocol).

The test feature is available only if the power save mode is disabled. To disable the power save mode with Linux : sudo iw dev wlan0 set power_save off

We provide python scripts allowing to automate RF measurements, based on the above capability to send PDS data to the lower MAC FW

1. The tester can be a separate machine, connected via SSH, UART or Telnet
2. On the DUT, a small wfx_test_agent allows sending PDS data and retrieving Rx results
   1. Please refer to https://github.com/SiliconLabs/wfx-common-tools/blob/master/test-feature/README.md for details
3. The wfx_test_agent for Linux is provided for a Raspbian configuration
4. The wfx_test_agent for RTOS applications can be provided upon request

You can get more details on PDS and test_feature in the below links:

• https://github.com/SiliconLabs/wfx-pds
• https://github.com/SiliconLabs/wfx-common-tools/tree/master/test-feature

The Platform Data Set (PDS) file is used by the customer to fine tune the WF(M)200 usage according to his design or/and application.

When the TEST_FEATURE_CFG field is in the PDS file then it allows to do RF tests with the WFx200 (without WLAN protocol).

The test feature is available only if the power save mode is disabled. To disable the power save mode with Linux : sudo iw dev wlan0 set power_save off

We provide python scripts allowing to automate RF measurements, based on the above capability to send PDS data to the lower MAC FW

1. The tester can be a separate machine, connected via SSH, UART or Telnet
2. On the DUT, a small wfx_test_agent allows sending PDS data and retrieving Rx results
   1. Please refer to https://github.com/SiliconLabs/wfx-common-tools/blob/master/test-feature/README.md for details
3. The wfx_test_agent for Linux is provided for a Raspbian  configuration is provided
4. The wfx_test_agent fro RTOS applications can be provided upon request

You can get more details on PDS and test_feature in the below links:

• https://github.com/SiliconLabs/wfx-pds
• https://github.com/SiliconLabs/wfx-common-tools/tree/master/test-feature

Linux SDIO part detection on the SDIO bus

Under Linux, SDIO parts are bound to the Linux mmc bus.

Before using a Wi-Fi part connected to the SDIO bus of a Linux system, it is necessary that the system detects the HW on the bus. Linux systems will try to detect SDIO parts on the bus at boot, and every time the mmc bus is bound. The latter is what we will use to trace mmc messages related to SDIO detection.

SDIO Detection message

The following message should be visible in dmesg once boot is complete:

mmcX new high speed SDIO card at address 0001

one-line check:

$ dmesg | grep 'new high speed SDIO'

Until this message is present in dmesg, it is useless to try to load the driver

If this message is not found, it is necessary to debug SDIO detection, going through the following steps:

1. Retrieving the current device tree 
2. Checking which mmc bus is used for SDIO
3. Making sure SDIO detection is enabled in the device tree
4. Checking the mmc bus commands during the SDIO detection phase
5. Checking the SDIO detection result

These steps are detailed below.

Keep in mind that any change to the device tree is only taken into account on the next reboot, so changing the device tree means rebooting!

Retrieving the current device tree

$ dtc -I fs -O dts  /sys/firmware/devicetree/base > device_tree.out

NB: The 'dts' format allows the resulting file to be edited in a human-readable format. If edited as if it were a C file you can benefit from code folding to get a better view of the contents.

Making sure SDIO is enabled in Device Tree

In order for the Linux system to try detecting a part on the SDIO bus, it needs to be part of the Device Tree used at boot.

one-line check (SDIO pins selection):

$ grep sdio_pins device_tree.out

Typical result:

                sdio_pins = "/soc/gpio@7e200000/sdio_pins";
                        sdio_pins {

If this returns an empty line, SDIO detection is not even triggered. Refer to your system documentation to know how to add SDIO to the device tree.

Check the SDIO pins allocation in the 'sdio_pins' node to make sure they match your HW 

Checking which mmc bus is used for SDIO

one-line check (SDIO mmc bus selection):

$ grep -E "mmc[0-2]|mmc@" device_tree.out

The result should contain:

mmc1 = "/soc/sdio@7e300000";

or (depending on the kernel, i.e. the device tree version)

mmc = "/soc/mmc@7e300000";

If this returns an empty line, SDIO is not connected to any mmc bus. Refer to your system documentation to know how to add SDIO to the device tree.

Checking the mmc bus commands during the SDIO detection phase

Until all the above checks are ok, it is pointless trying to trace SDIO detection messages, since detection is not even triggered.

This is the trickiest part, since it involves tracking message normally issued at boot, when the system is attempting SDIO detection. 

In reality, these are issued every time the mmc bus is bound to the system, so unbinding/binding the mmc bus will trigger a new detection attempt. We use this to avoid activating the traces at boot time, since this is not easy to do.

Preparing the kernel event traces (to be executed with root privileges):
Activating mmc request traces:

# echo 1 > /sys/kernel/debug/tracing/events/mmc/mmc_request_done/enable

Not tracing mmc CMD53 (once working in high-speed mode, to avoid being overloaded with traces once detected):

# echo 'cmd_opcode != 53' > /sys/kernel/debug/tracing/events/mmc/mmc_request_done/filter

Tracing the kernel events on mmc1 (adapt the mmc to your own use case):

# cat /sys/kernel/debug/tracing/trace_pipe | grep mmc1 &

echo 3f300000.mmc > /sys/bus/platform/drivers/mmc-bcm2835/unbind 2>/dev/null
sleep 2
echo 3f300000.mmc > /sys/bus/platform/drivers/mmc-bcm2835/bind

Typical traces (limited view due zooming on 'cmd_opcode' due to extra long lines):

2835/unbind 2>/dev/null
mmc_request[afec7ba4]: cmd_opcode=52
mmc_request[afec7ba4]: cmd_opcode=52
mmc_request[afec7bbc]: cmd_opcode=52
mmc_request[afec7bbc]: cmd_opcode=52

2835/bind
mmc_request[b9657df4]: cmd_opcode=52
mmc_request[b9657df4]: cmd_opcode=52
mmc_request[b9657e1c]: cmd_opcode=0 
mmc_request[b9657e24]: cmd_opcode=8 
mmc_request[b9657dd4]: cmd_opcode=5 
mmc_request[b9657d6c]: cmd_opcode=5 
mmc_request[b9657d74]: cmd_opcode=3 
mmc_request[b9657d7c]: cmd_opcode=7 
mmc_request[b9657d54]: cmd_opcode=52
. . .(26 times). . .
mmc_request[b9657cf4]: cmd_opcode=52

NB: The attached SDIO_Detection_mmc_request_done_traces.txt file contains the typical traces.

Stopping mmc request traces (once the traces have been retrieved):

This step is necessary to stop tracing, which is otherwise still active. No additional traces are shown because SDIO traffic only uses CMD53 once detection is complete, and CMD53 are filtered out. It is better to stop tracing completely.

# echo 0 > /sys/kernel/debug/tracing/events/mmc/mmc_request_done/enable

Checking the SDIO detection result

$ dmesg | grep mmc

If detection is correct, the 'mmcX new high speed SDIO card at address 0001' message is present in dmesg.

Otherwise, check for errors related to the mmc item corresponding to your part.

SDIO pins used for the detection phase

The SDIO detection as shown above only uses SD_CMD and SD_CLK pins, and is generally performed with a 400kHz SD_CLK. SD_DAT[3:0] are not used yet, so SDIO detection may succeed even though SD_DAT[3:0] are not properly routed.

Max SDIO speed too high

During the last steps of SDIO detection, the SoC sets the SDIO part to 'high-speed' mode on 4 data bits, then configures its own hardware to the maximum selected SDIO speed (controllable in the device tree) only at the very end of the SDIO detection, after a long series of about 26 CMD52 commands.

In case there are issues related to the max clock speed, the last CMD52 commands will return with 'cmd_err=-110' (which means 'TIMEOUT'), and will be followed by a short burst of about 4 CMD55 commands.

Whenever the SDIO detection loop fails, it is repeated with a slower clock speed (400, 300, 200, 100 kHz, respectively), but is still ending with the max clock. If the max clock is too high, all 4 loops will eventually fail, therefore the traces will show 4 repeated patterns of:

CMD52
CMD52
CMD0
CMD8
CMD5
CMD5
CMD7
CMD52
. . .
CMD52 / cmd_err=-110
CMD55 / cmd_err=-110
CMD55 / cmd_err=-110
CMD55 / cmd_err=-110
CMD55 / cmd_err=-110

And dmesg will show:

mmc1: error -110 whilst initialising SDIO card
mmc1: error -110 whilst initialising SDIO card
mmc1: error -110 whilst initialising SDIO card
mmc1: error -110 whilst initialising SDIO card

In this case, check your device tree documentation to check how to reduce the maximum SDIO clock.

Checking GPIO allocation

sudo cat /sys/kernel/debug/gpio

Output:

GPIOs 0-53, platform/3f200000.gpio, pinctrl-bcm2835:
 gpio-12 ( |wakeup ) out lo
 gpio-13 ( |reset ) out hi

GPIOs 100-101, platform/soc:virtgpio, brcmvirt-gpio, can sleep:
 gpio-100 ( |? ) out lo

Check that wakeup and reset are properly allocated

WF200 Drivers and Firmware are available from Github

For Linux applications

Driver: https://github.com/SiliconLabs/wfx-linux-driver

Firmware: https://github.com/SiliconLabs/wfx-firmware

Tools: https://github.com/SiliconLabs/wfx-linux-tools

Files used by WF200 under Linux on Raspberry Pi (Debian)

• Driver

  • /lib/modules/<kernel>/extras/wfx.ko

• Firmware

  • /lib/firmare/wfx_wf200_C0.sec

• Platform Data Set (PDS)

  • /lib/firmware/wf200.pds

• Device Tree overlays

  • /boot/overlays/wfx-sdio.dtbo

  • /boot/overlays/wfx-spi/dtbo

For RTOS Applications

Driver & Firmware: https://github.com/SiliconLabs/wfx-fullMAC-driver

Tools: https://github.com/SiliconLabs/wfx-fullMAC-tools

WF200 Drivers and Firmware are available from Github

For Linux applications

Driver: https://github.com/SiliconLabs/wfx-linux-driver

Firmware: https://github.com/SiliconLabs/wfx-firmware

Tools: https://github.com/SiliconLabs/wfx-linux-tools

Files used by WF200 under Linux on Raspberry Pi (Debian)

• Driver

  • /lib/modules/<kernel>/extras/wfx.ko

• Firmware

  • /lib/firmare/wfx_wf200_C0.sec

• Platform Data Set (PDS)

  • /lib/firmware/wf200.pds

• Device Tree overlays

  • /boot/overlays/wfx-sdio.dtbo

  • /boot/overlays/wfx-spi/dtbo

For RTOS Applications

Driver & Firmware: https://github.com/SiliconLabs/wfx-fullMAC-driver

Tools: https://github.com/SiliconLabs/wfx-fullMAC-tools

WF200 Drivers and Firmware are available from Github

For Linux applications

Driver: https://github.com/SiliconLabs/wfx-linux-driver

Firmware: https://github.com/SiliconLabs/wfx-firmware

Tools: https://github.com/SiliconLabs/wfx-linux-tools

Files used by WF200 under Linux on Raspberry Pi (Debian):

• Driver: /lib/modules/<kernel>/extras/wfx.ko
• Firmware: /lib/firmare/wfx_wf200_C0.sec
• Platform Data Set (PDS): /lib/firmware/wf200.pds
• Device Tree overlays
  • /boot/overlays/wfx-sdio.dtbo
  • /boot/overlays/wfx-spi/dtbo

For RTOS Applications

Driver & Firmware: https://github.com/SiliconLabs/wfx-fullMAC-driver

Tools: https://github.com/SiliconLabs/wfx-fullMAC-tools

Can the WF200 Linux driver (available at https://github.com/SiliconLabs/wfx-linux-driver) be used with Android?

In theory, yes, since the driver is compatible with Linux kernel from 4.4.1 up to 4.19.

Has it been tested? Not yet.

Linux applications use 

• hostapd in AP mode
• wpa_supplicant in STATION mode

Android uses different applications for AP/STATION management, therefore testing would be required to make sure there is no unexpected behavior in an Android application.

Related links

• https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/02/20/kba_wf200_linux_dri-mEf3 indicates which kernel versions are supported by the wfx linux driver.
• https://en.wikipedia.org/wiki/Android_version_history#Code_names lists the kernel versions associated with Android code names.

Can the WF200 Linux driver (available at https://github.com/SiliconLabs/wfx-linux-driver) be used with Android?

In theory, yes, since the driver is compatible with Linux kernel from 4.4.1 up to 4.19.

(see https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/02/20/kba_wf200_linux_dri-mEf3).

Has it been tested? Not yet.

Linux applications use 

• hostapd in AP mode
• wpa_supplicant in STATION mode

Android uses different applications for AP/STATION management, therefore testing would be required to make sure there is no unexpected behavior in an Android application.

Related links

• https://en.wikipedia.org/wiki/Android_version_history#Code_names lists the kernel versions associated with Android code names.

Can the WF200 Linux driver (available at https://github.com/SiliconLabs/wfx-linux-driver) be used with Android?

In theory, yes, since the driver is compatible with Linux kernel from 4.4.1 up to 4.19 (see https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/02/20/kba_wf200_linux_dri-mEf3).

Has it been tested? Not yet.

Linux applications use 

• hostapd in AP mode
• wpa_supplicant in STATION mode

Android uses different applications for AP/STATION management, therefore testing would be required to make sure there is no unexpected behavior in an Android application.

Related links

• https://en.wikipedia.org/wiki/Android_version_history#Code_names lists the kernel versions associated with Android code names.

Can the WF200 Linux driver (available at https://github.com/SiliconLabs/wfx-linux-driver) be used with Android?

In theory, yes, since the driver is compatible with Linux kernel from 4.4.1 up to 4.19.

Has it been tested? Not yet.

Linux applications use 

• hostapd in AP mode
• wpa_supplicant in STATION mode

Android uses different applications for AP/STATION management, therefore testing would be required to make sure there is no unexpected behavior in an Android application.

Related links

• https://en.wikipedia.org/wiki/Android_version_history#Code_names lists the kernel versions associated with Android code names.