Microchip PIC18 datasheet: 17.0 Universal serial bus (USB)

17.0 UNIVERSAL SERIAL BUS (USB)

This section describes the details of the USB peripheral. Because of the very specific nature of the module, knowledge of USB is expected. Some high-level USB information is provided in Section 17.10 “Overview of USB” only for application design reference. Designers are encouraged to refer to the official specification published by the USB Implementers Forum (USB-IF) for the latest information. USB specification Revision 2.0 is the most current specification at the time of publication of this document.

17.1 Overview of the USB Peripheral

The PIC18FX455/X550 device family contains a full-speed and low-speed compatible USB Serial Interface Engine (SIE) that allows fast communication between any USB host and the PIC® microcontroller. The SIE can be interfaced directly to the USB, utilizing the internal transceiver, or it can be connected through an external transceiver. An internal 3.3V regulator is also available to power the internal transceiver in 5V applications.

Some special hardware features have been included to improve performance. Dual port memory in the device’s data memory space (USB RAM) has been supplied to share direct memory access between the microcontroller core and the SIE. Buffer descriptors are also provided, allowing users to freely program endpoint memory usage within the USB RAM space. A Streaming Parallel Port has been provided to support the uninterrupted transfer of large volumes of data, such as isochronous data, to external memory buffers.

Figure 17-1 presents a general overview of the USB peripheral and its features.

FIGURE 17-1: USB PERIPHERAL AND OPTIONS

Note 1: This signal is only available if the internal transceiver is disabled (UTRDIS = 1). 2: The internal pull-up resistors should be disabled (UPUEN = 0) if external pull-up resistors are used. 3: Do not enable the internal regulator when using an external 3.3V supply.

17.2 USB Status and Control

The operation of the USB module is configured and managed through three control registers. In addition, a total of 22 registers are used to manage the actual USB transactions. The registers are:

• USB Control register (UCON)
• USB Configuration register (UCFG)
• USB Transfer Status register (USTAT)
• USB Device Address register (UADDR)
• Frame Number registers (UFRMH:UFRML)
• Endpoint Enable registers 0 through 15 (UEPn)

17.2.1 USB CONTROL REGISTER (UCON)

The USB Control register (Register 17-1) contains bits needed to control the module behavior during transfers. The register contains bits that control the following:

• Main USB Peripheral Enable
• Ping-Pong Buffer Pointer Reset
• Control of the Suspend mode
• Packet Transfer Disable

In addition, the USB Control register contains a status bit, SE0 (UCON<5>), which is used to indicate the occurrence of a single-ended zero on the bus. When the USB module is enabled, this bit should be monitored to determine whether the differential data lines have come out of a single-ended zero condition. This helps to differentiate the initial power-up state from the USB Reset signal.

The overall operation of the USB module is controlled by the USBEN bit (UCON<3>). Setting this bit activates the module and resets all of the PPBI bits in the Buffer Descriptor Table to '0'. This bit also activates the on-chip voltage regulator (if the VREGEN Configuration bit is set) and connects internal pull-up resistors, if they are enabled. Thus, this bit can be used as a soft attach/detach to the USB. Although all status and control bits are ignored when this bit is clear, the module needs to be fully preconfigured prior to setting this bit.

Note: When disabling the USB module, make sure the SUSPND bit (UCON<1>) is clear prior to clearing the USBEN bit. Clearing the USBEN bit when the module is in the suspended state may prevent the module from fully powering down.

REGISTER 17-1: UCON: USB CONTROL REGISTER

The PPBRST bit (UCON<6>) controls the Reset status when Double-Buffering mode (ping-pong buffering) is used. When the PPBRST bit is set, all Ping-Pong Buffer Pointers are set to the Even buffers. PPBRST has to be cleared by firmware. This bit is ignored in buffering modes not using ping-pong buffering.

The PKTDIS bit (UCON<4>) is a flag indicating that the SIE has disabled packet transmission and reception. This bit is set by the SIE when a SETUP token is received to allow setup processing. This bit cannot be set by the microcontroller, only cleared; clearing it allows the SIE to continue transmission and/or reception. Any pending events within the Buffer Descriptor Table will still be available, indicated within the USTAT register's FIFO buffer.

The RESUME bit (UCON<2>) allows the peripheral to perform a remote wake-up by executing Resume signaling. To generate a valid remote wake-up, firmware must set RESUME for 10 ms and then clear the bit. For more information on Resume signaling, see Sections 7.1.7.5, 11.4.4 and 11.9 in the USB 2.0 specification.

The SUSPND bit (UCON<1>) places the module and supporting circuitry (i.e., voltage regulator) in a low-power mode. The input clock to the SIE is also disabled. This bit should be set by the software in response to an IDLEIF interrupt. It should be reset by the microcontroller firmware after an ACTIVIF interrupt is observed. When this bit is active, the device remains attached to the bus but the transceiver outputs remain Idle. The voltage on the Vusb pin may vary depending on the value of this bit. Setting this bit before a IDLEIF request will result in unpredictable bus behavior.

Note: While in Suspend mode, a typical bus powered USB device is limited to 2.5 mA of current. Care should be taken to assure minimum current draw when the device enters Suspend mode.

17.2.2 USB CONFIGURATION REGISTER (UCFG)

Prior to communicating over USB, the module's associated internal and/or external hardware must be configured. Most of the configuration is performed with the UCFG register (Register 17-2). The separate USB voltage regulator (see Section 17.2.2.8 "Internal Regulator") is controlled through the Configuration registers.

The UFCG register contains most of the bits that control the system level behavior of the USB module. These include:

• Bus Speed (full speed versus low speed)
• On-Chip Pull-up Resistor Enable
• On-Chip Transceiver Enable
• Ping-Pong Buffer Usage

The UCFG register also contains two bits which aid in module testing, debugging and USB certifications. These bits control output enable state monitoring and eye pattern generation.

Note: The USB speed, transceiver and pull-up should only be configured during the module setup phase. It is not recommended to switch these settings while the module is enabled.

17.2.2.1 Internal Transceiver

The USB peripheral has a built-in, USB 2.0, full-speed and low-speed compliant transceiver, internally connected to the SIE. This feature is useful for low-cost single chip applications. The UTRDIS bit (UCFG<3>) controls the transceiver; it is enabled by default (UTRDIS = 0). The FSEN bit (UCFG<2>) controls the transceiver speed; setting the bit enables full-speed operation.

The on-chip USB pull-up resistors are controlled by the UPUEN bit (UCFG<4>). They can only be selected when the on-chip transceiver is enabled.

The USB specification requires 3.3V operation for communications; however, the rest of the chip may be running at a higher voltage. Thus, the transceiver is supplied power from a separate source, VUSB.

17.2.2.2 External Transceiver

This module provides support for use with an off-chip transceiver. The off-chip transceiver is intended for applications where physical conditions dictate the location of the transceiver to be away from the SIE. External transceiver operation is enabled by setting the UTRDIS bit.

FIGURE 17-2: TYPICAL EXTERNAL TRANSCEIVER WITH ISOLATION

Note: The above setting shows a simplified schematic for a full-speed configuration using an external transceiver with isolation.

REGISTER 17-2: UCFG: USB CONFIGURATION REGISTER

Legend:

R = Readable bit
W = Writable bit
U = Unimplemented bit, read as ‘0’
-n = Value at POR
‘1’ = Bit is set
‘0’ = Bit is cleared
x = Bit is unknown

bit 7
UTEYE: USB Eye Pattern Test Enable bit
1 = Eye pattern test enabled
0 = Eye pattern test disabled

bit 6
UOEMON: USB OE Monitor Enable bit⁽¹⁾
1 = UOE signal active; it indicates intervals during which the D+/D- lines are driving
0 = UOE signal inactive

bit 5
Unimplemented: Read as ‘0’

bit 4
UPUEN: USB On-Chip Pull-up Enable bit⁽²,³⁾
1 = On-chip pull-up enabled (pull-up on D+ with FSEN = 1 or D- with FSEN = 0)
0 = On-chip pull-up disabled

bit 3
UTRDIS: On-Chip Transceiver Disable bit⁽²⁾
1 = On-chip transceiver disabled; digital transceiver interface enabled
0 = On-chip transceiver active

bit 2
FSEN: Full-Speed Enable bit⁽²⁾
1 = Full-speed device: controls transceiver edge rates; requires input clock at 48 MHz
0 = Low-speed device: controls transceiver edge rates; requires input clock at 6 MHz

bit 1-0
PPB1:PPB0: Ping-Pong Buffers Configuration bits
11 = Even/Odd ping-pong buffers enabled for Endpoints 1 to 15
10 = Even/Odd ping-pong buffers enabled for all endpoints
01 = Even/Odd ping-pong buffer enabled for OUT Endpoint 0
00 = Even/Odd ping-pong buffers disabled

Note 1: If UTRDIS is set, the UOE signal will be active independent of the UOEMON bit setting.
2: The UPUEN, UTRDIS and FSEN bits should never be changed while the USB module is enabled. These values must be preconfigured prior to enabling the module.
3: This bit is only valid when the on-chip transceiver is active (UTRDIS = 0); otherwise, it is ignored.

There are 6 signals from the module to communicate with and control an external transceiver:

• VM: Input from the single-ended D- line
• VP: Input from the single-ended D+ line
• RCV: Input from the differential receiver
• VMO: Output to the differential line driver
• VPO: Output to the differential line driver
• UOE: Output enable

The VPO and VMO signals are outputs from the SIE to the external transceiver. The RCV signal is the output from the external transceiver to the SIE; it represents the differential signals from the serial bus translated into a single pulse train. The VM and VP signals are used to report conditions on the serial bus to the SIE that can’t be captured with the RCV signal. The combinations of states of these signals and their interpretation are listed in Table 17-1 and Table 17-2.

TABLE 17-1: DIFFERENTIAL OUTPUTS TO TRANSCEIVER

TABLE 17-2: SINGLE-ENDED INPUTS FROM TRANSCEIVER

The UOE signal toggles the state of the external transceiver. This line is pulled low by the device to enable the transmission of data from the SIE to an external device.

17.2.2.3 Internal Pull-up Resistors

The PIC18FX455/X550 devices have built-in pull-up resistors designed to meet the requirements for low-speed and full-speed USB. The UPEN bit (UCFG<4>) enables the internal pull-ups. Figure 17-1 shows the pull-ups and their control.

17.2.2.4 External Pull-up Resistors

External pull-up may also be used if the internal resistors are not used. The VUSB pin may be used to pull up D+ or D-. The pull-up resistor must be 1.5 kΩ (±5%) as required by the USB specifications. Figure 17-3 shows an example.

FIGURE 17-3: EXTERNAL CIRCUITRY

Note: The above setting shows a typical connection for a full-speed configuration using an on-chip regulator and an external pull-up resistor.

17.2.2.5 Ping-Pong Buffer Configuration

The usage of ping-pong buffers is configured using the PPB1:PPB0 bits. Refer to Section 17.4.4 “Ping-Pong Buffering” for a complete explanation of the ping-pong buffers.

17.2.2.6 USB Output Enable Monitor

The USB OE monitor provides indication as to whether the SIE is listening to the bus or actively driving the bus. This is enabled by default when using an external transceiver or when UCFG<6> = 1.

The USB OE monitoring is useful for initial system debugging, as well as scope triggering during eye pattern generation tests.

17.2.2.7 Eye Pattern Test Enable

An automatic eye pattern test can be generated by the module when the UCFG<7> bit is set. The eye pattern output will be observable based on module settings, meaning that the user is first responsible for configuring the SIE clock settings, pull-up resistor and Transceiver mode. In addition, the module has to be enabled.

Once UTEYE is set, the module emulates a switch from a receive to transmit state and will start transmitting a J-K-J-K bit sequence (K-J-K-J for full speed). The sequence will be repeated indefinitely while the Eye Pattern Test mode is enabled.

Note that this bit should never be set while the module is connected to an actual USB system. This test mode is intended for board verification to aid with USB certification tests. It is intended to show a system developer the noise integrity of the USB signals which can be affected by board traces, impedance mismatches and proximity to other system components. It does not properly test the transition from a receive to a transmit state. Although the eye pattern is not meant to replace the more complex USB certification test, it should aid during first order system debugging.

17.2.2.8 Internal Regulator

The PIC18FX455/X550 devices have a built-in 3.3V regulator to provide power to the internal transceiver and provide a source for the internal/external pull-ups. An external 220 nF (±20%) capacitor is required for stability.

Note: The drive from VUSB is sufficient to only drive an external pull-up in addition to the internal transceiver.

The regulator can be enabled or disabled through the VREGEN Configuration bit. When enabled, the voltage is visible on pin VUSB whenever the USBEN bit is also set. When the regulator is disabled (VREGEN = 0), a 3.3V source must be provided through the VUSB pin for the internal transceiver.

Note 1: Do not enable the internal regulator if an external regulator is connected to VUSB. 2: VDD must be equal to or greater than VUSB at all times, even with the regulator disabled.

17.2.3 USB STATUS REGISTER (USTAT)

The USB Status register reports the transaction status within the SIE. When the SIE issues a USB transfer complete interrupt, USTAT should be read to determine the status of the transfer. USTAT contains the transfer endpoint number, direction and Ping-Pong Buffer Pointer value (if used).

Note: The data in the USB Status register is valid only when the TRNIF interrupt flag is asserted.

The USTAT register is actually a read window into a four-byte status FIFO, maintained by the SIE. It allows the microcontroller to process one transfer while the SIE processes additional endpoints (Figure 17-4). When the SIE completes using a buffer for reading or writing data, it updates the USTAT register. If another USB transfer is performed before a transaction complete interrupt is serviced, the SIE will store the status of the next transfer into the status FIFO.

Clearing the transfer complete flag bit, TRNIF, causes the SIE to advance the FIFO. If the next data in the FIFO holding register is valid, the SIE will reassert the interrupt within 5 TCY of clearing TRNIF. If no additional data is present, TRNIF will remain clear; USTAT data will no longer be reliable.

Note: If an endpoint request is received while the USTAT FIFO is full, the SIE will automatically issue a NAK back to the host.

FIGURE 17-4: USTAT FIFO

DS39632E-page 170 © 2009 Microchip Technology Inc.

REGISTER 17-3: USTAT: USB STATUS REGISTER

bit 7 Unimplemented: Read as ‘0’ bit 6-3 ENDP3:ENDP0: Encoded Number of Last Endpoint Activity bits (represents the number of the BDT updated by the last USB transfer) 1111 = Endpoint 15 1110 = Endpoint 14

• ........ 0001 = Endpoint 1 0000 = Endpoint 0 bit 2 DIR: Last BD Direction Indicator bit 1 = The last transaction was an IN token 0 = The last transaction was an OUT or SETUP token bit 1 PPBI: Ping-Pong BD Pointer Indicator bit(1) 1 = The last transaction was to the Odd BD bank 0 = The last transaction was to the Even BD bank bit 0 Unimplemented: Read as ‘0’

Note 1: This bit is only valid for endpoints with available Even and Odd BD registers.

17.2.4 USB ENDPOINT CONTROL

Each of the 16 possible bidirectional endpoints has its own independent control register, UEPn (where ‘n’ represents the endpoint number). Each register has an identical complement of control bits. The prototype is shown in Register 17-4.

The EPHSHK bit (UEPn<4>) controls handshaking for the endpoint; setting this bit enables USB handshaking. Typically, this bit is always set except when using isochronous endpoints.

The EPCONDIS bit (UEPn<3>) is used to enable or disable USB control operations (SETUP) through the endpoint. Clearing this bit enables SETUP transactions. Note that the corresponding EPINEN and EPOUTEN bits must be set to enable IN and OUT transactions. For Endpoint 0, this bit should always be cleared since the USB specifications identify Endpoint 0 as the default control endpoint.

The EPOUTEN bit (UEPn<2>) is used to enable or disable USB OUT transactions from the host. Setting this bit enables OUT transactions. Similarly, the EPINEN bit (UEPn<1>) enables or disables USB IN transactions from the host.

The EPSTALL bit (UEPn<0>) is used to indicate a STALL condition for the endpoint. If a STALL is issued on a particular endpoint, the EPSTALL bit for that endpoint pair will be set by the SIE. This bit remains set until it is cleared through firmware, or until the SIE is reset.

REGISTER 17-4: UEPn: USB ENDPOINT n CONTROL REGISTER (UEP0 THROUGH UEP15)

Legend:

R = Readable bit
W = Writable bit
U = Unimplemented bit, read as ‘0’
-n = Value at POR
‘1’ = Bit is set
‘0’ = Bit is cleared
x = Bit is unknown

• bit 7-5 Unimplemented: Read as ‘0’
• bit 4 EPHSHK: Endpoint Handshake Enable bit
  1 = Endpoint handshake enabled
  0 = Endpoint handshake disabled (typically used for isochronous endpoints)
• bit 3 EPCONDIS: Bidirectional Endpoint Control bit
  If EPOUTEN = 1 and EPINEN = 1:
  1 = Disable Endpoint n from control transfers; only IN and OUT transfers allowed
  0 = Enable Endpoint n for control (SETUP) transfers; IN and OUT transfers also allowed
• bit 2 EPOUTEN: Endpoint Output Enable bit
  1 = Endpoint n output enabled
  0 = Endpoint n output disabled
• bit 1 EPINEN: Endpoint Input Enable bit
  1 = Endpoint n input enabled
  0 = Endpoint n input disabled
• bit 0 EPSTALL: Endpoint Stall Indicator bit
  1 = Endpoint n has issued one or more STALL packets
  0 = Endpoint n has not issued any STALL packets

17.2.5 USB ADDRESS REGISTER (UADDR)

The USB Address register contains the unique USB address that the peripheral will decode when active. UADDR is reset to 00h when a USB Reset is received, indicated by URSTIF, or when a Reset is received from the microcontroller. The USB address must be written by the microcontroller during the USB setup phase (enumeration) as part of the Microchip USB firmware support.

17.2.6 USB FRAME NUMBER REGISTERS (UFRMH:UFRML)

The Frame Number registers contain the 11-bit frame number. The low-order byte is contained in UFRML, while the three high-order bits are contained in UFRMH. The register pair is updated with the current frame number whenever a SOF token is received. For the microcontroller, these registers are read-only. The Frame Number register is primarily used for isochronous transfers.

17.3 USB RAM

USB data moves between the microcontroller core and the SIE through a memory space known as the USB RAM. This is a special dual port memory that is mapped into the normal data memory space in Banks 4 through 7 (400h to 7FFh) for a total of 1 Kbyte (Figure 17-5).

Bank 4 (400h through 4FFh) is used specifically for endpoint buffer control, while Banks 5 through 7 are available for USB data. Depending on the type of buffering being used, all but 8 bytes of Bank 4 may also be available for use as USB buffer space.

Although USB RAM is available to the microcontroller as data memory, the sections that are being accessed by the SIE should not be accessed by the microcontroller. A semaphore mechanism is used to determine the access to a particular buffer at any given time. This is discussed in Section 17.4.1.1 “Buffer Ownership”.

FIGURE 17-5: IMPLEMENTATION OF USB RAM IN DATA MEMORY SPACE

17.4 Buffer Descriptors and the Buffer Descriptor Table

The registers in Bank 4 are used specifically for endpoint buffer control in a structure known as the Buffer Descriptor Table (BDT). This provides a flexible method for users to construct and control endpoint buffers of various lengths and configuration.

The BDT is composed of Buffer Descriptors (BD) which are used to define and control the actual buffers in the USB RAM space. Each BD, in turn, consists of four registers, where n represents one of the 64 possible BDs (range of 0 to 63):

• BDnSTAT: BD Status register
• BDnCNT: BD Byte Count register
• BDnADRL: BD Address Low register
• BDnADRH: BD Address High register

BDs always occur as a four-byte block in the sequence, BDnSTAT:BDnCNT:BDnADRL:BDnADRH. The address of BDnSTAT is always an offset of (4n − 1) (in hexadecimal) from 400h, with n being the buffer descriptor number.

Depending on the buffering configuration used (Section 17.4.4 “Ping-Pong Buffering”), there are up to 32, 33 or 64 sets of buffer descriptors. At a minimum, the BDT must be at least 8 bytes long. This is because the USB specification mandates that every device must have Endpoint 0 with both input and output for initial setup. Depending on the endpoint and buffering configuration, the BDT can be as long as 256 bytes.

Although they can be thought of as Special Function Registers, the Buffer Descriptor Status and Address registers are not hardware mapped, as conventional microcontroller SFRs in Bank 15 are. If the endpoint corresponding to a particular BD is not enabled, its registers are not used. Instead of appearing as unimplemented addresses, however, they appear as available RAM. Only when an endpoint is enabled by setting the UEPn<1> bit does the memory at those addresses become functional as BD registers. As with any address in the data memory space, the BD registers have an indeterminate value on any device Reset.

An example of a BD for a 64-byte buffer, starting at 500h, is shown in Figure 17-6. A particular set of BD registers is only valid if the corresponding endpoint has been enabled using the UEPn register. All BD registers are available in USB RAM. The BD for each endpoint should be set up prior to enabling the endpoint.

17.4.1 BD STATUS AND CONFIGURATION

Buffer descriptors not only define the size of an endpoint buffer, but also determine its configuration and control. Most of the configuration is done with the BD Status register, BDnSTAT. Each BD has its own unique and correspondingly numbered BDnSTAT register.

FIGURE 17-6: EXAMPLE OF A BUFFER DESCRIPTOR

Note: Memory regions not to scale.

Unlike other control registers, the bit configuration for the BDnSTAT register is context sensitive. There are two distinct configurations, depending on whether the microcontroller or the USB module is modifying the BD and buffer at a particular time. Only three bit definitions are shared between the two.

17.4.1.1 Buffer Ownership

Because the buffers and their BDs are shared between the CPU and the USB module, a simple semaphore mechanism is used to distinguish which is allowed to update the BD and associated buffers in memory.

This is done by using the UOWN bit (BDnSTAT<7>) as a semaphore to distinguish which is allowed to update the BD and associated buffers in memory. UOWN is the only bit that is shared between the two configurations of BDnSTAT.

When UOWN is clear, the BD entry is “owned” by the microcontroller core. When the UOWN bit is set, the BD entry and the buffer memory are “owned” by the USB peripheral. The core should not modify the BD or its corresponding data buffer during this time. Note that the microcontroller core can still read BDnSTAT while the SIE owns the buffer and vice versa.

The buffer descriptors have a different meaning based on the source of the register update. Prior to placing ownership with the USB peripheral, the user can configure the basic operation of the peripheral through the BDnSTAT bits. During this time, the byte count and buffer location registers can also be set.

When UOWN is set, the user can no longer depend on the values that were written to the BDs. From this point, the SIE updates the BDs as necessary, overwriting the original BD values. The BDnSTAT register is updated by the SIE with the token PID and the transfer count, BDnCNT, is updated.

The BDnSTAT byte of the BDT should always be the last byte updated when preparing to arm an endpoint. The SIE will clear the UOWN bit when a transaction has completed. The only exception to this is when KEN is enabled and/or BSTALL is enabled.

No hardware mechanism exists to block access when the UOWN bit is set. Thus, unexpected behavior can occur if the microcontroller attempts to modify memory when the SIE owns it. Similarly, reading such memory may produce inaccurate data until the USB peripheral returns ownership to the microcontroller.

17.4.1.2 BDnSTAT Register (CPU Mode)

When UOWN = 0, the microcontroller core owns the BD. At this point, the other seven bits of the register take on control functions.

The Keep Enable bit, KEN (BDnSTAT<5>), determines if a BD stays enabled. If the bit is set, once the UOWN bit is set, it will remain owned by the SIE independent of the endpoint activity. This prevents the USTAT FIFO from being updated, as well as the transaction complete interrupt from being set for the endpoint. This feature should only be enabled when the Streaming Parallel Port is selected as the data I/O channel instead of USB RAM.

The Address Increment Disable bit, INCDIS (BDnSTAT<4>), controls the SIE’s automatic address increment function. Setting INCDIS disables the auto-increment of the buffer address by the SIE for each byte transmitted or received. This feature should only be enabled when using the Streaming Parallel Port, where each data byte is processed to or from the same memory location.

The Data Toggle Sync Enable bit, DTSEN (BDnSTAT<3>), controls data toggle parity checking. Setting DTSEN enables data toggle synchronization by the SIE. When enabled, it checks the data packet’s parity against the value of DTS (BDnSTAT<6>). If a packet arrives with an incorrect synchronization, the data will essentially be ignored. It will not be written to the USB RAM and the USB transfer complete interrupt flag will not be set. The SIE will send an ACK token back to the host to Acknowledge receipt, however. The effects of the DTSEN bit on the SIE are summarized in Table 17-3.

The Buffer Stall bit, BSTALL (BDnSTAT<2>), provides support for control transfers, usually one-time stalls on Endpoint 0. It also provides support for the SET_FEATURE/CLEAR_FEATURE commands specified in Chapter 9 of the USB specification; typically, continuous STALLs to any endpoint other than the default control endpoint.

The BSTALL bit enables buffer stalls. Setting BSTALL causes the SIE to return a STALL token to the host if a received token would use the BD in that location. The EPSTALL bit in the corresponding UEPn control register is set and a STALL interrupt is generated when a STALL is issued to the host. The UOWN bit remains set and the BDs are not changed unless a SETUP token is received. In this case, the STALL condition is cleared and the ownership of the BD is returned to the microcontroller core.

The BD9:BD8 bits (BDnSTAT<1:0>) store the two most significant digits of the SIE byte count; the lower 8 digits are stored in the corresponding BDnCNT register. See Section 17.4.2 “BD Byte Count” for more information.

TABLE 17-3: EFFECT OF DTSEN BIT ON ODD/EVEN (DATA0/DATA1) PACKET RECEPTION

Legend: x = don’t care

REGISTER 17-5: BDnSTAT: BUFFER DESCRIPTOR n STATUS REGISTER (BD0STAT THROUGH BD63STAT), CPU MODE (DATA IS WRITTEN TO THE SIDE)

Legend:

R = Readable bit
W = Writable bit
U = Unimplemented bit, read as ‘0’
-n = Value at POR
‘1’ = Bit is set
‘0’ = Bit is cleared
x = Bit is unknown

bit 7
UOWN: USB Own bit⁽¹⁾
0 = The microcontroller core owns the BD and its corresponding buffer

bit 6
DTS: Data Toggle Synchronization bit⁽²⁾
1 = Data 1 packet
0 = Data 0 packet

bit 5
KEN: BD Keep Enable bit
1 = USB will keep the BD indefinitely once UOWN is set (required for SPP endpoint configuration)
0 = USB will hand back the BD once a token has been processed

bit 4
INCDIS: Address Increment Disable bit
1 = Address increment disabled (required for SPP endpoint configuration)
0 = Address increment enabled

bit 3
DTSEN: Data Toggle Synchronization Enable bit
1 = Data toggle synchronization is enabled; data packets with incorrect Sync value will be ignored except for a SETUP transaction, which is accepted even if the data toggle bits do not match
0 = No data toggle synchronization is performed

bit 2
BSTALL: Buffer Stall Enable bit
1 = Buffer stall enabled; STALL handshake issued if a token is received that would use the BD in the given location (UOWN bit remains set, BD value is unchanged)
0 = Buffer stall disabled

bit 1-0
BC9:BC8: Byte Count 9 and 8 bits
The byte count bits represent the number of bytes that will be transmitted for an IN token or received during an OUT token. Together with BC<7:0>, the valid byte counts are 0-1023.

Note 1: This bit must be initialized by the user to the desired value prior to enabling the USB module.
Note 2: This bit is ignored unless DTSEN = 1.

17.4.1.3 BDnSTAT Register (SIE Mode)

When the BD and its buffer are owned by the SIE, most of the bits in BDnSTAT take on a different meaning. The configuration is shown in Register 17-6. Once UOWN is set, any data or control settings previously written there by the user will be overwritten with data from the SIE.

The BDnSTAT register is updated by the SIE with the token Packet Identifier (PID) which is stored in BDnSTAT<5:3>. The transfer count in the corresponding BDnCNT register is updated. Values that overflow the 8-bit register carry over to the two most significant digits of the count, stored in BDnSTAT<1:0>.

17.4.2 BD BYTE COUNT

The byte count represents the total number of bytes that will be transmitted during an IN transfer. After an IN transfer, the SIE will return the number of bytes sent to the host.

For an OUT transfer, the byte count represents the maximum number of bytes that can be received and stored in USB RAM. After an OUT transfer, the SIE will return the actual number of bytes received. If the number of bytes received exceeds the corresponding byte count, the data packet will be rejected and a NAK handshake will be generated. When this happens, the byte count will not be updated.

The 10-bit byte count is distributed over two registers. The lower 8 bits of the count reside in the BDnCNT register. The upper two bits reside in BDnSTAT<1:0>. This represents a valid byte range of 0 to 1023.

17.4.3 BD ADDRESS VALIDATION

The BD Address register pair contains the starting RAM address location for the corresponding endpoint buffer. For an endpoint starting location to be valid, it must fall in the range of the USB RAM, 400h to 7FFh. No mechanism is available in hardware to validate the BD address.

If the value of the BD address does not point to an address in the USB RAM, or if it points to an address within another endpoint’s buffer, data is likely to be lost or overwritten. Similarly, overlapping a receive buffer (OUT endpoint) with a BD location in use can yield unexpected results. When developing USB applications, the user may want to consider the inclusion of software-based address validation in their code.

REGISTER 17-6: BDnSTAT: BUFFER DESCRIPTOR n STATUS REGISTER (BD0STAT THROUGH BD63STAT), SIE MODE (DATA RETURNED BY THE SIDE TO THE MICROCONTROLLER)

Legend:

• bit 7
  UOWN: USB Own bit
  1 = The SIE owns the BD and its corresponding buffer

• bit 6
  Reserved: Not written by the SIE

• bit 5-2
  PID3:PID0: Packet Identifier bits
  The received token PID value of the last transfer (IN, OUT or SETUP transactions only).

• bit 1-0
  BC9:BC8: Byte Count 9 and 8 bits
  These bits are updated by the SIE to reflect the actual number of bytes received on an OUT transfer and the actual number of bytes transmitted on an IN transfer.

17.4.4 PING-PONG BUFFERING

An endpoint is defined to have a ping-pong buffer when it has two sets of BD entries: one set for an Even transfer and one set for an Odd transfer. This allows the CPU to process one BD while the SIE is processing the other BD. Double-buffering BDs in this way allows for maximum throughput to/from the USB.

The USB module supports four modes of operation:

• No ping-pong support
• Ping-pong buffer support for OUT Endpoint 0 only
• Ping-pong buffer support for all endpoints
• Ping-pong buffer support for all other Endpoints except Endpoint 0

The ping-pong buffer settings are configured using the PPB1:PPB0 bits in the UCFG register.

The USB module keeps track of the Ping-Pong Pointer individually for each endpoint. All pointers are initially reset to the Even BD when the module is enabled. After the completion of a transaction (UOWN cleared by the SIE), the pointer is toggled to the Odd BD. After the completion of the next transaction, the pointer is toggled back to the Even BD and so on.

The Even/Odd status of the last transaction is stored in the PPBI bit of the USTAT register. The user can reset all Ping-Pong Pointers to Even using the PPBRST bit.

Figure 17-7 shows the four different modes of operation and how USB RAM is filled with the BDs.

BDs have a fixed relationship to a particular endpoint, depending on the buffering configuration. The mapping of BDs to endpoints is detailed in Table 17-4. This relationship also means that gaps may occur in the BDT if endpoints are not enabled contiguously. This theoretically means that the BDs for disabled endpoints could be used as buffer space. In practice, users should avoid using such spaces in the BDT unless a method of validating BD addresses is implemented.

FIGURE 17-7: BUFFER DESCRIPTOR TABLE MAPPING FOR BUFFERING MODES

Note: Memory area not shown to scale.

DS39632E-page 178 © 2009 Microchip Technology Inc.

TABLE 17-4: ASSIGNMENT OF BUFFER DESCRIPTORS FOR THE DIFFERENT BUFFERING MODES

\begin{tabular}{|c|c|c|c|c|c|c|c|c|} \hline \multicolumn{1}{|c|}{} & \multicolumn{8}{c|}{BDs Assigned to Endpoint} \ \cline{2-9} \multicolumn{1}{|c|}{Endpoint} & \multicolumn{2}{c|}{Mode 0} & \multicolumn{2}{c|}{Mode 1} & \multicolumn{2}{c|}{Mode 2} & \multicolumn{2}{c|}{Mode 3} \ \multicolumn{1}{|c|}{} & \multicolumn{2}{c|}{(No Ping-Pong)} & \multicolumn{2}{c|}{(Ping-Pong on EP0 OUT)} & \multicolumn{2}{c|}{(Ping-Pong on all EPs)} & \multicolumn{2}{c|}{(Ping-Pong on all other EPs, except EP0)} \ \cline{2-9} \multicolumn{1}{|c|}{} & Out & In & Out & In & Out & In & Out & In \ \hline 0 & 0 & 1 & 0 (E), 1 (O) & 2 & 0 (E), 1 (O) & 2 (E), 3 (O) & 0 & 1 \ \hline 1 & 2 & 3 & 3 & 4 & 4 (E), 5 (O) & 6 (E), 7 (O) & 2 (E), 3 (O) & 4 (E), 5 (O) \ \hline 2 & 4 & 5 & 5 & 6 & 8 (E), 9 (O) & 10 (E), 11 (O) & 6 (E), 7 (O) & 8 (E), 9 (O) \ \hline 3 & 6 & 7 & 7 & 8 & 12 (E), 13 (O) & 14 (E), 15 (O) & 10 (E), 11 (O) & 12 (E), 13 (O) \ \hline 4 & 8 & 9 & 9 & 10 & 16 (E), 17 (O) & 18 (E), 19 (O) & 14 (E), 15 (O) & 16 (E), 17 (O) \ \hline 5 & 10 & 11 & 11 & 12 & 20 (E), 21 (O) & 22 (E), 23 (O) & 18 (E), 19 (O) & 20 (E), 21 (O) \ \hline 6 & 12 & 13 & 13 & 14 & 24 (E), 25 (O) & 26 (E), 27 (O) & 22 (E), 23 (O) & 24 (E), 25 (O) \ \hline 7 & 14 & 15 & 15 & 16 & 28 (E), 29 (O) & 30 (E), 31 (O) & 26 (E), 27 (O) & 28 (E), 29 (O) \ \hline 8 & 16 & 17 & 17 & 18 & 32 (E), 33 (O) & 34 (E), 35 (O) & 30 (E), 31 (O) & 32 (E), 33 (O) \ \hline 9 & 18 & 19 & 19 & 20 & 36 (E), 37 (O) & 38 (E), 39 (O) & 34 (E), 35 (O) & 36 (E), 37 (O) \ \hline 10 & 20 & 21 & 21 & 22 & 40 (E), 41 (O) & 42 (E), 43 (O) & 38 (E), 39 (O) & 40 (E), 41 (O) \ \hline 11 & 22 & 23 & 23 & 24 & 44 (E), 45 (O) & 46 (E), 47 (O) & 42 (E), 43 (O) & 44 (E), 45 (O) \ \hline 12 & 24 & 25 & 25 & 26 & 48 (E), 49 (O) & 50 (E), 51 (O) & 46 (E), 47 (O) & 48 (E), 49 (O) \ \hline 13 & 26 & 27 & 27 & 28 & 52 (E), 53 (O) & 54 (E), 55 (O) & 50 (E), 51 (O) & 52 (E), 53 (O) \ \hline 14 & 28 & 29 & 29 & 30 & 56 (E), 57 (O) & 58 (E), 59 (O) & 54 (E), 55 (O) & 56 (E), 57 (O) \ \hline 15 & 30 & 31 & 31 & 32 & 60 (E), 61 (O) & 62 (E), 63 (O) & 58 (E), 59 (O) & 60 (E), 61 (O) \ \hline \end{tabular}

Legend: (E) = Even transaction buffer, (O) = Odd transaction buffer

TABLE 17-5: SUMMARY OF USB BUFFER DESCRIPTOR TABLE REGISTERS

\begin{tabular}{|l|c|c|c|c|c|c|c|c|} \hline Name & Bit 7 & Bit 6 & Bit 5 & Bit 4 & Bit 3 & Bit 2 & Bit 1 & Bit 0 \ \hline BDnSTAT$^{(1)}$ & UOWN & DTS$^{(4)}$ & PID3$^{(2)}$ KEN$^{(3)}$ & PID2$^{(2)}$ INCDIS$^{(3)}$ & PID1$^{(2)}$ DTSEN$^{(3)}$ & PID0$^{(2)}$ BSTALL$^{(3)}$ & BC9 & BC8 \ \hline BDnCNT$^{(1)}$ & Byte Count & & & & & & & \ \hline BDnADRL$^{(1)}$ & Buffer Address Low & & & & & & & \ \hline BDnADRH$^{(1)}$ & Buffer Address High & & & & & & & \ \hline \end{tabular}

Note 1: For buffer descriptor registers, n may have a value of 0 to 63. For the sake of brevity, all 64 registers are shown as one generic prototype. All registers have indeterminate Reset values (xxxx xxxx). 2: Bits 5 through 2 of the BDnSTAT register are used by the SIE to return PID3:PID0 values once the register is turned over to the SIE (UOWN bit is set). Once the registers have been under SIE control, the values written for KEN, INCDIS, DTSEN and BSTALL are no longer valid. 3: Prior to turning the buffer descriptor over to the SIE (UOWN bit is cleared), bits 5 through 2 of the BDnSTAT register are used to configure the KEN, INCDIS, DTSEN and BSTALL settings. 4: This bit is ignored unless DTSEN = 1.

17.5 USB Interrupts

The USB module can generate multiple interrupt conditions. To accommodate all of these interrupt sources, the module is provided with its own interrupt logic structure, similar to that of the microcontroller. USB interrupts are enabled with one set of control registers and trapped with a separate set of flag registers. All sources are funneled into a single USB interrupt request, USBIF (PIR2<5>), in the microcontroller's interrupt logic.

Figure 17-8 shows the interrupt logic for the USB module. There are two layers of interrupt registers in the USB module. The top level consists of overall USB status interrupts; these are enabled and flagged in the UIE and UIR registers, respectively. The second level consists of USB error conditions, which are enabled and flagged in the UEIR and UEIE registers. An interrupt condition in any of these triggers a USB Error Interrupt Flag (UERRIF) in the top level.

Interrupts may be used to trap routine events in a USB transaction. Figure 17-9 shows some common events within a USB frame and their corresponding interrupts.

FIGURE 17-8: USB INTERRUPT LOGIC FUNNEL

Second Level USB Interrupts (USB Error Conditions) UEIR (Flag) and UEIE (Enable) Registers

Top Level USB Interrupts (USB Status Interrupts) UIR (Flag) and UIE (Enable) Registers

BTSEF BTSEE BTOEF BTOEE DFN8EF DFN8EE CRC16EF CRC16EE CRC5EF CRC5EE PIDEF PIDEE

SOFIF SOFIE TRNIF TRNIE IDLEIF IDLEIE UERRIF UERRIE STALLIF STALLIE ACTVIF ACTVIE URSTIF URSTIE

USBIF

FIGURE 17-9: EXAMPLE OF A USB TRANSACTION AND INTERRUPT EVENTS

From Host From Host To Host SETUP Token Data ACK Set TRNIF

From Host To Host From Host IN Token Data ACK Set TRNIF

From Host From Host To Host OUT Token Empty Data ACK Set TRNIF Transaction Transaction Complete

USB Reset URSTIF

Start-Of-Frame SOFIF

RESET SOF SETUP DATA STATUS SOF Differential Data Control Transfer(1) 1 ms Frame

Note 1: The control transfer shown here is only an example showing events that can occur for every transaction. Typical control transfers will spread across multiple frames.

17.5.1 USB INTERRUPT STATUS REGISTER (UIR)

The USB Interrupt Status register (Register 17-7) contains the flag bits for each of the USB status interrupt sources. Each of these sources has a corresponding interrupt enable bit in the UIE register. All of the USB status flags are ORed together to generate the USBIF interrupt flag for the microcontroller’s interrupt funnel.

Once an interrupt bit has been set by the SIE, it must be cleared by software by writing a ‘0’. The flag bits can also be set in software which can aid in firmware debugging.

When the USB module is in the Low-Power Suspend mode (UCON<1> = 1), the SIE does not get clocked. When in this state, the SIE cannot process packets, and therefore, cannot detect new interrupt conditions other than the Activity Detect Interrupt, ACTVIF. The ACTVIF bit is typically used by USB firmware to detect when the microcontroller should bring the USB module out of the Low-Power Suspend mode (UCON<1> = 0).

REGISTER 17-7: UIR: USB INTERRUPT STATUS REGISTER

Legend:

R = Readable bit
W = Writable bit
U = Unimplemented bit, read as ‘0’
-n = Value at POR
‘1’ = Bit is set
‘0’ = Bit is cleared
x = Bit is unknown

• bit 7 Unimplemented: Read as ‘0’
• bit 6 SOFIF: Start-Of-Frame Token Interrupt bit
  1 = A Start-Of-Frame token received by the SIE
  0 = No Start-Of-Frame token received by the SIE
• bit 5 STALLIF: A STALL Handshake Interrupt bit
  1 = A STALL handshake was sent by the SIE
  0 = A STALL handshake has not been sent
• bit 4 IDLEIF: Idle Detect Interrupt bit(1)
  1 = Idle condition detected (constant Idle state of 3 ms or more)
  0 = No Idle condition detected
• bit 3 TRNIF: Transaction Complete Interrupt bit(2)
  1 = Processing of pending transaction is complete; read USTAT register for endpoint information
  0 = Processing of pending transaction is not complete or no transaction is pending
• bit 2 ACTVIF: Bus Activity Detect Interrupt bit(3)
  1 = Activity on the D+/D- lines was detected
  0 = No activity detected on the D+/D- lines
• bit 1 UERRIF: USB Error Condition Interrupt bit(4)
  1 = An unmasked error condition has occurred
  0 = No unmasked error condition has occurred.
• bit 0 URSTIF: USB Reset Interrupt bit
  1 = Valid USB Reset occurred; 00h is loaded into UADDR register
  0 = No USB Reset has occurred

Note 1: Once an Idle state is detected, the user may want to place the USB module in Suspend mode.
2: Clearing this bit will cause the USTAT FIFO to advance (valid only for IN, OUT and SETUP tokens).
3: This bit is typically unmasked only following the detection of a UIDLE interrupt event.
4: Only error conditions enabled through the UEIE register will set this bit. This bit is a status bit only and cannot be set or cleared by the user.

17.5.1.1 Bus Activity Detect Interrupt Bit (ACTVIF)

The ACTVIF bit cannot be cleared immediately after the USB module wakes up from Suspend or while the USB module is suspended. A few clock cycles are required to synchronize the internal hardware state machine before the ACTVIF bit can be cleared by firmware. Clearing the ACTVIF bit before the internal hardware is synchronized may not have an effect on the value of ACTVIF. Additionally, if the USB module uses the clock from the 96 MHz PLL source, then after clearing the SUSPND bit, the USB module may not be immediately operational while waiting for the 96 MHz PLL to lock. The application code should clear the ACTVIF flag as shown in Example 17-1.

Note: Only one ACTVIF interrupt is generated when resuming from the USB bus Idle condition. If user firmware clears the ACTVIF bit, the bit will not immediately become set again, even when there is continuous bus traffic. Bus traffic must cease long enough to generate another IDLEIF condition before another ACTVIF interrupt can be generated.

EXAMPLE 17-1: CLEARING ACTVIF BIT (UIR<2>)

Assembly: BCF UCON, SUSPND

Loop: BCF UIR, ACTVIF BTFSC UIR, ACTVIF BRA Loop Done:

C: UCONbits.SUSPND = 0; while (UIRbits.ACTVIF) { UIRbits.ACTVIF = 0; }

17.5.2 USB INTERRUPT ENABLE REGISTER (UIE)

The USB Interrupt Enable register (Register 17-8) contains the enable bits for the USB status interrupt sources. Setting any of these bits will enable the respective interrupt source in the UIR register.

The values in this register only affect the propagation of an interrupt condition to the microcontroller’s interrupt logic. The flag bits are still set by their interrupt conditions, allowing them to be polled and serviced without actually generating an interrupt.

REGISTER 17-8: UIE: USB INTERRUPT ENABLE REGISTER

bit 7 Unimplemented: Read as ‘0’ bit 6 SOFIE: Start-Of-Frame Token Interrupt Enable bit 1 = Start-Of-Frame token interrupt enabled 0 = Start-Of-Frame token interrupt disabled bit 5 STALLIE: STALL Handshake Interrupt Enable bit 1 = STALL interrupt enabled 0 = STALL interrupt disabled bit 4 IDLEIE: Idle Detect Interrupt Enable bit 1 = Idle detect interrupt enabled 0 = Idle detect interrupt disabled bit 3 TRNIE: Transaction Complete Interrupt Enable bit 1 = Transaction interrupt enabled 0 = Transaction interrupt disabled bit 2 ACTVIE: Bus Activity Detect Interrupt Enable bit 1 = Bus activity detect interrupt enabled 0 = Bus activity detect interrupt disabled bit 1 UERRIE: USB Error Interrupt Enable bit 1 = USB error interrupt enabled 0 = USB error interrupt disabled bit 0 URSTIE: USB Reset Interrupt Enable bit 1 = USB Reset interrupt enabled 0 = USB Reset interrupt disabled

17.5.3 USB ERROR INTERRUPT STATUS REGISTER (UEIR)

The USB Error Interrupt Status register (Register 17-9) contains the flag bits for each of the error sources within the USB peripheral. Each of these sources is controlled by a corresponding interrupt enable bit in the UEIE register. All of the USB error flags are ORed together to generate the USB Error Interrupt Flag (UERRIF) at the top level of the interrupt logic.

Each error bit is set as soon as the error condition is detected. Thus, the interrupt will typically not correspond with the end of a token being processed.

Once an interrupt bit has been set by the SIE, it must be cleared by software by writing a ‘0’.

REGISTER 17-9: UEIR: USB ERROR INTERRUPT STATUS REGISTER

Legend:

R = Readable bit
C = Clearable bit
U = Unimplemented bit, read as ‘0’
-n = Value at POR
‘1’ = Bit is set
‘0’ = Bit is cleared
x = Bit is unknown

bit 7
BTSEF: Bit Stuff Error Flag bit
1 = A bit stuff error has been detected
0 = No bit stuff error

bit 6-5
Unimplemented: Read as ‘0’

bit 4
BTOEF: Bus Turnaround Time-out Error Flag bit
1 = Bus turnaround time-out has occurred (more than 16 bit times of Idle from previous EOP elapsed)
0 = No bus turnaround time-out

bit 3
DFN8EF: Data Field Size Error Flag bit
1 = The data field was not an integral number of bytes
0 = The data field was an integral number of bytes

bit 2
CRC16EF: CRC16 Failure Flag bit
1 = The CRC16 failed
0 = The CRC16 passed

bit 1
CRC5EF: CRC5 Host Error Flag bit
1 = The token packet was rejected due to a CRC5 error
0 = The token packet was accepted

bit 0
PIDEF: PID Check Failure Flag bit
1 = PID check failed
0 = PID check passed

17.5.4 USB ERROR INTERRUPT ENABLE REGISTER (UEIE)

The USB Error Interrupt Enable register (Register 17-10) contains the enable bits for each of the USB error interrupt sources. Setting any of these bits will enable the respective error interrupt source in the UEIR register to propagate into the UERR bit at the top level of the interrupt logic.

As with the UIE register, the enable bits only affect the propagation of an interrupt condition to the microcontroller’s interrupt logic. The flag bits are still set by their interrupt conditions, allowing them to be polled and serviced without actually generating an interrupt.

REGISTER 17-10: UEIE: USB ERROR INTERRUPT ENABLE REGISTER

Legend:

R = Readable bit
W = Writable bit
U = Unimplemented bit, read as ‘0’
-n = Value at POR
‘1’ = Bit is set
‘0’ = Bit is cleared
x = Bit is unknown

• bit 7
  BTSEE: Bit Stuff Error Interrupt Enable bit
  1 = Bit stuff error interrupt enabled
  0 = Bit stuff error interrupt disabled

• bit 6-5
  Unimplemented: Read as ‘0’

• bit 4
  BTOEE: Bus Turnaround Time-out Error Interrupt Enable bit
  1 = Bus turnaround time-out error interrupt enabled
  0 = Bus turnaround time-out error interrupt disabled

• bit 3
  DFN8EE: Data Field Size Error Interrupt Enable bit
  1 = Data field size error interrupt enabled
  0 = Data field size error interrupt disabled

• bit 2
  CRC16EE: CRC16 Failure Interrupt Enable bit
  1 = CRC16 failure interrupt enabled
  0 = CRC16 failure interrupt disabled

• bit 1
  CRC5EE: CRC5 Host Error Interrupt Enable bit
  1 = CRC5 host error interrupt enabled
  0 = CRC5 host error interrupt disabled

• bit 0
  PIDEE: PID Check Failure Interrupt Enable bit
  1 = PID check failure interrupt enabled
  0 = PID check failure interrupt disabled

17.6 USB Power Modes

Many USB applications will likely have several different sets of power requirements and configuration. The most common power modes encountered are Bus Power Only, Self-Power Only and Dual Power with Self-Power Dominance. The most common cases are presented here.

17.6.1 BUS POWER ONLY

In Bus Power Only mode, all power for the application is drawn from the USB (Figure 17-10). This is effectively the simplest power method for the device.

In order to meet the inrush current requirements of the USB 2.0 specifications, the total effective capacitance appearing across VBUS and ground must be no more than 10 µF. If not, some kind of inrush limiting is required. For more details, see Section 7.2.4 of the USB 2.0 specification.

According to the USB 2.0 specification, all USB devices must also support a Low-Power Suspend mode. In the USB Suspend mode, devices must consume no more than 2.5 mA from the 5V VBUS line of the USB cable.

The host signals the USB device to enter the Suspend mode by stopping all USB traffic to that device for more than 3 ms. This condition will cause the IDLEIF bit in the UIR register to become set.

During the USB Suspend mode, the D+ or D- pull-up resistor must remain active, which will consume some of the allowed suspend current: 2.5 mA budget.

FIGURE 17-10: BUS POWER ONLY

17.6.2 SELF-POWER ONLY

In Self-Power Only mode, the USB application provides its own power, with very little power being pulled from the USB. Figure 17-11 shows an example. Note that an attach indication is added to indicate when the USB has been connected and the host is actively powering VBUS.

In order to meet compliance specifications, the USB module (and the D+ or D- pull-up resistor) should not be enabled until the host actively drives VBus high. One of the I/O pins may be used for this purpose.

The application should never source any current onto the 5V VBUS pin of the USB cable.

FIGURE 17-11: SELF-POWER ONLY

17.6.3 DUAL POWER WITH SELF-POWER DOMINANCE

Some applications may require a dual power option. This allows the application to use internal power primarily, but switch to power from the USB when no internal power is available. Figure 17-12 shows a simple Dual Power with Self-Power Dominance example, which automatically switches between Self-Power Only and USB Bus Power Only modes.

Dual power devices also must meet all of the special requirements for inrush current and Suspend mode current and must not enable the USB module until VBus is driven high. For descriptions of those requirements, see Section 17.6.1 "Bus Power Only" and Section 17.6.2 "Self-Power Only".

Additionally, dual power devices must never source current onto the 5V VBUS pin of the USB cable.

FIGURE 17-12: DUAL POWER EXAMPLE

Note: Users should keep in mind the limits for devices drawing power from the USB. According to USB specification 2.0, this cannot exceed 100 mA per low-power device or 500 mA per high-power device.

17.7 Streaming Parallel Port

The Streaming Parallel Port (SPP) is an alternate route option for data besides USB RAM. Using the SPP, an endpoint can be configured to send data to or receive data directly from external hardware.

This methodology presents design possibilities where the microcontroller acts as a data manager, allowing the SPP to pass large blocks of data without the microcontroller actually processing it. An application example might include a data acquisition system, where data is streamed from an external FIFO through USB to the host computer. In this case, endpoint control is managed by the microcontroller and raw data movement is processed externally.

The SPP is enabled as a USB endpoint port through the associated endpoint buffer descriptor. The endpoint must be enabled as follows:

1. Set BDnADRL:BDnADRH to point to FFFFh.
2. Set the KEN bit (BDnSTAT<5>) to let SIE keep control of the buffer.
3. Set the INCDIS bit (BDnSTAT<4>) to disable automatic address increment.

Refer to Section 18.0 “Streaming Parallel Port” for more information about the SPP.

Note 1: If an endpoint is configured to use the SPP, the SPP module must also be configured to use the USB module. Otherwise, unexpected operation may occur.

2: In addition, if an endpoint is configured to use the SPP, the data transfer type of that endpoint must be isochronous only.

17.8 Oscillator

The USB module has specific clock requirements. For full-speed operation, the clock source must be 48 MHz. Even so, the microcontroller core and other peripherals are not required to run at that clock speed or even from the same clock source. Available clocking options are described in detail in Section 2.3 “Oscillator Settings for USB”.

TABLE 17-6: REGISTERS ASSOCIATED WITH USB MODULE OPERATION(1)

Legend: — = unimplemented, read as ‘0’. Shaded cells are not used by the USB module.

Note 1: This table includes only those hardware mapped SFRs located in Bank 15 of the data memory space. The Buffer Descriptor registers, which are mapped into Bank 4 and are not true SFRs, are listed separately in Table 17-5.

Legend: — = unimplemented, read as ‘0’. Shaded cells are not used by the USB module.

Note 1: This table includes only those hardware mapped SFRs located in Bank 15 of the data memory space. The Buffer Descriptor registers, which are mapped into Bank 4 and are not true SFRs, are listed separately in Table 17-5.

DS39632E-page 188 © 2009 Microchip Technology Inc.

17.10 Overview of USB

This section presents some of the basic USB concepts and useful information necessary to design a USB device. Although much information is provided in this section, there is a plethora of information provided within the USB specifications and class specifications. Thus, the reader is encouraged to refer to the USB specifications for more information (www.usb.org). If you are very familiar with the details of USB, then this section serves as a basic, high-level refresher of USB.

17.10.1 LAYERED FRAMEWORK

USB device functionality is structured into a layered framework graphically shown in Figure 17-13. Each level is associated with a functional level within the device. The highest layer, other than the device, is the configuration. A device may have multiple configurations. For example, a particular device may have multiple power requirements based on Self-Power Only or Bus Power Only modes.

For each configuration, there may be multiple interfaces. Each interface could support a particular mode of that configuration.

Below the interface is the endpoint(s). Data is directly moved at this level. There can be as many as 16 bidirectional endpoints. Endpoint 0 is always a control endpoint and by default, when the device is on the bus, Endpoint 0 must be available to configure the device.

17.10.2 FRAMES

Information communicated on the bus is grouped into 1 ms time slots, referred to as frames. Each frame can contain many transactions to various devices and endpoints. Figure 17-9 shows an example of a transaction within a frame.

17.10.3 TRANSFERS

There are four transfer types defined in the USB specification.

• Isochronous: This type provides a transfer method for large amounts of data (up to 1023 bytes) with timely delivery ensured; however, the data integrity is not ensured. This is good for streaming applications where small data loss is not critical, such as audio.
• Bulk: This type of transfer method allows for large amounts of data to be transferred with ensured data integrity; however, the delivery timeliness is not ensured.
• Interrupt: This type of transfer provides for ensured timely delivery for small blocks of data, plus data integrity is ensured.
• Control: This type provides for device setup control.

While full-speed devices support all transfer types, low-speed devices are limited to interrupt and control transfers only.

17.10.4 POWER

Power is available from the Universal Serial Bus. The USB specification defines the bus power requirements. Devices may either be self-powered or bus powered. Self-powered devices draw power from an external source, while bus powered devices use power supplied from the bus.

FIGURE 17-13: USB LAYERS

The USB specification limits the power taken from the bus. Each device is ensured 100 mA at approximately 5V (one unit load). Additional power may be requested, up to a maximum of 500 mA. Note that power above one unit load is a request and the host or hub is not obligated to provide the extra current. Thus, a device capable of consuming more than one unit load must be able to maintain a low-power configuration of a one unit load or less, if necessary.

The USB specification also defines a Suspend mode. In this situation, current must be limited to 2.5 mA, averaged over 1 second. A device must enter a Suspend state after 3 ms of inactivity (i.e., no SOF tokens for 3 ms). A device entering Suspend mode must drop current consumption within 10 ms after Suspend. Likewise, when signaling a wake-up, the device must signal a wake-up within 10 ms of drawing current above the Suspend limit.

17.10.5 ENUMERATION

When the device is initially attached to the bus, the host enters an enumeration process in an attempt to identify the device. Essentially, the host interrogates the device, gathering information such as power consumption, data rates and sizes, protocol and other descriptive information; descriptors contain this information. A typical enumeration process would be as follows:

1. USB Reset: Reset the device. Thus, the device is not configured and does not have an address (address 0).
2. Get Device Descriptor: The host requests a small portion of the device descriptor.
3. USB Reset: Reset the device again.
4. Set Address: The host assigns an address to the device.
5. Get Device Descriptor: The host retrieves the device descriptor, gathering info such as manufacturer, type of device, maximum control packet size.
6. Get configuration descriptors.
7. Get any other descriptors.
8. Set a configuration.

The exact enumeration process depends on the host.

17.10.6 DESCRIPTORS

There are eight different standard descriptor types of which five are most important for this device.

17.10.6.1 Device Descriptor

The device descriptor provides general information, such as manufacturer, product number, serial number, the class of the device and the number of configurations. There is only one device descriptor.

17.10.6.2 Configuration Descriptor

The configuration descriptor provides information on the power requirements of the device and how many different interfaces are supported when in this configuration. There may be more than one configuration for a device (i.e., low-power and high-power configurations).

17.10.6.3 Interface Descriptor

The interface descriptor details the number of endpoints used in this interface, as well as the class of the interface. There may be more than one interface for a configuration.

17.10.6.4 Endpoint Descriptor

The endpoint descriptor identifies the transfer type (Section 17.10.3 “Transfers”) and direction, as well as some other specifics for the endpoint. There may be many endpoints in a device and endpoints may be shared in different configurations.

17.10.6.5 String Descriptor

Many of the previous descriptors reference one or more string descriptors. String descriptors provide human readable information about the layer (Section 17.10.1 “Layered Framework”) they describe. Often these strings show up in the host to help the user identify the device. String descriptors are generally optional to save memory and are encoded in a unicode format.

17.10.7 BUS SPEED

Each USB device must indicate its bus presence and speed to the host. This is accomplished through a 1.5 kΩ resistor which is connected to the bus at the time of the attachment event.

Depending on the speed of the device, the resistor either pulls up the D+ or D- line to 3.3V. For a low-speed device, the pull-up resistor is connected to the D- line. For a full-speed device, the pull-up resistor is connected to the D+ line.

17.10.8 CLASS SPECIFICATIONS AND DRIVERS

USB specifications include class specifications which operating system vendors optionally support. Examples of classes include Audio, Mass Storage, Communications and Human Interface (HID). In most cases, a driver is required at the host side to ‘talk’ to the USB device. In custom applications, a driver may need to be developed. Fortunately, drivers are available for most common host systems for the most common classes of devices. Thus, these drivers can be reused.