This user guide describes how to run Wi-Fi on the ATWILC1000 SD card or the ATWILC3000 Shield
board on the SAMA5D4 Xplained Ultra running with the Linux® kernel 4.9.
Note: All references to the ATWILC module includes all the devices listed below unless otherwise noted:
•ATWILC1000
•ATWILC3000
The source codes are maintained on GitHub. For latest source codes, see GitHub Linux for ATWILC at
https://github.com/linux4wilc.
Figure 1. ATWILC1000 SD Card and ATWILC3000 Shield Board
The build prerequisite for Linux is a host PC with Linux operating system. The hardware prerequisites are
the following:
•Linux
–SAMA5D4 Xplained Ultra
–ATWILC1000 SD Pro card
–ATWILC3000 Shield board
–USB to Serial adapter (for DEBUG port)
•Common
–Micro-USB cable (Micro-A/Micro-B)
To avoid modifying kernel code, mount the resistor R312 with an approximate value of 120k Ohm in the
location shown below on the ATWILC3000 Shield board.
2. Building Linux for SAMA5D4 Xplained Ultra Board
This section describes how to build the root file system and kernel image to use for ATWILC devices
demo.
This user guide describes general information on the AT91Bootstrap and U-Boot information. For more
details on the AT91Bootstrap and U-Boot, see U-Boot of Linux & Open Source related information for
AT91 Smart ARM Microcontrollers.
2.1 Cloning a Kernel Source and Root File System
The demo uses buildroot to get the suitable toolchain, root file system, and Linux kernel.
The buildroot is cloned from linux4wilc github at the following address:
The buildroot is cloned at the following path in the current directory:
\buildroot4wilc
The current buildroot4wilc is copied from buildroot's repository at git://git.buildroot.net/
buildroot, branch 2017_08, modified with WILC config files (configs/sama5_wilc_defconfig),
and other config files that help run WILC examples.
2.2 Loading SAMA5D4 Configuration File
Use the predefined defconfig file to create the required .config configuration file. This defconfig
file is available in configs folder of the buildroot folder buildroot4wilc.
For SAMA5D4, the sama5_wilc_defconfig defconfig file is used.
To build the root file system for SAMA5D4 with Linux kernel 4.9 for the ATWILC board, browse to the
directory where the files are extracted and create the .config file, using the following commands:
$ cd buildroot4wilc
$ make sama5_wilc_defconfig
2.3 Buildroot File System and Linux Kernel
Start the build operation using $ make command from the buildroot directory.
This $ make command displays the build status on the terminal.
Note: Ensure that the host PC is connected to the internet before starting the build operation and do not
use any build options.
The rootfs.ubi file is generated in the buildroot/output/images directory when the build
operation is complete. The default build will include the WILC modules in the rootfs.ubi.
The driver source files are located at: https://github.com/linux4wilc/linux-at91/tree/master/drivers/staging/wilc1000 in the linux-at91 kernel.
Note: The driver directory name is wilc1000 for legacy reasons only. The driver supports both
ATWILC1000 and ATWILC3000.
Buildroot downloads the Linux kernel as per the buildroot configuration file from GitHub. The downloaded
kernel must be available in the buildroot4wilc/output/build/linux-xxxx path, and is built
automatically during the buildroot build operation.
However, if the kernel is modified after building the buildroot, the user must rebuild the kernel. The
following is the procedure to build the Linux kernel against the toolchain and ARM architecture:
1.Change the directory to the Linux kernel source folder, using the following command:
$ cd output/build/linux-xx
2.Create the kernel with the help of sama5_defconfig defconfig file, using the following command:
$ make ARCH=arm sama5_defconfig
3.Perform the required changes using the menuconfig tool, using the following command:
$ make ARCH=arm menuconfig
4.Build the Linux kernel against the toolchain and ARM architecture, using the following commands:
$ make ARCH=arm CROSS_COMPILE=../../../output/host/opt/ext-toolchain/bin/arm-linuxgnueabihf$ make ARCH=arm CROSS_COMPILE=../../../output/host/opt/ext-toolchain/bin/arm-linuxgnueabihf- zImage
$ make ARCH=arm CROSS_COMPILE=../../../output/host/opt/ext-toolchain/bin/arm-linuxgnueabihf- dtbs
3. Updating Binary and System Image into the Target Board
This section describes how to update or flash the system image. The pre-build images include pre-build
driver and firmware binaries, which are available at GitHub.
The SAM-BA® tool is used to flash the binaries into the target board.
Note: Ensure that the SAM-BA tool is installed in the host machine before updating the system image.
The scripts in the demo package can use either SAM-BA 2.16 or 3.2.x depending on the download script
the user selects in step 5 of the following procedure.
For additional information, refer to the following:
•Software Tools
•SAMA5D4 Xplained Board
•ATSAMA5D44 Microprocessor
To start flashing, perform the following steps:
1.Download the pre-built images from https://github.com/linux4wilc/wilc_demo.
2.Unzip the downloaded file.
3.Once the new image is built as described in Chapter 2, Building Linux for SAMA5D4 Xplained Ultra
Board, these files must be copied from the buildroot\output\images directory to the directory
where the demo_linux_nandflash.tcl file is available.
Figure 3-1. List of Files in buildroot\output\images Location
4.Add the jumper at JP7 and connect to the host PC via the USB port at J11. Ensure that the host
machine completes the USB serial port connection and then remove the jumper at JP7. The
following figure shows the SAMA5D4 adapter connections.
5.Execute the demo_linux_nandflash.bat (for Windows®) file or the
demo_linux_nandflash.sh (for Linux) file.
Note:
•By default, the demo_linux_nandflash.sh file has sam-ba binary for 32-bit operating
system. For 64-bit operating system, change the sam-ba to sam-ba_64 in the same file.
•Execute the script in the super user mode. If sam-ba 3.2 is installed, use
demo_linux_nandflash_3_2.bat or demo_linux_nandflash_3_2.sh instead.
The output log can be viewed via J1 serial port.
Open the serial terminal on PC via the COM port, with the following configurations:
•115200 baud rate
•8-bit data
•No parity
•One stop bit
•No flow control
6.Successful download of the system image into the board is indicated by a log file, which opens
automatically. This log file contains all the download process history.
This chapter describes how to update the ATWILC firmware or driver on the demo image.
4.1 ATWILC1000 and ATWILC3000 Driver Modules
After the system boots, add the ATWILC driver modules wilc-sdio.ko, or wilc-spi.ko to /lib/
modules/4.9.xx-XX/kernel/drivers/staging/wilc1000/ directory or copy to any location on
the file system.
4.2 ATWILC1000 and ATWILC3000 Firmware Binaries
1.Add the ATWILC1000 firmware wilc1000_wifi_firmware.bin to the /lib/firmware/
mchp/ directory.
2.Add the ATWILC3000 Wi-Fi firmware, wilc3000_wifi_firmware.bin to the/lib/firmware/
mchp/ directory.
3.Add the ATWILC3000 Bluetooth® firmware, wilc3000_ble_firmware.bin to the wilc/lib/
firmware/mchp/ directory.
Updating ATWILC Firmware
Note: The firmware is available at https://github.com/linux4wilc/firmware.
The files can be transferred into the SAMA5D4 platform using any of the following methods:
•Ethernet
•ZMODEM
4.2.1 Adding Files Using Ethernet
The Local Area Network (LAN)/ Wide Area Network (WAN) can be used to transfer the file from one
machine to another machine, using the following command:
$ scp [path of file to send] root@[receiver's IP]:[target directory]
For example, the following command sends the wilc1000_wifi_firmware.bin file from the binary
directory to the /lib/firmware/mchp directory of the device using the internal IP address
This chapter describes how to use the ATWILC1000 and ATWILC3000 on the SAMA5D4 Xplained Board
or any similar Linux platform.
5.1 Accessing the Console
The user can access the serial console through the on board serial-to-USB converter. In fact, the
Embedded Debugger (EDBG) chip on the evaluation kit acts as a serial-to-USB converter and is loaded
with a firmware that can communicate via USB-CDC protocol.
To enable EDBG, open JP1 and connect the USB cable to the board (J20 EDBG-USB).
5.1.1 For Microsoft Windows Users
Install USB drivers for Atmel and Segger tools. Then, identify the USB connection that is established. The
user can verify this by checking if the EDBG virtual COM port appears in the Device Manager. The
COMxx number is used to configure the terminal emulator.
5.1.2 For Linux Users
Identify the USB connection by monitoring the last lines of dmesg command. The /dev/ttyACMx
number is used to configure the terminal emulator.
ATWILC1000/ATWILC3000
Running ATWILC
The following is the USB debug port connection:
[172677.700868] usb 2-1.4.4: new full-speed USB device number 31 using ehci-pci
[172677.792677] usb 2-1.4.4: not running at top speed; connect to a high speed hub
[172677.793418] usb 2-1.4.4: New USB device found, idVendor=03eb, idProduct=6124
[172677.793424] usb 2-1.4.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[172677.793897] cdc_acm 2-1.4.4:1.0: This device cannot do calls on its own. It is not a
modem.
[172677.793924] cdc_acm 2-1.4.4:1.0: ttyACM0: USB ACM device
The identifiers idVendor=03eb, and idProduct=6124 indicate the device as the evaluation kit board with
USB connection.
Now, use the terminal emulator with appropriate terminal settings (see Table 5-1) to communicate with
the SAMA5D4 adapter.
5.1.3 Serial Communication Parameters
The serial communication parameters are as follows:
The following section describes the SD express board and Serial Peripheral Interface (SPI) board
connections.
5.2.1 SD Express Board
Before performing the boot-up operation, ensure that the ATWILC1000 SD Express board is connected in
the SD slot (J24) of the SAMA5D4 Xplained board (see following figure).
Figure 5-1. SAMA5D4 SD Connection
ATWILC1000/ATWILC3000
Running ATWILC
The Secure Digital Input/Output (SDIO) Express card is recognized during boot-up with the following
lines.
mmc0: new high speed SDIO card at address 0001
Use the following commands to load the ATWILC1000 module SDIO driver.
Welcome to Buildroot
buildroot login: root
[root@buildroot ~]# insmod wilc.ko
wilc: module is from the staging directory, the quality is unknown, you have been warned.
[root@buildroot ~]# insmod wilc-sdio.ko
wilc_sdio: module is from the staging directory, the quality is unknown, you have been
warned.
linux_sdio_probe init_power =0
wilc_sdio mmc0:0001:1:Driver Initializing success
Note: Do not panic upon receiving the following message while loading the module:
wilc: module is from the staging directory, the quality is unknown, you have
been warned
This is the default message for all the drivers in kernel staging directory.
The ATWILC1000 Serial Peripheral Interface (SPI) board must be connected to SPI1 interface at J17 as
shown in the following figure.
Figure 5-2. SAMA5D4 SPI Connection
ATWILC1000/ATWILC3000
Running ATWILC
Table 5-2. SPI Pin Descriptions
SPI PinsHeader J17 Pins
MOSIPIN11
CLKPIN13
MISOPIN12
CSPIN10
IRQPIN8
Note: VEXT pin in the SPI card can be connected to 3V3 pin in the header J6. Re-configure to build the
driver in SPI mode with the WILC_SPI option in the kernel menuconfig. The modules wilc.ko and
wilc-spi.ko need to be loaded for the ATWILC1000 SPI driver.
5.3 Recognizing ATWILC3000
The following section describes the SDIO shield board and SPI shield board connections.
5.3.1 SDIO Shield Board
Before performing the boot-up operation, ensure that the ATWILC3000 Shield board is connected to the
Shield Arduino Shield Stacking Connector of the SAMA5D4 Xplained adapter.
Load the Wi-Fi SDIO driver module using the following command:
[root@buildroot ~]# insmod wilc.ko
wilc: module is from the staging directory, the quality is unknown, you have been warned.
[root@buildroot ~]# insmod wilc-sdio.ko
wilc_sdio: module is from the staging directory, the quality is unknown, you have been warned.
linux_sdio_probe init_power =0
wilc_sdio mmc0:0001:1: Driver Initializing success
Note: Do not panic upon receiving the following message while loading the module:
wilc: module is from the staging directory, the quality is unknown, you have
been warned
This is the default message for all the drivers in kernel staging directory.
5.3.2 Serial Peripheral Interface Shield Board
The ATWILC3000 Shield boards can operate using both SDIO and SPI, and are configured by installing
or removing 0 Ohm resistors. By default, the boards are preconfigured for SDIO mode.
To switch to the SPI mode, the user must change the following resistors as shown in the following
illustration.
Figure 5-3. ATWILC3000 Shield Board Configured for SPI
ATWILC1000/ATWILC3000
Running ATWILC
The resistors marked in green arrows must be connected and those marked in red arrows must be
removed.
Table 5-3. SPI Resistor Configuration
Resistors to be RemovedResistors to be Connected
R311R310
R218R214
R219R215
R220R216
R221R217
1.Load the Wi-Fi SDIO driver module, using the following command:
# modprobe wilc-spi
wilc_spi: module is from the staging directory, the quality is unknown, you have been
warned.
WILC_SPI spi32765.0: spiModalias: wilc_spi, spiMax-Speed: 48000000
(unnamed net_device) (uninitialized): INFO [wilc_create_wiphy]Registering wifi device
(unnamed net_device) (uninitialized): INFO [WILC_WFI_CfgAlloc]Allocating wireless device
(unnamed net_device) (uninitialized): INFO [wilc_create_wiphy]Successful Registering
(unnamed net_device) (uninitialized): INFO [wilc_create_wiphy]Registering wifi device
(unnamed net_device) (uninitialized): INFO [WILC_WFI_CfgAlloc]Allocating wireless device
(unnamed net_device) (uninitialized): INFO [wilc_create_wiphy]Successful Registering
WILC_SPI spi32765.0: WILC got 60 for gpio_reset
WILC_SPI spi32765.0: WILC got 94 for gpio_chip_en
WILC_SPI spi32765.0: WILC got 91 for gpio_irq
wifi_pm : 0
wifi_pm : 1
WILC_SPI spi32765.0: WILC SPI probe success
# ifconfig wlan0 up
WILC_SPI spi32765.0 wlan0: INFO [wilc_mac_open]MAC OPEN[d477d800] wlan0
WILC POWER UP
WILC_SPI spi32765.0 wlan0: INFO [wilc_init_host_int]Host[d477d800][d477cc00]
WILC_SPI spi32765.0 wlan0: INFO [wilc_mac_open]*** re-init ***
WILC_SPI spi32765.0 wlan0: INFO [wlan_init_locks]Initializing Locks ...
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_init]Initializing WILC_Wlan ...
WILC_SPI spi32765.0 wlan0: INFO [init_chip]Bootrom sts = c
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_initialize]WILC Initialization done
WILC_SPI spi32765.0 wlan0: INFO [init_irq]IRQ request succeeded IRQ-NUM= 137 on GPIO: 91
WILC_SPI spi32765.0 wlan0: INFO [wlan_initialize_threads]Initializing Threads ...
WILC_SPI spi32765.0 wlan0: INFO [wlan_initialize_threads]Creating kthread for
transmission
WILC_SPI spi32765.0 wlan0: INFO [wlan_initialize_threads]Creating kthread for Debugging
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_get_firmware]Detect chip WILC3000
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_get_firmware]loading firmware mchp/
wilc3000_wifi_firmware.bin
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_get_firmware]WLAN firmware: mchp/
wilc3000_wifi_firmware.bin
WILC_SPI spi32765.0 wlan0: INFO [wilc_firmware_download]Downloading Firmware ...
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_firmware_download]Downloading firmware size =
137172
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_firmware_download]Offset = 120228
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_firmware_download]Offset = 137172
WILC_SPI spi32765.0 wlan0: INFO [wilc_firmware_download]Download Succeeded
WILC_SPI spi32765.0 wlan0: INFO [linux_wlan_start_firmware]Starting Firmware ...
WILC_SPI spi32765.0 wlan0: INFO [linux_wlan_start_firmware]Waiting for Firmware to get
ready ...
WILC_SPI spi32765.0 wlan0: INFO [linux_wlan_start_firmware]Firmware successfully started
WILC_SPI spi32765.0 wlan0: INFO [wilc_wlan_initialize]WILC Firmware Ver =
WILC_WIFI_FW_REL_15_00_RC4 Build: 9153
[root@buildroot ~]#
5.4 Modifying Configuration Files
To use the Wi-Fi module, the user must load a set of default configuration files on the prebuilt image.
These files can be modified as per the requirement described in the following section.
5.4.1 Wi-Fi Protected Access Supplicant
The reference configuration files for Wi-Fi Protected Access (WPA) supplicant are available in: /etc/
directory. The configuration files for both Station and Access Point modes are available in the demo
prebuilt image.
5.4.1.1 Station Mode
The configuration file for Station mode wilc_wpa_supplicant.conf contains the following lines.
option subnet-mask 255.255.255.0;
option domain-name-servers 168.126.63.1, 164.124.101.2; # DNS Server IP
option domain-name “sample.example”; # domain name
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.100 192.168.0.110; # range ip
option broadcast-address 192.168.0.255;
option routers 192.168.0.1; # gateway ip
}
Log-facility local7;
Note: Each value must be modified as per the test environment.
The location of the dhcpd.conf file should match the location defined in /etc/init.d/S80dhcp-server under: test -f /etc/dhcp/dhcpd.conf || exit 0.
5.4.3 radvd
For IPv6, the radvd configuration file is required. The reference file on the demo image is available in
the /etc/radvd.conf directory.
The following example shows how to run the ATWILC device in Station mode, and connect to an AP.
1.Initialize the ATWILC1000 and ATWILC3000 driver module, using the following command:
Welcome to Buildroot
buildroot login: root
root@buildroot ~]# modprobe wilc-sdio
wilc_sdio: module is from the staging directory, the quality is unknown, you have been
warned.
linux_sdio_probe init_power =0
wilc_sdio mmc0:0001:1: Driver Initializing success
2.Start the WPA supplicant service and execute wpa_supplicant, using the following command:
Note: Change the User_AP with the Service Set Identifier (SSID) of the desired AP.
3.2.To connect to the WPA secured Access Point:
Use the following commands to scan and connect to a WPA or WPA2 and Temporal Key
Integrity Protocol (TKIP) or Advanced Encryption Standard (AES) protected AP.
The user can save and use the network information to automatically connect to the network using
the wpa_cli save command in Linux.
5.6 Running in the ATWILC AP Mode
This section describes how to connect a device to the ATWILC1000 Access Point.
1.Initialize the ATWILC1000 or ATWILC3000 driver module, using the following command:
[root@buildroot ~]# modprobe wilc-sdio
wilc_sdio: module is from the staging directory, the quality is unknown, you have been
warned.
linux_sdio_probe init_power =0
wilc_sdio mmc0:0001:1: Driver Initializing success
2.Run hostapd as user configuration, using the following command:
[root@buildroot ~]# hostapd /etc/wilc_hostapd_open.conf -B &
[root@buildroot ~]# Configuration file: /etc/wilc_hostapd_open.conf
rfkill: Cannot open RFKILL control device
wilc_sdio mmc0:0001:1 wlan0: Detect chip WILC3000
wilc_sdio mmc0:0001:1 wlan0: loading firmware wilc3000_wifi_firmware.bin
wilc_gnrl_async_info_received
wilc_sdio mmc0:0001:1 wlan0: WILC Firmware Ver = WILC_WIFI_FW_REL_15_00 Build: 8719
Using interface wlan0 with hwaddr fa:f0:05:f6:56:6a and ssid "wilc_SoftAP"
wilc_gnrl_async_info_received
wilc_sdio mmc0:0001:1 wlan0: there is no current Connect Request
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
ATWILC1000/ATWILC3000
Running ATWILC
Note: See the wilc_hostapd_open.conf file for unencrypted AP settings,
wilc_hostapd_wep.conf file for WEP AP settings and wilc_hostapd_wpa.conf file for
WPA/WPA2 AP settings.
3.Run DHCP server to allocate IP to client. Set the IP address to the gateway using the #ifconfigwlan0 192.168.0.1 command.
Note: The gateway IP address is defined in the dhcpd.conf file.
Start the DHCP server using the #/etc/init.d/S80dhcp-server start command.
The user can now connect the PC or smartphone to the ATWILC1000 access point.
To configure AP in the WPS mode, use the same steps for WPA/WPA2 settings, then use the
following command to configure to the Push-button mode:
hostapd_cli wps_pbc
(or) to configure for the pin mode, use the following command:
hostapd_cli wps_pin any <pin>
5.7 Running in the ATWILC P2P Mode
A P2P group includes two devices: One device acts as a P2P Group Owner (GO) and the other device
acts as a P2P Client. The ATWILC devices support both P2P GO and P2P Client modes. The following is
the procedure to test P2P mode on ATWILC.
There are two scenarios in which the P2P mode can be tested. The following section describes each
scenario:
3.On the terminal, enter into wpa_cli interactive mode, using the following command:
wpa_cli -ip2p0
4.Scan for neighbouring P2P devices for specified duration, using the following command:
p2p_find <scan_duration_in_seconds>
5.After the scan is complete, list the available P2P peers, using the following command:
p2p_peers
This command lists the BSSID of the P2P peer.
6.Connect to the P2P Go using the BSSID of the P2P peer, using the following command:
p2p_connect <MAC_ADDRESS> pbc go_intent=1
7.Press Ctrl+c to exit the interactive mode.
8.Run the DHCP client on the WILC to obtain IP address.
dhcpcd p2p0 &
Configuring a mobile phone as a group owner:
In the Wi-Fi settings menu on the phone, enter into Wi-Fi Direct mode and perform the following to
establish the connection.
•Trigger connection from WILC:
1.1.Enter the p2p_find command without time-out value on the WILC.
The SSID of the P2P peer appears on the phone.
1.2.Enter the p2p_connect command as shown above in the WILC. A pop-up window
appears on the phone.
1.3.Click the Accept button or prompt to connect.
•Trigger connection from phone:
2.1.Click the SSID displayed on the phone and send a P2P invite.
2.2.Enter the p2p_connect <MAC_ADDRESS> pbc command in the WILC to form a P2P
group.
5.8 Supported Modes with Concurrency
The ATWILC devices support the following modes to execute concurrently.
•STA - STA (see Running in the ATWILC Station Mode section)
•STA - P2P Client (see Running in the ATWILC Station Mode and Configuring WILC device as aP2P client sections)
•STA - P2P GO (see Running in the ATWILC Station Mode and Configuring WILC device as a groupowner sections)
•AP - P2P Client (see Running in the ATWILC AP Mode and Configuring WILC device as a P2Pclient sections)
•STA - AP (see Running the ATWILC Device in Station and AP Modes Concurrently section)Note: Use Wlan0 and p2p0 interfaces to run the ATWILC device concurrently.
5.8.1 Running the ATWILC Device in Station and AP Modes Concurrently
The following section describes the configuration steps to run the ATWILC device in Station (STA) and AP
modes, concurrently.
1.Initialize the ATWILC1000 and ATWILC3000 driver module, using the following command:
Welcome to Buildroot
buildroot login: root
[root@buildroot ~]# modprobe wilc-sdio
wilc_sdio: module is from the staging directory, the quality is unknown, you have been
warned.
linux_sdio_probe init_power =0
wilc_sdio mmc0:0001:1: Driver Initializing success
2.Start the WPA Supplicant service and execute wpa_supplicant, using the following command:
# wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wilc_wpa_supplicant.conf &
Successfully initialized wpa_supplicant
rfkill: Cannot open RFKILL control dev
wilc_sdio mmc0:0001:1 wlan0: Detect chip WILC3000
wilc_sdio mmc0:0001:1 wlan0: loading firmware wilc3000_wifi_firmware.bin
wilc_gnrl_async_info_received
wilc_sdio mmc0:0001:1 wlan0: WILC Firmware Ver = WILC_WIFI_FW_REL_15_00 Build: 8719
3.Connect to the Access Point, using the following command:
Note: The Powersave mode is disabled by default for AP and P2P mode.
5.9.2 BLE Powersave
To use BLE powersave, UART flow control should be enabled, to hold the host back from sending new
commands to the ATWILC3000 BLE controller when it is in Sleep mode.
This can be done using the Update UART Parameters vendor specific HCI command to enable flow
control on ATWILC3000, then update the host's UART configuration to enable flow control. Also, the host
application should allow the ATWILC3000 BLE controller to enter powersave, by setting the host's UART
Tx line low, entering a Break mode. Before starting any HCI communication, the application should get
the host's UART out of the Break mode, then proceed with sending the HCI commands to the
ATWILC3000.
ATWILC1000/ATWILC3000
Running ATWILC
When ATWILC3000 is in Powersave mode, it will set the UART RTS line high to hold back the host from
sending any additional HCI commands. Once the host UART Tx line is back high, ATWILC3000 will go
out of Powersave mode, but will not be fully active instantly. After ATWILC3000 is up and ready to receive
more HCI commands, it will set the UART RTS line low, and the host will be able to send more HCI
commands.
To disable Break mode and wake up ATWILC3000, use the following command:
# /etc/etc/uart_brk_ioctl
5.10 Antenna Switching
The ATWILC devices support antenna diversity where dual antennas are connected to the chip using an
external antenna switch.
Antenna switches are controlled using two input signals to select which antenna is in operation, and the
user uses two different configurations with respect to the control GPIOs:
1.Dual GPIO – two different ATWILC device GPIOs are used to control each of the antenna switch’s
control lines.
2.Single GPIO – a single ATWILC device GPIO is used to control one of the switch’s control lines,
and its inverse is connected to the other control line. This configuration requires an external
inverter. The antenna selection algorithm evaluates the average RSSI every second, and based on
that, it determines if it needs to switch the antenna.
The average RSSI is calculated based on the RSSI read while receiving each packet. If the average
RSSI is below threshold, it switches to the other antenna and sets a new threshold to the average RSSI
of the abandoned antenna. To avoid unnecessary switching, the antenna switching happens only when
the RSSI is below -30dBm, and has a margin of 1dBm to avoid hysteresis.
Sysfs entries can be used to configure the ATWILC device driver for the Antenna Diversity mode, and the
GPIOs that are used to control the antenna switch at run time.
5.10.1 Antenna Switch GPIO Control
Sysfs entry /sys/wilc/ant_swtch_mode can be used as follows to configure the GPIOs used to
control the antenna switch:
where, mode = 1 for Single Antenna , mode = 2 for Dual Antenna and 0 - to Disable diversity.
For WILC1000 valid GPIOs are 0, 1, 4 and 6, and for WILC3000 valid GPIOs are 0, 3, 4, 17, 18, 19 and
20.
5.10.2 GPIOs
To configure the GPIOs that are connected to the antenna switch, sysfs entry /sys/wilc/antenna1
and /sys/wilc/antenna2 can be used as follows.
# echo GPIO_NUM > /sys/wilc/antenna1 ( for single antenna switch)
# echo GPIO_NUM > /sys/wilc/antenna2 ( for dual antenna switch)
where, GPIO_NUM is any valid GPIO for antenna diversity.
Valid GPIOs for the ATWILC1000 are 0, 1, 4 and 6.
Valid GPIOs for the ATWILC3000 are 3, 4, 17, 18, 19 and 20.
5.10.3 Antenna Selection
The antenna used can be selected using the iw tool to either select Fixed Manual mode (antenna1 or
antenna2) or automatic switching according to the antenna performance as follows:
•Set the Antenna 1, using the following command:
iw phy phy3 set antenna 1 1
ATWILC1000/ATWILC3000
Running ATWILC
•Set the Antenna 2, using the following command:
iw phy phy3 set antenna 2 2
•Enable Automatic switching, using the following command:
iw phy phy3 set antenna 3 3
Note: Since WILC exposes two phy devices, both devices can be used to set the antenna
selection, but the same antenna selection is applied to both the devices. Also, before setting the
antenna selection, the antenna switch control GPIOs should be configured.
In Manual modes, the GPIOs is set according to the following tables.
The ATWILC driver inherits the debug logs levels from Linux. To change the system's debug level, use
one of the following methods:
#echo "7" > /proc/sys/kernel/printk
where "7" is the highest desired log level
or
# dmesg -n 7
To change the default level while building the kernel, change the following line in kernel_src/
include/linux/printk.h
#define CONSOLE_LOGLEVEL_DEFAULT 7
ATWILC driver also uses debugfs to allow the user to control which code regions to enable or disable logs
for.
To change it, the user has to first mount the debugfs:
# mount -t debugfs nodev /sys/kernel/debug
ATWILC1000/ATWILC3000
Running ATWILC
Then echo a number that represents a bit field of the regions that the user wants to enable logs from. The
bit field is defined as follows:
BIT 0: GENERIC
BIT 1: HOSTAPD
BIT 2: HOSTINF
BIT 3: CORECONFIG
BIT 4: CFG80211
BIT 5: INT
BIT 6: TX
BIT 7: RX
BIT 8: TCP
BIT 9: INIT
BIT 10: PWRDEV
5.12 Miscellaneous Linux Topics
This section provides additional information on Linux topics.
5.12.1 Host Suspend/Resume Mechanism
Upon suspending, Linux version 4.9 disconnects the Access Point. To maintain the connection after
suspending, modify the Linux code by removing the following code from the \net\wireless\sysfs.c
file.
//Prevent disconnecting from connected AP's on suspension
//if (!rdev->wiphy.wowlan_config)
//cfg80211_leave_all(rdev);
The following is the sample of the \net\wireless\sysfs.c file:
static int wiphy_suspend(struct device *dev, pm_message_t state)
{
struct cfg80211_registered_device *rdev = dev_to_rdev(dev);
int ret = 0;
if (rdev->wiphy.registered) {
//Prevent disconnecting from connected AP's on suspension
//if (!rdev->wiphy.wowlan_config)
//cfg80211_leave_all(rdev);
if (rdev->ops->suspend)
ret = rdev_suspend(rdev, rdev->wiphy.wowlan_config);
if (ret == 1) {
/* Driver refuse to configure wowlan */
cfg80211_leave_all(rdev);
ret = rdev_suspend(rdev, NULL);
}
}
rtnl_unlock();
return ret;
}
The user can configure Linux in Suspend mode, using mem string in the /sys/power/state path. For
more information, see https://www.kernel.org/doc/Documentation/power/interface.txt.
The controller then wakes up the host on certain wake-up on wireless LAN triggers that can be configured
using the iw tool. The controller then asserts a wake-up signal on a dedicated wake-up General Purpose
Input/output (GPIO) pin on the host board which is connected to the IRQ pin on ATWILC device board.
The ATWILC only supports the ANY option in the Wake on Wireless (WoW) mode from the set of allowed
wake-up triggers. The host wakes up the ATWILC device upon receiving any type of packets from the
connected access point if the triggers are set by the user. If it is not set by the user, the controller must
not wake up the host.
To configure the host wake-up triggers as ANY, use the following any command argument:
#iw phy0 wowlan enable any
Where phy0 resembles wireless hardware interface name, and any is the required trigger.
To disable all the triggers, use the disable argument as shown in the following command:
#iw phy0 wowlan disable
To show the configured triggers, use the show argument as shown in the following command:
#iw phy0 wowlan show
To configure the host into Suspend mode, use the following command:
#echo mem > /sys/power/state
5.12.2 Set Transmit Power
The user can control the Tx power of ATWILC1000 or ATWILC3000 using the iw tool with the following
command line arguments.
$ iw dev wlan0 set txpower fixed x
Where x is the desired Tx level.
The supported levels are 0, 3, 6, 9, 12, 15, and 18.
Note: If the input Tx power value is other than the mentioned supported levels, the x value is
automatically set to the first greater value.
To scan for the available APs, use the $ wpa_cli scan command.
5.12.4 Get Scan Results
To get a list of identified APs with associated attributes such as bssid, frequency, Received Signal
Strength Indicator (RSSI), encryption and Service Set Identifier (SSID), use the following command:
To change the default regulatory domain that Linux uses at startup, the user must edit the configuration
file that was passed while starting the wpa_cli using the vi tool. The configuration is as follows:
$ vi /etc/wilc_wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
update_config=1
country=US
network={
ssid="AndroidAP"
key_mgmt=NONE
}
5.13 Running ATWILC3000 in Bluetooth Mode
Use the following commands to use BLE after loading the wilc-sdio.ko modules.
When WILC3000 initializes, it creates a node at /dev/wilc_bt, which can be used to write the following
commands:
•BT_POWER_UP
•BT_DOWNLOAD_FW
•BT_FW_CHIP_WAKEUP
•BT_FW_CHIP_ALLOW_SLEEP
•BT_POWER_DOWN
ATWILC1000/ATWILC3000
Running ATWILC
5.13.1 BT_POWER_UP
The following command powers up the chip, and indicates that the BT requires the chip to be ON.
$ echo BT_POWER_UP > /dev/wilc_bt
5.13.2 BT_DOWNLOAD_FW
The following command downloads the BT firmware using SDIO.
$ echo BT_DOWNLOAD_FW > /dev/wilc_bt
5.13.3 BT_FW_CHIP_WAKEUP
The following command prevents the chip from sleeping.
$ echo BT_FW_CHIP_WAKEUP > /dev/wilc_bt
This command is used before downloading the firmware using Universal Asynchronous Receiver/
Transmitter (UART). Otherwise, the chip may go to Sleep mode when the stack is downloading the BT
firmware.
5.13.4 BT_FW_CHIP_ALLOW_SLEEP
The following command specifies that the at_pwr_dev module does not require the chip to be awake.
The user must use this command after downloading and starting the BT firmware using UART, allowing
the BT and Wi-Fi firmwares to take sleep or wake decisions.
The following command is used to chip down the power when the BT is not in use.
$ echo BT_POWER_DOWN > /dev/wilc_bt
The chip cannot be powered-down using the BT_POWER_DOWN command, if Wi-Fi is active. However,
using BT_POWER_UP and BT_POWER_DOWN in the correct sequence the user can power on and off
the chip successfully.
5.13.6 Attaching UART for Bluetooth
The ATWILC3000 Bluetooth driver provides the UART interface and is connected via a Teletypewriter
(TTY) device. It is connected to the BlueZ stack.
The following command is used to attach the device. Ensure that the /dev/ttyS1 folder is available on
the target platform. The user must set the Bluetooth firmware baud rate at 115200 and should enable
noflow control.
$ hciattach ttyS1 any 115200 noflow
Ensure that the Host Control Interface (HCI) is created.
$ hciconfig -a
hci0: Type: BR/EDR Bus: UART
BD Address: AB:89:67:45:23:01 ACL MTU: 1021:9 SCO MTU: 255:4
DOWN
RX bytes:574 acl:0 sco:0 events:27 errors:0
TX bytes:411 acl:0 sco:0 commands:27 errors:0
Features: 0xff 0xff 0xcd 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
ATWILC1000/ATWILC3000
Running ATWILC
5.13.7 Enabling the Bluetooth Interface
Enable the ATWILC3000 Bluetooth HCI interface, using the following command.
$ hciconfig hci0 up
5.13.8 Run bluetoothd (Bluetooth daemon)
The user must create symbolic link for the bluetoothd as:
Start the Bluetooth daemon in background using the $ bluetoothd -n & command.
5.13.9 Scanning for Devices
The user can scan for the neighboring networks using the $ scan on command. This command
displays a list of networks showing the Bluetooth address (BD_ADDR) and name when the scan is
complete.
Start the bluetoothctl using the $ bluetoothctl command, which can be used to scan and connect.
The following is a sample when the scan is started:
It is recommended to use the DBUS interface to connect to a device that is found during scanning.
Use the connect command to connect to the device with the specified Bluetooth address.
For example, to connect to the Bluetooth address 00:02:3C:3A:95:6F, use the following command:
$ connect 00:02:3C:3A:95:6F
5.13.11 BLE Peripheral Mode Example For BlueZ 5.28 and Earlier
BlueZ can be used to run in BLE Peripheral mode using the Low Energy Advertise command (leadv).
The Bluetooth Daemon (bluetoothd) is also used to provide time profile using the following commands:
[root@buildroot ~]# modprobe wilc-sdio
wilc_sdio: module is from the staging directory, the quality is unknown, you have been warned.
linux_sdio_probe init_power =0
wilc_sdio mmc0:0001:1: Driver Initializing success
[root@buildroot ~]# mmc0: card 0001 removed
mmc0: new high speed SDIO card at address 0001
linux_sdio_probe init_power =1
wilc_sdio mmc0:0001:1: Driver Initializing success
# echo BT_SDIO_INIT > /dev/wilc_bt
[root@buildroot ~]# echo BT_POWER_UP > /dev/wilc_bt
[root@buildroot ~]# echo BT_FW_CHIP_WAKEUP > /dev/wilc_bt
[root@buildroot ~]# echo BT_DOWNLOAD_FW > /dev/wilc_bt
[root@buildroot ~]# echo BT_FW_CHIP_ALLOW_SLEEP > /dev/wilc_bt
[root@buildroot ~]# hciattach ttyS1 any 115200 noflow
atmel_usart fc010000.serial: using dma0chan10 for rx DMA transfers
atmel_usart fc010000.serial: using dma0chan11 for tx DMA transfers
Device setup complete
[root@buildroot ~]# hciconfig hci0 up
[root@buildroot ~]# g_serial gadget: high-speed config #2: CDC ACM config
ln -svf /usr/libexec/bluetooth/bluetoothd /usr/sbin
'/usr/sbin/bluetoothd' -> '/usr/libexec/bluetooth/bluetoothd'
[root@buildroot ~]# bluetoothd -p time -n &
[1] 845
[root@buildroot ~]# bluetoothd[845]: Bluetooth daemon 5.21
bluetoothd[845]: Starting SDP server
bluetoothd[845]: Ignoring (cli) hostname
bluetoothd[845]: Ignoring (cli) wiimote
bluetoothd[845]: Ignoring (cli) autopair
bluetoothd[845]: Ignoring (cli) policy
bluetoothd[845]: Ignoring (cli) neard
bluetoothd[845]: Ignoring (cli) sap
bluetoothd[845]: Ignoring (cli) a2dp
bluetoothd[845]: Ignoring (cli) avrcp
bluetoothd[845]: Ignoring (cli) network
bluetoothd[845]: Ignoring (cli) input
bluetoothd[845]: Ignoring (cli) hog
bluetoothd[845]: Ignoring (cli) health
bluetoothd[845]: Ignoring (cli) gatt
bluetoothd[845]: Ignoring (cli) scanparam
bluetoothd[845]: Ignoring (cli) deviceinfo
bluetoothd[845]: Ignoring (cli) alert
bluetoothd[845]: Ignoring (cli) proximity
bluetoothd[845]: Ignoring (cli) thermometer
bluetoothd[845]: Ignoring (cli) heartrate
bluetoothd[845]: Ignoring (cli) cyclingspeed
bluetoothd[845]: Failed to open RFKILL control device
bluetoothd[845]: Bluetooth management interface 1.14 initialized
5.13.12 BLE Peripheral Mode Example for BlueZ 5.29 and Later
Starting with blueZ 5.29 and later, the time profile is no longer supported using bluetoothd. An
alternative approach is to use the btgatt-server example that is automatically built while building the blueZ
package. However, it is important to note that buildroot does not install this example to the target by
default, and it should be transferred manually to the host using scp or rz.
To install it automatically, the .mk file for blueZ in the buildroot system will need to be modified as follows:
Microchip provides online support via our web site at http://www.microchip.com/. This web site is used as
a means to make files and information easily available to customers. Accessible by using your favorite
Internet browser, the web site contains the following information:
•Product Support – Data sheets and errata, application notes and sample programs, design
resources, user’s guides and hardware support documents, latest software releases and archived
software
•General Technical Support – Frequently Asked Questions (FAQ), technical support requests,
online discussion groups, Microchip consultant program member listing
•Business of Microchip – Product selector and ordering guides, latest Microchip press releases,
listing of seminars and events, listings of Microchip sales offices, distributors and factory
representatives
Customer Change Notification Service
Microchip’s customer notification service helps keep customers current on Microchip products.
Subscribers will receive e-mail notification whenever there are changes, updates, revisions or errata
related to a specified product family or development tool of interest.
To register, access the Microchip web site at http://www.microchip.com/. Under “Support”, click on
“Customer Change Notification” and follow the registration instructions.
Customer Support
Users of Microchip products can receive assistance through several channels:
•Distributor or Representative
•Local Sales Office
•Field Application Engineer (FAE)
•Technical Support
Customers should contact their distributor, representative or Field Application Engineer (FAE) for support.
Local sales offices are also available to help customers. A listing of sales offices and locations is included
in the back of this document.
Technical support is available through the web site at: http://www.microchip.com/support
Microchip Devices Code Protection Feature
Note the following details of the code protection feature on Microchip devices:
•Microchip products meet the specification contained in their particular Microchip Data Sheet.
•Microchip believes that its family of products is one of the most secure families of its kind on the
market today, when used in the intended manner and under normal conditions.
•There are dishonest and possibly illegal methods used to breach the code protection feature. All of
these methods, to our knowledge, require using the Microchip products in a manner outside the
operating specifications contained in Microchip’s Data Sheets. Most likely, the person doing so is
engaged in theft of intellectual property.
•Microchip is willing to work with the customer who is concerned about the integrity of their code.
•Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their
code. Code protection does not mean that we are guaranteeing the product as “unbreakable.”
Code protection is constantly evolving. We at Microchip are committed to continuously improving the
code protection features of our products. Attempts to break Microchip’s code protection feature may be a
violation of the Digital Millennium Copyright Act. If such acts allow unauthorized access to your software
or other copyrighted work, you may have a right to sue for relief under that Act.
Legal Notice
Information contained in this publication regarding device applications and the like is provided only for
your convenience and may be superseded by updates. It is your responsibility to ensure that your
application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR
WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY
OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS
CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE.
Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life
support and/or safety applications is entirely at the buyer’s risk, and the buyer agrees to defend,
indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting
from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual
property rights unless otherwise stated.
Trademarks
The Microchip name and logo, the Microchip logo, AnyRate, AVR, AVR logo, AVR Freaks, BeaconThings,
BitCloud, CryptoMemory, CryptoRF, dsPIC, FlashFlex, flexPWR, Heldo, JukeBlox, KeeLoq, KeeLoq logo,
Kleer, LANCheck, LINK MD, maXStylus, maXTouch, MediaLB, megaAVR, MOST, MOST logo, MPLAB,
OptoLyzer, PIC, picoPower, PICSTART, PIC32 logo, Prochip Designer, QTouch, RightTouch, SAM-BA,
SpyNIC, SST, SST Logo, SuperFlash, tinyAVR, UNI/O, and XMEGA are registered trademarks of
Microchip Technology Incorporated in the U.S.A. and other countries.
ClockWorks, The Embedded Control Solutions Company, EtherSynch, Hyper Speed Control, HyperLight
Load, IntelliMOS, mTouch, Precision Edge, and Quiet-Wire are registered trademarks of Microchip
Technology Incorporated in the U.S.A.
Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, BodyCom,
chipKIT, chipKIT logo, CodeGuard, CryptoAuthentication, CryptoCompanion, CryptoController,
dsPICDEM, dsPICDEM.net, Dynamic Average Matching, DAM, ECAN, EtherGREEN, In-Circuit Serial
Programming, ICSP, Inter-Chip Connectivity, JitterBlocker, KleerNet, KleerNet logo, Mindi, MiWi,
motorBench, MPASM, MPF, MPLAB Certified logo, MPLIB, MPLINK, MultiTRAK, NetDetach, Omniscient
Code Generation, PICDEM, PICDEM.net, PICkit, PICtail, PureSilicon, QMatrix, RightTouch logo, REAL
ICE, Ripple Blocker, SAM-ICE, Serial Quad I/O, SMART-I.S., SQI, SuperSwitcher, SuperSwitcher II, Total
Endurance, TSHARC, USBCheck, VariSense, ViewSpan, WiperLock, Wireless DNA, and ZENA are
trademarks of Microchip Technology Incorporated in the U.S.A. and other countries.
SQTP is a service mark of Microchip Technology Incorporated in the U.S.A.
Silicon Storage Technology is a registered trademark of Microchip Technology Inc. in other countries.
GestIC is a registered trademark of Microchip Technology Germany II GmbH & Co. KG, a subsidiary of
Microchip Technology Inc., in other countries.
All other trademarks mentioned herein are property of their respective companies.
2018, Microchip Technology Incorporated, Printed in the U.S.A., All Rights Reserved.
ISBN: 978-1-5224-3249-4
Quality Management System Certified by DNV
ISO/TS 16949
Microchip received ISO/TS-16949:2009 certification for its worldwide headquarters, design and wafer
fabrication facilities in Chandler and Tempe, Arizona; Gresham, Oregon and design centers in California
and India. The Company’s quality system processes and procedures are for its PIC® MCUs and dsPIC
DSCs, KEELOQ® code hopping devices, Serial EEPROMs, microperipherals, nonvolatile memory and
analog products. In addition, Microchip’s quality system for the design and manufacture of development
systems is ISO 9001:2000 certified.