wiki:802.11/Usage

Version 10 (modified by chunter, 11 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

By default, the 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.
  3. Use any 802.11 device (such as a computer or smartphone) to join the unsecured network with SSID of "WARP." At this point, the 802.11 device should be able to access the network.

Creating the SDK Workspace

  1. Ensure your Xilinx tools match the version used to create the reference design (see the downloads? 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 5 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. Five projects will be listed:
      wlan_bsp_cpu_high
      wlan_bsp_cpu_low
      wlan_mac_ap
      wlan_mac_dcf
      wlan_xps_v00_hw_platform  <- the version number in this project name will change between releases
      
    5. Ensure all 5 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_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