Version 3 (modified by murphpo, 8 years ago) (diff)


Using the 802.11 Reference Design: User IO


The user LEDs are controlled from the software project running in CPU Low.

In the DCF and NoMAC applications the LEDs indicate packet receptions.

The green LEDs indicate successful packet receptions. One green LED is illuminated at any given time. The active LED increments with each error-free packet reception.

The red LEDs indicate failed packet receptions. One red LED is illuminated at any given time. The active red LED increments with each reception event which ends with a checksum error (bad FCS).

The rate of the LED activity reflects the frequency of packet receptions in the lower-level MAC.

Hex Displays

The MAC High Framework uses the hex displays to indicate error conditions during initialization. If an error occurs the displays will show one of the following codes:

  • E0: The MAC code failed a change of the ">>" (right shift) operator, indicating the application was compiled with a buggy version Xilinx tools
  • E1: Insufficient RAM was allocated for the Ethernet DMA Tx buffer descriptor
  • E2: A DDR3 SO-DIMM was not detected at boot

After initialization the hex displays are used by the upper-level MAC applications. Each MAC application uses the displays differently:

DIP Switch

The right-most switch controls the UART mux.

The left 3 switches are used by the MAC applications:

Debug Header Signals

The 802.11 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 Map for v1.0:

Pin In/Out Signal Description
0 Out Tx PHY Active: asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted
1 Out OFDM Rx PHY Active: asserts when the first FFT is started and de-asserts when the Rx PHY completes processing
2 Out DSSS Rx PHY Active: asserts when the DSSS receiver is processing a frame
3 Out OFDM Packet Detect: asserts when the OFDM Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY active event
4 Out DSSS Packet Detect: asserts when the DSSS Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY active event
5 Out LTS Timeout: asserts briefly when the Rx PHY fails to correlate the preamble LTS following a packet detection event
6 Out 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
7 Out RSSI Det: asserts when the instantaneous RSSI exceeds a programmed threshold (debug only - does not indicate actual PHY state)
8 Out 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
9 Out Idle for DIFS: asserted whenever the MAC observes the medium has been idle longer than DIFS interval
10 Out Backoff Active: asserted whenever the MAC is deferring to a busy medium; the MAC will not transmit when backing off
11 Out NAV Active: asserted whenever the MAC is enforcing backoff due to virtual carrier sense after reception of a frame with a valid duration field
12:14 Out Sw Debug: General debug outputs controlled by software via a register in the Rx PHY; useful for unobtrusively measuring software execution times
15 In Rx OFDM Ext Pkt Det: input to PHY pkt detect logic which forces a pkt det event, independent of the normal detection thresholds; useful for assuring the Rx PHY attempts reception of every packet transmitted by another node (Tx PHY Active -> Ext Pkt Det is "perfect" packet detection)