wiki:802.11/Usage/UserIO

Using the 802.11 Reference Design: User IO

LEDs

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

The WARP v3 hardware provides a 16-pin debug header tied directly to 16 FPGA IO pins. The 802.11 Reference Design uses the debug header for real time monitoring of internal MAC and PHY state. These signals can be observed with an oscilloscope or logic analyzer.

Starting in release v1.5.3 the 802.11 Reference Design uses the updated w3_userio core to manage the 16-pin debug header on the WARP v3 hardware. The w3_userio core's debug header logic supports runtime selection of hardware or software control of each debug pin.

When a pin is configured for hardware control the debug pin is driven directly by design-specific logic in the FPGA. See the table below for the list of MAC/PHY signals tied to the hardware-controlled outputs.

When a pin is configured for software control the debug pin can be used as an output whose state is controlled from C code or as an input whose state is readable by C code. The control source (hardware vs software) and direction (input vs output for software-controlled pins) are configured by C code using the w3_userio driver.

Important Update: As of v1.5.3 both CPUs can access the software-controlled debug I/O via the single w3_userio core. The state of a debug output is stored in the w3_userio core. Either CPU can set or unset each software-controlled output at any time. This is a changed from previous releases where the software-controlled outputs were driven by an OR of values written by each CPU.

By default the 802.11 Reference Design configures:

  • Pins 15, 14, 13, 12: software-controlled outputs, used for real-time debug and characterization of C code in CPU High or Low
  • Pins 11 to 0: hardware-controlled outputs, tied to various MAC and PHY status signals (see below)

The MAC framework provides helper macros in wlan_mac_userio_util.h for accessing the debug header configuration and pin states. These macros can be used anywhere in the C code in CPU High and Low. For example, to use pin 15 as a software-controlled output to benchmark execution time of a code block:

// Assert pin 15
wlan_mac_set_dbg_hdr_out(0x8000); //assert p15
{ /* Benchmark code here */ }
wlan_mac_clear_dbg_hdr_out(0x8000); //clear p15

The 802.11 Reference Design hardware project routes 16 MAC/PHY status signals to the w3_userio debug port. By default (see above) only 12 of these hardware status signals are routed to the debug header, reserving the top 4 pins for software-controlled I/O. The table below lists all 16 status signals. To access the status signals on pins 15, 14, 13, 12 the corresponding pins must be re-configured as hardware-controlled outputs in the C code.

Hardware debug signals design release v1.6 and later:

Pin Signal Description
0 Tx PHY Active: asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted
1 OFDM Rx PHY Active: asserts when the first FFT is started and de-asserts when the Rx PHY completes processing
2 DSSS Rx PHY Active: asserts when the DSSS receiver is processing a frame
3 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 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 LTS Timeout: asserts briefly when the Rx PHY fails to correlate the preamble LTS following a packet detection event
6 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 RSSI Det: asserts when the instantaneous RSSI exceeds a programmed threshold (debug only - does not indicate actual PHY state)
8 Tx A Pending: asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller A by the MAC software, de-asserts when the Tx PHY completes the transmission
9 Idle for DIFS: asserted whenever the MAC observes the medium has been idle longer than DIFS interval
10 Backoff A Active: asserted whenever the backoff counter for Tx Controller A is non-zero, indicating the MAC hardware will defer a transmission
11 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 Tx B Pending: asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller B by the MAC software, de-asserts when the Tx PHY completes the transmission
13 Backoff C Active: asserted whenever the backoff counter for Tx Controller C is non-zero, indicating the MAC hardware will defer a transmission
14 Tx C Pending: asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller C by the MAC software, de-asserts when the Tx PHY completes the transmission
15 Tx D Pending: asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller D by the MAC software, de-asserts when the Tx PHY completes the transmission

The tables below list the debug header pin map for previous releases of the 802.11 Reference Design.

Hardware debug signals design release v1.5.3 - v1.5.4:

Pin Signal Description
0 Tx PHY Active: asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted
1 OFDM Rx PHY Active: asserts when the first FFT is started and de-asserts when the Rx PHY completes processing
2 DSSS Rx PHY Active: asserts when the DSSS receiver is processing a frame
3 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 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 LTS Timeout: asserts briefly when the Rx PHY fails to correlate the preamble LTS following a packet detection event
6 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 RSSI Det: asserts when the instantaneous RSSI exceeds a programmed threshold (debug only - does not indicate actual PHY state)
8 Tx A Pending: asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller A by the MAC software, de-asserts when the Tx PHY completes the transmission
9 Idle for DIFS: asserted whenever the MAC observes the medium has been idle longer than DIFS interval
10 Backoff A Active: asserted whenever the backoff counter for Tx Controller A is non-zero, indicating the MAC hardware will defer a transmission
11 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 Tx B Pending: asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller B by the MAC software, de-asserts when the Tx PHY completes the transmission
13 Backoff C Active: asserted whenever the backoff counter for Tx Controller C is non-zero, indicating the MAC hardware will defer a transmission
14 Tx C Pending: asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller C by the MAC software, de-asserts when the Tx PHY completes the transmission
15 EIFS Sel: asserted whenever the MAC is using the EIFS interval instead of DIFS, required when the most recent medium busy event is a reception with bad FCS

Pin Map for design v1.5.0 - v1.5.2:

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:15 Out Sw Debug: General debug outputs controlled by software via a register in the Rx PHY; useful for unobtrusively measuring software execution times

Pin Map for design v1.0 - v1.4:

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)
Last modified 6 years ago Last modified on Dec 5, 2017, 4:21:21 PM