wiki:802.11/Usage

Version 14 (modified by chunter, 10 years ago) (diff)

--

The 802.11 Reference Design and its documentation are under active development by the Mango team. The current release should be considered a beta- updates with bug fixes, API changes, new features and other refinements will be posted frequently. Please check the downloads page for the latest updates and post any questions about the design to the forums.

802.11 Reference Design: Usage

The 802.11 Reference Design contains two implementations that share much of the same MAC and PHY. These implementations are an AP that can be joined by 802.11 devices and a station (STA) that can be used to join 802.11 APs (WARP or otherwise).

802.11 AP

By default, the AP Reference Design implements an 802.11 compatible access point with SSID "WARP-AP". To use the design in this configuration:

  1. Plug ETH A from a WARP v3 board into a router whose WAN port is connected to the Internet. The 802.11 Reference Design is not a router -- it does not have a DHCP server to issue IP addresses to associated stations. It will, however, pass DHCP requests and responses through its Ethernet portal, so connecting WARP v3 to a router will allow DHCP to occur on client stations.
  2. Download the 802.11 Reference Design and program a WARP v3 board with the provided bitstream for the AP implementation.
  3. Use any 802.11 device (such as a computer or smartphone) to join the unsecured network with SSID of "WARP-AP." At this point, the 802.11 device should be able to access the network.

802.11 STA

By default, the STA Reference Design will attempt to associate with an AP that is advertising an SSID of "WARP-AP." The stock AP Reference Design meets this criteria, so programming one board with the AP design followed by programming another board with the STA design is sufficient to create a connection. Alternatively, the UART menu on the station can be used to perform an active scan and display the list of all nearby APs and their SSIDs. This menu can then be used to attempt association to one of those APs. TO use this design,

  1. Plug ETH A from a WARP v3 board into a single Ethernet device such as a laptop or desktop PC. The STA design will bridge the Ethernet link of that device to the 802.11 wireless link. NOTE: do not plug ETH A into a switch if that switch has more than one Ethernet device on it. The current STA implementation assumes that all traffic it receives over Ethernet comes from a single source.
  2. Download the 802.11 Reference Design and program a WARP v3 board with the provided bitstream for the STA implementation.
  3. Use the UART menu to associate with a nearby AP.
  4. Access the wireless network with the device that is plugged into ETH A.

Using the UART Menu

Both the AP and STA implementations include extensive control of parameters via UART. The instructions provided here show how to connect to the USB UART on WARP v3. The 802.11 Reference Design uses a baud rate of 115200 for all UART interactions.

AP UART Capabilities

  • Change the advertised SSID
  • Change the channel
  • Change the rate used for unicast transmissions
  • Print the current status of transmit queues
  • Enter an interactive AP menu where
    • individual station statistics can be observed (e.g. last received power, packet counts, etc)
    • traffic can be locally generated for any number of connected stations

STA UART Capabilities

  • Perform an active scan and details about nearby access points
  • Associate with an access point displayed during the active scan
  • Change the rate used for unicast transmissions
  • Enter an interactive STA menu where
    • statistics about the associated AP can be observed (e.g. last received power, packet counts, etc)
    • traffic can be locally generated for the associated AP

Creating the SDK Workspace

  1. Ensure your Xilinx tools match the version used to create the reference design (see the download page for the current versions)
  2. Ensure your local copy of the WARP edk_user_repository is up to date and in the repository search path of XPS (see edk_user_repository for details)
  3. Download the 802.11 Reference Design archive and expand the inner .zip archive in <ref_design_archive>/EDK_Projects/w3_802.11_EDK_vXXX.zip.
    • Be sure the expanded EDK project path has no spaces; C:/work/w3_802.11_EDK/ works, C:/Documents and Settings/user/w3_802.11_EDK/ does not
    • The text below assumes your expanded EDK project is in <xps_proj>/.
  4. Launch Xilinx SDK and select <xps_proj>/SDK_Workspace as the active workspace
  5. Select Xilinx Tools -> Repositories. In Local Repositories click New, then select <xps_proj>/ and click OK.
  6. Import the 7 SDK projects provided by the reference design
    1. Select File -> Import
    2. Expand General -> Existing Projects into Workspace, click Next
    3. Click Browse and navigate to <xps_proj>/SDK_Workspace
    4. Six projects will be listed:
      wlan_bsp_cpu_high
      wlan_bsp_cpu_low
      wlan_mac_ap
      wlan_mac_sta
      wlan_mac_dcf
      wlan_mac_shared
      wlan_xps_vXX_hw_platform  <- the version number in this project name will change between releases
      
    5. Ensure all 7 projects are checked and click Finish
    6. In the SDK Project Explorer:
      1. Right click on the wlan_mac_ap project and select Change Referenced BSP. In the dialog box select wlan_bsp_cpu_high then click OK
      2. Right click on the wlan_mac_dcf project and select Change Referenced BSP. In the dialog box select wlan_bsp_cpu_low then click OK
      3. Right click on the wlan_mac_ap project and select Clean Project
      4. Right click on the wlan_mac_sta project and select Clean Project
      5. Right click on the wlan_mac_dcf project and select Clean Project
  7. Both software projects should now build to completion. Watch the console for the message elfcheck passed

Debugging Software

The dual-processor architecture of the 802.11 Reference Design presents some challenges in debugging the software applications.

The usual debugging tools in the Xilinx SDK work fine with dual-processor designs. The Reference Design includes one instance of the mdm pcore. The mdm is connected to both MicroBlaze debug ports. The PC-side debug tools can connect to either MB via the mdm and xmd.

Each MicroBlaze processor has an xps_uartlite peripheral mapped to stdin/stdout. The WARP v3 hardware has only USB-UART transceiver. The Reference Design includes a uart_mux core which allows either xps_uartlite to connect to the USB-UART transceiver. By default the mux is controlled by the LSB of the user DIP switch on the WARP v3 board. A 0 (switch down) selects the UART for CPU Low.

Debug Signals

The Reference Design routes various internal MAC/PHY signals to the 16-pin debug header on the WARP v3 node. These signals allow monitoring of MAC/PHY state at run time using an oscilloscope or logic analyzer. The current pin assignments are listed below. These may change between releases, depending on what we're debugging at the time. You can confirm the current pin assignments by looking at the PORT debughdr = ... line in the system.mhs file.

Refer to the WARP v3 user guide for the numbering of pins on the header.

Pin Signal
0 OFDM Rx PHY running: asserts when the first FFT is started and de-asserts when the Rx PHY completes processing
1 Rx Packet Detect: asserts when the Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY started event
2 LTS Timeout: asserts briefly when the Rx PHY fails to correlate the preamble LTS following a packet detection event
3 Tx Pending: asserted by the MAC hardware when a new Tx MPDU is provided by the MAC but has not yet been submitted to the Tx PHY
4 RSSI Det: asserts when the instantaneous RSSI exceeds a programmed threshold (debug only - does not indicate actual PHY state)
5 FCS Good: asserts briefly after the PHY writes the last byte of a received frame to the packet buffer and the checksum calculation indicates no errors
6 Tx PHY Running: asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted
7 DSSS Rx PHY Running: asserts when the DSSS receiver is processing a frame
8 NAV Active: asserted whenever the MAC is enforcing backoff due to virtual carrier sense after reception of a frame with a valid duration field
9 Idle for DIFS: asserted whenever the MAC observes the medium has been idle longer than DIFS interval
10 EIFS Sel: asserted when the MAC is enforcing an EIFS interval of idle time
11 Backoff Active: asserted whenever the MAC is deferring to a busy medium; the MAC will not transmit when backing off
12:15 Sw Debug: General debug outputs controlled by software via a register in the Rx PHY; useful for unobtrusively measuring software execution times