For WF200, WFM200 or WGM160P, the firmware uses by default the Relative CCA mode which automatically set the CCA level.
This default mode is not recommended to pass the CE RF certification and for this certification the Absolute CCA mode shall be selected.
If you are using the Full-MAC API this could be set with SL_WFX_CCA_THR_MODE_ABSOLUTE using this https://docs.silabs.com/wifi/wf200/rtos/latest/group-g-e-n-e-r-a-l-d-r-i-v-e-r-a-p-i#ga033dca6edbef96e4042d500a10dff9d8
if you are using Lower MAC and Linux driver wfx then you could modify the CCA mode sending a specific frame after the firmware download like this (within a root session only):
# Absolute CCA mode : echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x01\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg
In order to revert CCA mode in default mode Relative, you could do this below or to reload the firmware:
# Relative CCA mode : echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x00\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg
Note in the above path, the * in "phy*" could be replaced by an index depending of your target.
This is also indicated in the UG395 in section 8.3 but it could be useful for WF200 or WGM160P.
Off course, the 2.4GHz coexistence is a sharing and so the throughput and/or packet delay could be impacted for both or for one device. It will be difficult to target high throughput and short delay with two or more devices sharing the 2.4 GHz. If you target moderate Wi-Fi throughput like 5 or 10 Mbps then the sharing should be easy. If you target low Wi-Fi throughput then may be the PTA is not always useful but the interface could be connected for future usage in case of need.
We recommend to add Test Points on used PTA signals to debug and check the configuration on both devices is Ok.
Note with EFR32 using BLE or Zigbee, only the 3 wires PTA interface is currently available but the 4 wires could be connected for future usage. You could refer to these Application Notes below :
WF(200) can be used with Linux in WPA3 in both AP (Access Point) and STA (STAtion) modes using Linux standard commands.
This article provides generic (i.e. not specific to WF(M)200) information on the Linux configuration of a WPA3 AP as well as a WPA3 STA. You can set up 2 boards and connect them together over WPA3 Wi-Fi.
In most cases, WF(M)200 will act either as AP or STA, not with both roles simultaneously. For commissioning purposes, it is possible to enable simultaneous AP+STA. Details on this feature are not provided in this article.
The AP wlan interface is selectable in the hostapd command line, as the '-i' (list of interface names to use) field. It can also be hard-coded in the hostapd_WPA3.conf file.
Typical hostapd command line (in the context of our Raspberry Pi demo, user 'pi' (requiring 'sudo'))
sudo killall hostapd
sudo hostapd -i wlan0 hostapd_WPA3.conf
Configuration file: hostapd_WPA3.conf
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Using interface wlan0 with hwaddr 00:0d:6f:73:91:57 and ssid "WPA3_AP"
wlan0: interface state COUNTRY_UPDATE->ENABLED
wlan0: AP-ENABLED
We recommend not running hostapd in the background when experimenting, to get an immediate display of any message from the application. Run in the background once you have validated your setup (use '-B' for running in background).
hostapd v2.8-devel
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2019, Jouni Malinen <j@w1.fi> and contributors
Checking if hostapd is running, and what the interface and configuration file are
We recommend not running wpa_supplicant in the background when experimenting, to get an immediate display of any message from the application. Run in the background once you have validated your setup (use '-B' for running in background).
wlan0: SME: Trying to authenticate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: SME: Trying to authenticate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: PMKSA-CACHE-ADDED 00:0d:6f:73:91:57 0
wlan0: Trying to associate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: Associated with 00:0d:6f:73:91:57
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan0: WPA: Key negotiation completed with 00:0d:6f:73:91:57 [PTK=CCMP GTK=CCMP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:0d:6f:73:91:57 completed [id=0 id_str=]
STA: Checking wlan0 IP address
ip addr show wlan0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0d:6f:73:8a:15 brd ff:ff:ff:ff:ff:ff
inet 192.168.45.109/24 brd 192.168.45.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
inet6 fe80::108f:61b8:531f:3a20/64 scope link
valid_lft forever preferred_lft forever
Check that the IP address is within the range allocated via dnsmasq on the AP
WPA3 configuration fields table
The table below lists side-by-side parameters present in hostapd.conf and wpa_supplicant for a setup where a Linux platform is configured as AP while another Linux platform is configured as a STA associated with the AP.
These parameters correspond to the attached configuration files:
hostapd_WPA3_wlan0.conf
wpa_supplicant_WPA3.conf
Legend
User-modifiable fields
WPA3-forced fields
hostapd/wpa_supplicant configuration fields
hostapd_WPA3.conf
wpa_supplicant_WPA3.conf
comments
interface=wlan0
optional in hostapd config. Can be set via command line '-i' field
# The wpa field is a bit field that can be used to enable WPA/WPA2
# bit0 = WPA (IEEE 802.11i/D3.0)
# bit1 = WPA2 (IEEE 802.11i/RSN) (dot11RSNAEnabled)
# We don't use WPA: bit0 = 0
# WPA2 and WPA3 use RSN: bit1 = 1
# this leads to wpa=2 / proto=RSN
wpa_key_mgmt=SAE
key_mgmt=SAE
SAE = 'Simultaneous Authentication of Equals' for WPA3-Personal
rsn_pairwise=CCMP
pairwise=CCMP
# 2 'pairwise' fields are used for WPA or RSN: wpa_pairwise and rsn_pairwise
# we only use RSN, so only set rsn_pairwise
# the value is a space-separated list of accepted encryption algorithms
# CCMP = AES in Counter mode with CBC-MAC (CCMP-128)
With a CISCO AP AIR-AP1852E-E-K9, firmware 8.10.105.0 configured with WPA3 security and a Raspberry Pi with the SD-card 3.2 with BRD8022/23A with FW3.8.0 and the Driver WFX 2.5.2, you could get this with WPA3 security enabled:
First with a Wi-Fi scan, you should get SAE on the security used by the AP with WPA3:
Then using the wpa_supplicant_WPA3.conf above, we could get the association like below:
pi@rpi-123:~ $ wfx_sta --conf wpa_supplicant_WPA3.conf
Asking dhcpcd to control wlan0
Starting wpa_supplicant
Setting up connection
Waiting for connection Associated
Waiting for DHCP
DHCP lease obtained
Success: wlan0 connected to WPA3_000 with IP X.X.X.X
Then we could get the following status with wpa_cli:
We could check the status indicating key_mgmt=SAE and pmf=1 in bold above because it is associated with an AP using the WPA3 security.
Remarks:
WPA3 security is now mandatory for all Wi-Fi Alliance certified products but it is relatively new and not supported by all Access Point or station already installed or sold in 2020.
Please note WPA3 could be not supported with old wpa_supplicant release. We have tested successfully this with a Linux kernel 4.19.57-v7l+ and the wpa_supplicant release v2.8-devel.
When the host asks the WF200 or WFM200 to limit the Tx power, WF(M)200 adds FRONT_END_LOSS_TX_QDB from the requested value (see UG404 on the PDS file).
Hence:
if FRONT_END_LOSS_TX_QDB is 0, the host controls the power limitation at the output of the RF1 and RF2 pin of WF(M)200
if FRONT_END_LOSS_TX_QDB is set to antenna gain (negative value) and loss on the board or from a FEM (positive value), the host controls the limitation in EIRP
Note that the Linux hosts work with EIRP values. So, if WF(M)200 aims to work with a Linux host, FRONT_END_LOSS_TX_QDB should be set with the antenna gain.
Note also this is only a Tx output limitation and this limitation could be higher than the WF(M)200 Power Amplifier is allowed or able to transmit depending on RF certification constraint and backoff set in the PDS file according to the channel or the PHY rate.
Please find below a short list of things to check when targeting low current consumption when the Wi-Fi power save mode is enabled:
1) The LP_CLK (32.768KHz +/-1000ppm) has to be provided (not useful if you don't care about current consumption).
2) The frequency drift of LP_CLK within 1 second should be lower than +/-100ppm.
3) The WUP signal should be connected between the host and the WF(M)200.
4) The WUP and WIRQ management should be carefully done to optimize the current consumption (see the source code of WFX driver examples provided on Github).
When the host CPU is not sending frame to WF200 then the WUP pin should be low in order the WF200 stops the SPI or SDIO interface power consumption during the associated sleep time period (see AN1219 appendix B).
The SPI or SDIO clock should be stopped when the WUP pin is low.
5) The SPI or SDIO clock should be the highest (respectively 42MHz and 50MHz) to reduce data and management transfer time between the host and the WF(M)200.
6) The resistor pull-up on SDIO interface could increase the current consumption (should be in the host according to the SDIO standard).
7) The WF(M)200 GPIOs usage like FEM or PTA will add additional current consumption on WF(M)200.
8) All pull-up/pull-down resistors on used WF(M)200 GPIOs could impact greatly the average current consumption.
9) Power limitation in Tx or backoff usage could reduce the current consumption in TX (but this also reduces the coverage).
10) VDD_RF, VDD_D, VDD_IO could use 1.8V to reduce power consumption (or 3.3V) but VDD_PA uses only 3.3V nominal (see WF200 or WFM200 datasheet operating conditions).
VDD_IO could be only set to 1.8V If the SPI or SDIO host interface support 1.8V (check also this for other signals like WUP/WIRQ...).
Off course these previous items are some basics and the customer should take care to the host consumption and data traffic usage.
To reduce power consumption, it is recommended to use short high bit rate time slot for transmission or reception and then to be without data traffic during as long time duration as possible.
This points to an existing limitation/issue in the AllWinner SDIO HW/Driver combination related to SDIO IRQ masking.
This leads to 2 consecutive read of CONTROL, followed by 2 consecutive read of QUEUE.
As this (2 consecutive QUEUE read) is not expected by the FW, SDIO data (i.e. CRC) is incorrect, and the communication is stopped.
There are 2 possible error messages, depending on the first CRC location:
If the QUEUE length is short (below 24x bytes), there is only 1 CRC: the final one. The message is then related to a 'sunxi data error'.
If the QUEUE length is long (more than 24x bytes), there are intermediate CRCs. The message is then related to a 'wfx-sdio read error'
At the time of writing, no correction to the AllWinner 'sunxi-mmc' driver has been implemented, so the solution is to detect the double SDIO IRQs with the wfx driver and drop them.
A 'workaround/patch' has been created for this purpose.
Symptoms
The following error messages should make you consider applying the workaround patch if using SDIO with an AllWinner SoC:
sunxi-mmc 1c12000.mmc: data error, sending stop command
wfx-sdio mmc1:0001:1: wfx_data_read: bus communication error: -110
Workaround Patch
This patch suppresses consecutive reads of CONTROL and QUEUE. It can be applied on driver 2.4.
From 61e1e589ce720235ddd0e2d569c5d81fe155ed1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pouiller?= <jerome.pouiller@silabs.com>
Date: Wed, 22 Apr 2020 10:10:30 +0200
Subject: [PATCH] bh: try to detect duplicated IRQs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bitThe allwinner architecture seems to have some race conditions while
masking the IRQs. So, in some case the IRQ is reported twice to the
driver, then the control register is read twice and data is read twice.Until now, the duplicated access to the control register always happens
before the access to the data (note that it does not prove it will be
always the case). Thus, it is easy to detect that pattern and drop the
faulty access.Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
---
bh.c | 5 +++++
hwio.c | 7 +++++++
wfx.h | 2 ++
3 files changed, 14 insertions(+)diff --git a/bh.c b/bh.c
index 55724e4295..dd6b4095d3 100644
--- a/bh.c
+++ b/bh.c
@@ -287,6 +287,10 @@ void wfx_bh_request_rx(struct wfx_dev *wdev)
u32 cur, prev;
control_reg_read(wdev, &cur);
+ if (cur == ~0) {
+ dev_warn(wdev->dev, "drop probably duplicated IRQ\n");
+ return;
+ }
prev = atomic_xchg(&wdev->hif.ctrl_reg, cur);
complete(&wdev->hif.ctrl_ready);
queue_work(system_highpri_wq, &wdev->hif.bh);
@@ -324,6 +328,7 @@ void wfx_bh_poll_irq(struct wfx_dev *wdev)
start = ktime_get();
for (;;) {
control_reg_read(wdev, ®);
+ wdev->last_read_reg_is_ctrl = false;
now = ktime_get();
if (reg & 0xFFF)
break;
diff --git a/hwio.c b/hwio.c
index 777217cdf9..ee2fbc112d 100644
--- a/hwio.c
+++ b/hwio.c
@@ -34,6 +34,11 @@ static int read32(struct wfx_dev *wdev, int reg, u32 *val)
*val = ~0; // Never return undefined value
if (!tmp)
return -ENOMEM;
+ if (reg == WFX_REG_CONTROL && wdev->last_read_reg_is_ctrl) {
+ kfree(tmp);
+ return 0;
+ }
+ wdev->last_read_reg_is_ctrl = !!(reg == WFX_REG_CONTROL);
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv, reg, tmp,
sizeof(u32));
if (ret >= 0)
@@ -149,6 +154,7 @@ static int indirect_read(struct wfx_dev *wdev, int reg, u32 addr,
goto err;
}
+ wdev->last_read_reg_is_ctrl = false;
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv, reg, buf, len);
err:
@@ -235,6 +241,7 @@ int wfx_data_read(struct wfx_dev *wdev, void *buf, size_t len)
WARN((long)buf & 3, "%s: unaligned buffer", __func__);
wdev->hwbus_ops->lock(wdev->hwbus_priv);
+ wdev->last_read_reg_is_ctrl = false;
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv,
WFX_REG_IN_OUT_QUEUE, buf, len);
_trace_io_read(WFX_REG_IN_OUT_QUEUE, buf, len);
diff --git a/wfx.h b/wfx.h
index 3ea3a41216..dbb4870ecc 100644
--- a/wfx.h
+++ b/wfx.h
@@ -101,6 +101,8 @@ struct wfx_dev {
struct hif_rx_stats rx_stats;
struct mutex rx_stats_lock;
+
+ bool last_read_reg_is_ctrl;
};
struct wfx_vif {
--
2.26.1
Please note that Zentri legacy WiFi modules (AMW007/AMW037/AMW006/AMW036/AMW106/AMW136) are pre-certified for IC, FCC, CE, and others. To obtain a copy of the certification report for various modules, please see: https://docs.zentri.com/zentri/docresources
For those interested in redoing the certification test, or interested in a certain RF test, we also provide a tool suite that we use for the full certification of our modules. However it involves reprogramming the modules with dedicated test firmware (please note that when using with AMW007/AMW037/AMW036/AMW006, it is not possible to put the original software back onto the modules).
There is a PDF in the docs directory that will guide you through the various test options.
The software runs on a standard windows 10 machine.
The setup requires an ATG002 (Piranha) board. If not available, you will need to purchase one from your local distributor. Ultimately, you will need to connect the ATG002 to your board. Look at the evaluation board schematics for the required connections. Once that is done, launch the "wl_gui.exe" tool, select the module type and firmware type ("RF") and click program. This will load the dedicated certification test firmware into the module.
After that, the rest of the options are fairly intuitive. We have used this tool with multiple different test houses.
Gecko OS Studio access a few different public domains to perform tasks such as logging in, downloading the SDK and interfacing to DMS. Often, corporate firewalls can block access to these domains. Below is a list of sites that Gecko OS Studio touches. All services use HTTPS on the standard port 443. Typically, issues related to this are solved with the help of the corporate IT department by whitelisting these URLs for the Gecko OS Studio application.
On Linux platforms, devices are physically connected to buses and the device tree needs to reflect this for device to be detected.
It is important to debug device tree issues at startup. To achieve this, a very convenient tool is dtc (aka 'device tree compiler').
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!
Installing dtc
Installing dtc on the target machine is convenient, but may not be allowed on the target. We describe below an alternative solution, where dtc is installed on another machine.
apt-get install device-tree-compiler
Retrieving the current device tree rather than looking at the sources
The point with device tree is that looking at the sources (.dts/.dtsi) files you don't really have the view the host has on the final device tree.
To cope with this, we recommend looking at the 'device tree seen by the host', directly from the file system at /sys/firmware/devicetree/base/
This reflects the device tree content after editing/compiling/booting
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. With the '--sort' option, comparing device trees is much easier.
Retrieving the device tree without dtc support on your platform
On your platform
Create an archive from your file system's device tree
tar zcf device_tree.tar.gz /sys/firmware/devicetree/base/
Copy this file to a platform supporting dtc
On a platform supporting dtc
decompress the archive
retrieve the device tree using dtc from the new directory (note how the path starts with 'sys' instead of '/sys' here, since the entire content has been extracted locally)
NB: Checking the device tree from the file system rather than from the .dtb file is safer, since it removes the risk of using the wrong file. The file system content is 'what the kernel sees'.
Debugging device tree issues by comparison
Once you have 2 different files before/after adding your device tree you can easily diff them and spot all differences brought in by your .dts/.dtsi source files.
In case of potential device tree issues, make sure all the changes you expect are visible, otherwise you may be facing issues in your .dts/.dtsi source files.
Checking device tree at runtime
$ sudo vcdbg log msg
will allow you to check which device tree file is loaded at boot.
Adding
dtdebug=1
to /boot/config.txt will add more details on the next boot.
Wi-Fi Knowledge Base
WF(M)200 : Relative and Absolute CCA Modes for RF certifications
For WF200, WFM200 or WGM160P, the firmware uses by default the Relative CCA mode which automatically set the CCA level.
This default mode is not recommended to pass the CE RF certification and for this certification the Absolute CCA mode shall be selected.
If you are using the Full-MAC API this could be set with SL_WFX_CCA_THR_MODE_ABSOLUTE using this https://docs.silabs.com/wifi/wf200/rtos/latest/group-g-e-n-e-r-a-l-d-r-i-v-e-r-a-p-i#ga033dca6edbef96e4042d500a10dff9d8
if you are using Lower MAC and Linux driver wfx then you could modify the CCA mode sending a specific frame after the firmware download like this (within a root session only):
# Absolute CCA mode :
echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x01\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg
In order to revert CCA mode in default mode Relative, you could do this below or to reload the firmware:
# Relative CCA mode :
echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x00\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg
Note in the above path, the * in "phy*" could be replaced by an index depending of your target.
This is also indicated in the UG395 in section 8.3 but it could be useful for WF200 or WGM160P.
WF(M)200 RF Coexistence and PTA usage with another 2.4GHz device
This short KBA provides some key links related to RF coexistence recommendations with WF200, WFM200 and WGM160P.
WF(M)200 implements a PTA arbiter which allows to improve the RF coexistence with another 2.4GHz device. This is very useful when the product is small with co-located antenna. The following link provides an application note on this topic: https://docs.silabs.com/wifi/wf200/content-source/application-note/wifi-coexistence
Even when implementing managed coexistence with PTA mechanism, you should take care to unmanaged coexistence principles : https://docs.silabs.com/wifi/wf200/content-source/application-note/wifi-coexistence#unmanaged-coexistence
Off course, the 2.4GHz coexistence is a sharing and so the throughput and/or packet delay could be impacted for both or for one device. It will be difficult to target high throughput and short delay with two or more devices sharing the 2.4 GHz. If you target moderate Wi-Fi throughput like 5 or 10 Mbps then the sharing should be easy. If you target low Wi-Fi throughput then may be the PTA is not always useful but the interface could be connected for future usage in case of need.
We recommend to add Test Points on used PTA signals to debug and check the configuration on both devices is Ok.
Note with EFR32 using BLE or Zigbee, only the 3 wires PTA interface is currently available but the 4 wires could be connected for future usage. You could refer to these Application Notes below :
A general learning-center Wi-Fi coexistence page:
WF(M)200 : Linux WPA3 configuration
Linux: Configuring WF(M)200 for WPA3
WF(200) can be used with Linux in WPA3 in both AP (Access Point) and STA (STAtion) modes using Linux standard commands.
This article provides generic (i.e. not specific to WF(M)200) information on the Linux configuration of a WPA3 AP as well as a WPA3 STA. You can set up 2 boards and connect them together over WPA3 Wi-Fi.
Pre-requisites
WPA3 is working as from
Please update to the above minimal versions before using WPA3 with WF(M)200.
AP (Access Point)
The AP uses hostapd, configured via the hostapd_WPA3_wlan0.conf file.
AP: Allocating an IP address to wlan0
sudo dhcpcd --release wlan0 sudo ip addr flush dev wlan0 sudo ip addr add 192.168.45.1/24 dev wlan0AP: Checking wlan0 IP address
ip addr show wlan0AP: DHCP/DNS setup using dnsmasq: allocating an IP address range to wlan0 clients
sudo killall dnsmasq sudo dnsmasq --conf-file=/dev/null --interface=wlan0 --bind-interfaces --except-interface=lo --dhcp-range=192.168.45.100,192.168.45.200AP interface selection
The AP wlan interface is selectable in the hostapd command line, as the '-i' (list of interface names to use) field. It can also be hard-coded in the hostapd_WPA3.conf file.
Typical hostapd command line (in the context of our Raspberry Pi demo, user 'pi' (requiring 'sudo'))
sudo killall hostapdsudo hostapd -i wlan0 hostapd_WPA3.confAP configuration
Refer to the attached hostapd_WPA3.conf file. Refer to https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf for details of hostapd configuration.
AP Checks (on the AP)
Checking hostapd version (tested with v2.8-devel)
hostapd -vChecking if hostapd is running, and what the interface and configuration file are
ps -few | grep hostapdChecking active lines in hostapd configuration (skipping empty lines and comment lines)
cat hostapd_wpa3.conf | grep -v ^$ | grep -v ^#Checking hostapd status
hostapd_cli statusChecking hostapd configuration
hostapd_cli get_configExternal AP checks (from a Linux Wi-Fi STAtion)
wpa_cli scanwpa_cli scan_resultsAP hostapd messages during STA association
STA (STAtion)
The STA uses wpa_supplicant, configured via the wpa_supplicant_WPA3.conf file.
STA interface selection
The STA wlan interface is selected in the wpa_supplicant command line, as the '-i' (= interface name) field
Typical wpa_supplicant command line (in the context of our Raspberry Pi demo, user 'pi')
sudo killall wpa_supplicant sudo wpa_supplicant -i wlan0 -c wpa_supplicant_WPA3.confSTA configuration
Refer to the attached wpa_supplicant_WPA3.conf file. Refer to https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf for details of wpa_supplicant configuration.
STA Checks (on the STA)
Checking wpa_supplicant version (tested with 2.8-devel)
wpa_supplicant -vChecking if wpa_supplicant is running, and what the interface and configuration file are
ps -few | grep wpa_supplicantChecking active lines in wpa_supplicant configuration (skipping empty lines and comment lines)
cat wpa_supplicant_WPA3.conf | grep -v ^$ | grep -v ^#Checking wpa_supplicant status
wpa_cli statusSTA wpa_supplicant messages upon connection
STA: Checking wlan0 IP address
ip addr show wlan0WPA3 configuration fields table
The table below lists side-by-side parameters present in hostapd.conf and wpa_supplicant for a setup where a Linux platform is configured as AP while another Linux platform is configured as a STA associated with the AP.
These parameters correspond to the attached configuration files:
Legend
# bit0 = WPA (IEEE 802.11i/D3.0)
# bit1 = WPA2 (IEEE 802.11i/RSN) (dot11RSNAEnabled)
# We don't use WPA: bit0 = 0
# WPA2 and WPA3 use RSN: bit1 = 1
# this leads to wpa=2 / proto=RSN
# we only use RSN, so only set rsn_pairwise
# the value is a space-separated list of accepted encryption algorithms
# CCMP = AES in Counter mode with CBC-MAC (CCMP-128)
# PMF required: ieee80211w=2
# WPA3-Personal-only mode: ieee80211w=2 / key_mgmt=SAE
# wpa_passphrase is an ASCII passphrase, converted to PSK (Pre-Shared Key)
Double quotes required in wpa_supplicant.conf
WF(M)200 : Linux wpa_supplicant.conf to be associated with a Wi-Fi Access Point in WPA3
In order to use the WPA3 with the WF(M)200 through Linux, you could use the following wpa_supplicant.conf:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="WPA3_000"
psk="xxxxxxxxxxxxx"
key_mgmt= SAE
proto=RSN
pairwise=CCMP
group=CCMP
ieee80211w=2
}
Note ieee80211w could be set to 1 or 2. See the definition of the parameters in the https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf
With a CISCO AP AIR-AP1852E-E-K9, firmware 8.10.105.0 configured with WPA3 security and a Raspberry Pi with the SD-card 3.2 with BRD8022/23A with FW3.8.0 and the Driver WFX 2.5.2, you could get this with WPA3 security enabled:
First with a Wi-Fi scan, you should get SAE on the security used by the AP with WPA3:
pi@rpi-123:~ $ wfx_sta --scan
Starting wpa_supplicant
Scanning access points...
bssid / frequency / signal level / flags / ssid
x:x:x:x:x:x 2462 -43 [WPA2-PSK+SAE-CCMP][ESS] WPA3_000
...
Then using the wpa_supplicant_WPA3.conf above, we could get the association like below:
pi@rpi-123:~ $ wfx_sta --conf wpa_supplicant_WPA3.conf
Asking dhcpcd to control wlan0
Starting wpa_supplicant
Setting up connection
Waiting for connection
Associated
Waiting for DHCP
DHCP lease obtained
Success: wlan0 connected to WPA3_000 with IP X.X.X.X
Then we could get the following status with wpa_cli:
pi@rpi-123:~ $ wpa_cli status
Selected interface 'wlan0'
bssid=xx:xx:xx:xx:xx:xx
freq=2462
ssid=WPA3_000
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=SAE
pmf=1
mgmt_group_cipher=BIP
sae_group=19
wpa_state=COMPLETED
ip_address=X.X.X.X
We could check the status indicating key_mgmt=SAE and pmf=1 in bold above because it is associated with an AP using the WPA3 security.
Remarks:
WF(M)200 : Explanations how the Wi-Fi power limitation from the Host is applied
When the host asks the WF200 or WFM200 to limit the Tx power, WF(M)200 adds FRONT_END_LOSS_TX_QDB from the requested value (see UG404 on the PDS file).
Hence:
if FRONT_END_LOSS_TX_QDB is 0, the host controls the power limitation at the output of the RF1 and RF2 pin of WF(M)200
if FRONT_END_LOSS_TX_QDB is set to antenna gain (negative value) and loss on the board or from a FEM (positive value), the host controls the limitation in EIRP
Note that the Linux hosts work with EIRP values. So, if WF(M)200 aims to work with a Linux host, FRONT_END_LOSS_TX_QDB should be set with the antenna gain.
Note also this is only a Tx output limitation and this limitation could be higher than the WF(M)200 Power Amplifier is allowed or able to transmit depending on RF certification constraint and backoff set in the PDS file according to the channel or the PHY rate.
WF200, WFM200 current consumption : list of things to take care
Please find below a short list of things to check when targeting low current consumption when the Wi-Fi power save mode is enabled:
1) The LP_CLK (32.768KHz +/-1000ppm) has to be provided (not useful if you don't care about current consumption).
2) The frequency drift of LP_CLK within 1 second should be lower than +/-100ppm.
3) The WUP signal should be connected between the host and the WF(M)200.
4) The WUP and WIRQ management should be carefully done to optimize the current consumption (see the source code of WFX driver examples provided on Github).
5) The SPI or SDIO clock should be the highest (respectively 42MHz and 50MHz) to reduce data and management transfer time between the host and the WF(M)200.
6) The resistor pull-up on SDIO interface could increase the current consumption (should be in the host according to the SDIO standard).
7) The WF(M)200 GPIOs usage like FEM or PTA will add additional current consumption on WF(M)200.
8) All pull-up/pull-down resistors on used WF(M)200 GPIOs could impact greatly the average current consumption.
9) Power limitation in Tx or backoff usage could reduce the current consumption in TX (but this also reduces the coverage).
10) VDD_RF, VDD_D, VDD_IO could use 1.8V to reduce power consumption (or 3.3V) but VDD_PA uses only 3.3V nominal (see WF200 or WFM200 datasheet operating conditions).
VDD_IO could be only set to 1.8V If the SPI or SDIO host interface support 1.8V (check also this for other signals like WUP/WIRQ...).
Off course these previous items are some basics and the customer should take care to the host consumption and data traffic usage.
To reduce power consumption, it is recommended to use short high bit rate time slot for transmission or reception and then to be without data traffic during as long time duration as possible.
The AN1219 provides some additional details about this (see https://www.silabs.com/documents/public/application-notes/an1219-power-consumption-wfm200.pdf).
See also https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/03/05/kba_wfx200_dtim3-tmpo and https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/03/19/kba_how_to_do_curr-U9le
KBA: WF200/WFM200 Linux Driver with AllWinner SoC (SDIO)
WF200/WFM200 Linux Driver with AllWinner SoC (SDIO)
The information in this article is specific to using the wfx driver in SDIO with AllWinner SoCs on Linux.
The allwinner architecture seems to have some race conditions while masking the SDIO IRQs.
In some case the IRQ is reported twice to the wfx driver, then the control register is read twice and data is read twice.
This subject is discussed in this Linux Kernel discussion Thread
This points to an existing limitation/issue in the AllWinner SDIO HW/Driver combination related to SDIO IRQ masking.
This leads to 2 consecutive read of CONTROL, followed by 2 consecutive read of QUEUE.
As this (2 consecutive QUEUE read) is not expected by the FW, SDIO data (i.e. CRC) is incorrect, and the communication is stopped.
There are 2 possible error messages, depending on the first CRC location:
At the time of writing, no correction to the AllWinner 'sunxi-mmc' driver has been implemented, so the solution is to detect the double SDIO IRQs with the wfx driver and drop them.
A 'workaround/patch' has been created for this purpose.
Symptoms
The following error messages should make you consider applying the workaround patch if using SDIO with an AllWinner SoC:
sunxi-mmc 1c12000.mmc: data error, sending stop command
wfx-sdio mmc1:0001:1: wfx_data_read: bus communication error: -110
Workaround Patch
This patch suppresses consecutive reads of CONTROL and QUEUE. It can be applied on driver 2.4.
Zentri Classic/Legacy Module Setup for Certification Testing
Please note that Zentri legacy WiFi modules (AMW007/AMW037/AMW006/AMW036/AMW106/AMW136) are pre-certified for IC, FCC, CE, and others. To obtain a copy of the certification report for various modules, please see: https://docs.zentri.com/zentri/docresources
For those interested in redoing the certification test, or interested in a certain RF test, we also provide a tool suite that we use for the full certification of our modules. However it involves reprogramming the modules with dedicated test firmware (please note that when using with AMW007/AMW037/AMW036/AMW006, it is not possible to put the original software back onto the modules).
You can download the certification test package from: https://resources.zentri.com/documentation/certs/ZentriClassicCertificationTesting.zip
There is a PDF in the docs directory that will guide you through the various test options.
The software runs on a standard windows 10 machine.
The setup requires an ATG002 (Piranha) board. If not available, you will need to purchase one from your local distributor. Ultimately, you will need to connect the ATG002 to your board. Look at the evaluation board schematics for the required connections. Once that is done, launch the "wl_gui.exe" tool, select the module type and firmware type ("RF") and click program. This will load the dedicated certification test firmware into the module.
After that, the rest of the options are fairly intuitive. We have used this tool with multiple different test houses.
Running Gecko OS Studio on a corporate network
Gecko OS Studio access a few different public domains to perform tasks such as logging in, downloading the SDK and interfacing to DMS. Often, corporate firewalls can block access to these domains. Below is a list of sites that Gecko OS Studio touches. All services use HTTPS on the standard port 443. Typically, issues related to this are solved with the help of the corporate IT department by whitelisting these URLs for the Gecko OS Studio application.
KBA: Linux Device Tree Debugging
Device tree debugging
On Linux platforms, devices are physically connected to buses and the device tree needs to reflect this for device to be detected.
It is important to debug device tree issues at startup. To achieve this, a very convenient tool is dtc (aka 'device tree compiler').
Installing dtc
apt-get install device-tree-compilerRetrieving the current device tree rather than looking at the sources
The point with device tree is that looking at the sources (.dts/.dtsi) files you don't really have the view the host has on the final device tree.
To cope with this, we recommend looking at the 'device tree seen by the host', directly from the file system at /sys/firmware/devicetree/base/
Retrieving the device tree using dtc
Retrieving the device tree without dtc support on your platform
Retrieving the device tree from the .dtb (device tree blob) file
As a last resort, get the .dtb file used at boot and decompile it using dtc on a platform supporting it.
Debugging device tree issues by comparison
Once you have 2 different files before/after adding your device tree you can easily diff them and spot all differences brought in by your .dts/.dtsi source files.
In case of potential device tree issues, make sure all the changes you expect are visible, otherwise you may be facing issues in your .dts/.dtsi source files.
Checking device tree at runtime
will allow you to check which device tree file is loaded at boot.
Adding
dtdebug=1
to /boot/config.txt will add more details on the next boot.