USBD — Universal serial bus device

The behavior of a USB device can be modelled through a state diagram.

The USB 2.0 Specification (see Chapter 9 USB Device Framework) defines a number of states for a USB device, as shown in the following figure.

The device must change state according to host-initiated traffic and USB bus states. It is up to the software to implement a state machine that matches the above definition. To detect the presence or absence of USB supply (VBUS), two events USBDETECTED and USBREMOVED can be used to implement the state machine. For more details on these events, see USB supply.

As a general rule when implementing the software, the host behavior shall never be assumed to be predictable. In particular the sequence of commands received during an enumeration. The software shall always react to the current bus conditions or commands sent by the host.

The USB specification defines bus states, rather than logic levels on the D+ and D- lines.

For a full speed device, the bus state where the D+ line is high and the D- line is low is defined as the J state. The bus state where D+ is low and D- high is called the K state.

An idle bus, where D+ and D- lines are only polarized through the pull-up on D+ and pull-downs on the host side, will be in J state.

Both lines low are called SE0 (single-ended 0), and both lines high SE1 (single-ended 1).

The USBD peripheral features a number of dedicated pins.

The dedicated USB pins can be grouped in two categories, signal and power. The signal pins consist of the D+ and D- pins, which are to be connected to the USB host. They are dedicated pins, and not available as standard GPIOs. The USBD peripheral is implemented according to the USB specification revision 2.0, 5V Short Circuit Withstand ECN Requirement Change, meaning these two pins are not 5 V tolerant.

The signal pins and the pull-up will operate only while VBUS is in its valid voltage range, and USBD is enabled through the ENABLE register. For details on the USB power supply and VBUS detection, see USB supply.

For more information about the pinout, see Pin assignments.

The physical layer interface (PHY)/USB transceiver is powered separately from the rest of the device (VBUS pin), which has some implications on the USBD power-up sequence.

The device is not able to properly signal its presence to the USB host and handle traffic from the host, unless the PHY's power supply is enabled and stable. Turning the PHY's power supply on/off is directly linked to register ENABLE. The device provides events that help synchronizing software to the various steps during the power-up sequence.

To make sure that all resources in USBD are available and the dedicated USB voltage regulator stabilized, the following is recommended:

• Enable USBD only after VBUS has been detected
• Turn the USB pull-up on after the following events have occurred:
  • USBPWRRDY
  • USBEVENT, with the READY condition flagged in EVENTCAUSE

The following sequence chart illustrates a typical handling of VBUS power-up:

Upon detecting VBUS removal, it is recommended to wait for ongoing EasyDMA transfers to finish before disabling USBD (relevant ENDEPIN[n], ENDISOIN, ENDEPOUT[n], or ENDISOOUT events, see EasyDMA). The USBREMOVED event, described in USB supply, signals when the VBUS is removed. Reading the ENABLE register will return Enabled until USBD is completely disabled.

The USB pull-up serves two purposes: it indicates to the host that the device is connected to the USB bus, and it indicates the device's speed capability.

When no pull-up is connected to the USB bus, the host sees both D+ and D- lines low, as they are pulled down on the host side by 15 kΩ resistors. The device is not detected by the host, putting it in a detached state even if it is physically connected to the host. In this situation, the device is not allowed to draw current from VBUS, according to USB 2.0 Specification.

When a full-speed device connects its 1.5 kΩ pull-up to D+, the host sees the corresponding line high. The device is then in the attached state. During the enumeration process, the host attempts to determine if the full-speed device also supports higher speeds and initiates communication with the device to further identify it. The USBD peripheral implemented in this device supports only full-speed operation (12 Mbps), and thus ignores the negotiation for higher speeds in accordance with USB 2.0 Specification.

Register USBPULLUP enables software to connect or disconnect the pull-up on D+. This allows the software to control when USB enumeration takes place. It also allows to emulate a physical disconnect from the USB bus, for instance when re-enumeration is required. USBPULLUP has to be enabled to allow the USBD to handle USB traffic and generate appropriate events. This forbids the use of an external pull-up.

Note that disconnecting the pull-up through register USBPULLUP while connected to a host, will result in both D+ and D- lines to be pulled low by the host's pull-down resistors. However, as mentioned above, this will also inhibit the generation of the USBRESET event. The pull-up is disabled by default after a chip reset.

The pull-up shall only get connected after USBD has been enabled through register ENABLE. The USB pull-up value is automatically changed depending on the bus activity, as specified in Resistor ECN which amends the original USB 2.0 Specification. The user does not have access to this function as it is handled in hardware.

While they should never be used in normal traffic activity, lines D+ and D- may at any time be forced into state specified in register DPDMVALUE by the task DPDMDRIVE. The DPDMNODRIVE task stops driving them, and PHY returns to normal operation.

The USB specification defines a USB reset, which is not be confused with a chip reset. The USB reset is a normal USB bus condition, and is used as part of the enumeration sequence, it does not reset the chip.

The USB reset results from a single-ended low state (SE0) on lines D+/D- for a t_USB,DETRST amount of time. Only the host is allowed to drive a USB reset condition on the bus. The UBSD peripheral automatically interprets a SE0 longer than t_USB,DETRST as a USB reset. When the device detects a USB reset and generates a USBRESET event, the device USB stack and related parts of the application shall re-initialize themselves, and go back to the default state.

Some of the registers in the USBD peripheral get automatically reset to a known state, in particular all data endpoints are disabled and the USBADDR reset to 0.

After the device has connected to the USB bus (i.e. after VBUS is applied), the device shall not respond to any traffic from the time the pull-up is enabled until it has seen a USB reset condition. This is automatically ensured by the USBD.

After a USB reset, the device shall be fully responsive after at most T_RSTRCY (according to chapter 7 in the USB specification). Software shall take into account this time that takes the hardware to recover from a USB reset condition.

Normally, the host will maintain activity on the USB at least every millisecond according to USB specification. A USB device will enter suspend when there is no activity on the bus (idle) for a given time. The device will resume operation when it receives any non idle signalling.

To signal that the device shall go into low power mode (suspend), the host stops activity on the USB bus, which becomes idle. Only the device pull-up and host pull-downs act on D+ and D-, and the bus is thus kept at a constant J state. It is up to the device to detect this lack of activity, and enter the low power mode (suspend) within a specified time.

The USB host can decide to suspend or resume USB activity at any time. If remote wake-up is enabled, the device may signal to the host to resume from suspend.

The USBD peripheral implements EasyDMA for accessing memory without CPU involvement.

Each endpoint has an associated set of registers, tasks and events. EasyDMA and traffic on USB are tightly related. A number of events provide insight of what is happening on the USB bus with a number of tasks allowing an automated response to the traffic.

The USB specification mandates every USB device to implement endpoint 0 IN and OUT as control endpoints.

A control transfer consists of two or three stages:

• Setup stage
• Data stage (optional)
• Status stage

Each control transfer can be one of following types:

• Control read
• Control read no data
• Control write
• Control write no data

An EP0SETUP event indicates that the data in the setup stage (following the SETUP token) is available in registers.

The data in the data stage (following the IN or OUT token) is transferred from or to the desired location using EasyDMA.

The control endpoint buffer can be of any size.

After receiving the SETUP token, the USB controller will not accept (NAK) any incoming IN or OUT tokens until the software has finished decoding the command, determined the type of transfer, and prepared for the next stage (data or status) appropriately.

The software can stall a command when in the data and status stages, through the EP0STALL task, when the command is not supported or if its wValue, wIndex or wLength parameters are wrong. The following shows a stalled control read transfer, but the same mechanism (tasks) applies to stalling a control write transfer.

See the USB 2.0 Specification and relevant class specifications for rules on stalling commands.

The USBD peripheral implements seven pairs of bulk/interrupt endpoints.

The bulk/interrupt endpoints have a fixed USB endpoint number, summarized in the following table.

A bulk/interrupt transaction consists of a single data stage. Two consecutive, successful transactions are distinguished through alternating leading process ID (PID): DATA0 follows DATA1, DATA1 follows DATA0, etc. A repeated transaction is detected by re-using the same PID as previous transaction, i.e DATA0 follows DATA0, or DATA1 follows DATA1.

The USBD controller automatically toggles DATA0/DATA1 PIDs for every bulk/interrupt transaction.

If incoming data is corrupted (CRC does not match), the USBD controller automatically prevents DATA0/DATA1 from toggling, to request the host to resend the data.

In some specific cases, the software may want to force a data toggle (usually reset) on a specific IN endpoint, or force the expected toggle on an OUT endpoint, for instance as a consequence of the host issuing ClearFeature, SetInterface, or selecting an alternate setting. Controlling the data toggle of data IN or OUT endpoint n (n=1..7) is done through register DTOGGLE.

The bulk/interrupt transaction in USB full-speed can be of any size up to 64 bytes. It must be a multiple of four bytes and 32-bit aligned in memory.

When the USB transaction has completed, an EPDATA event is generated. Until new data has been transferred by EasyDMA from memory to the USBD peripheral (signalled by the ENDEPIN[n] event), the hardware will automatically respond with NAK to all incoming IN tokens. Software has to configure and start the EasyDMA transfer once it is ready to send more data.

Each IN or OUT data endpoint has to be explicitly enabled by software through register EPINEN or EPOUTEN, according to the configuration declared by the device and selected by the host through the SetConfig command.

A disabled data endpoint will not respond to any traffic from the host. An enabled data endpoint will normally respond NAK or ACK (depending on the readiness of the buffers), or STALL (if configured in register EPSTALL), in which case the endpoint is asked to halt. The halted (or not) state of a given endpoint can be read back from register HALTED.EPIN[n] or HALTED.EPOUT[n]. The format of the returned 16-bit value can be copied as is, as a response to a GetStatusEndpoint request from the host.

Enabling or disabling an endpoint will not change its halted state. However, a USB reset will disable and clear the halted state of all data endpoints.

The control endpoint 0 IN and OUT can also be enabled and/or halted using the same mechanisms, but due to USB specification, receiving a SETUP will override its state.

The USBD peripheral implements isochronous (ISO) endpoints.

The ISO endpoints have a fixed USB endpoint number, summarized in the following table.

An isochronous transaction consists of a single, non-acknowledged data stage. The host sends out a start of frame at a regular interval (1 ms), and data follows IN or OUT tokens within each frame.

EasyDMA allows transferring ISO data directly from and to memory. EasyDMA transfers must be initiated by the software, which can synchronize with the SOF (start of frame) events.

Because the timing of the start of frame is very accurate, the SOF event can be used for jobs such as synchronizing a local timer through the SOF event and PPI. The SOF event gets synchronized to the 16 MHz clock prior to being made available to the PPI.

Every start of frame increments a free-running counter, which can be read by software through the FRAMECNTR register.

Each IN or OUT ISO data endpoint has to be explicitly enabled by software through register EPINEN or EPOUTEN, according to the configuration declared by the device and selected by the host through the SetConfig command. A disabled ISO IN data endpoint will not respond to any traffic from the host. A disabled ISO OUT data endpoint will ignore any incoming traffic from the host.

The USBD peripheral has an internal 1 kB buffer associated with ISO endpoints. The user can either allocate the full amount to the IN or the OUT endpoint, or split the buffer allocation between the two using register ISOSPLIT.

The internal buffer also sets the maximum size of the ISO OUT and ISO IN transfers: 1023 bytes when the full buffer is dedicated to either ISO OUT or ISO IN, and half when the buffer is split between the two.

Some of the registers in USBD cannot be accessed in specific conditions.

This may be the case when USBD is not enabled (using the ENABLE register) and ready (signalled by the READY bit in EVENTCAUSE after a USBEVENT event), or when USBD is in low power mode while the USB bus is suspended.