USB device states

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

Chapter 9 USB Device Framework in the USB specification revision 2.0 defines a number of
states for a USB device, illustrated below.

Figure 2. Device state diagram

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), the POWER chapter defines
two events USBDETECTED and USBREMOVED, they can be used to implement the state machine.

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.

USB terminology

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).

USB pins

The dedicated USB pins can be grouped in two categories: signal and power.

For details on the USB power supply and VBUS detection, refer to the POWER chapter.

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 implements the "5V Short Circuit Withstand ECN", which amends the original USB 2.0 Specification. This
means that 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.

USBD start-up sequence

The PHY of the USBD 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.

The turning on or off of the PHY's power supply is directly linked to the ENABLE register. The device provides events that help synchronizing software to the various steps during the
power up sequence.

It is recommended to enable USBD only after VBUS has been detected, and turn on the USB pull-up
after a USBPWRRDY event has occurred, and after a USBEVENT has occurred with the READY condition flagged
in EVENTCAUSE. This ensures that all resources in USBD are available and the dedicated USB voltage regulator
has stabilized.

Below sequence chart illustrates a typical handling of VBUS power up.

Figure 3. VBUS power up sequence

Upon detection of VBUS removal, signalled by the USBREMOVED event described in the POWER chapter,
it is recommended to let on-going EasyDMA transfers finish (wait for the relevant ENDEPIN[n], ENDISOIN,
ENDEPOUT[n] or ENDISOOUT event, see EasyDMA), then to disable USBD through writing ENABLE = Disabled .

USB pull-up

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

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 kOhm resistors. The device is not seen by the host, and hence defined to be in detached state,
even though it could be physically connected to the host. USB spec does not allow to draw any current on
VBUS in that situation.

When a full-speed device connects its 1.5 kOhm pull-up to D+, the host sees the corresponding line high. The
device is then in attached state. The host may attempt to determine if the device supports higher speeds (which it does not), and will
then initiate communication with the device to further identify it; this process is called enumeration.

If the host supports higher speed grades and the device is full-speed, the host may attempt to determine
if that device is capable of higher speeds. The USBD peripheral implemented in this device supports only
full-speed (12 Mbps), and will ignore the negotiation for higher speeds, in accordance with the USB
specification revision 2.0, full speed part.

The USBPULLUP register provides means to connect or disconnect the pull-up on D+ under software control.
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 set to 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 the USBPULLUP register 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 the ENABLE register. Attempting
to access the USBPULLUP register prior to that will lead to an ACCESSFAULT event to get generated.

The USB pull-up value is automatically changed depending on bus activity, as specified in the "Resistor ECN"
which amends the original USB Specification v2.0 . The user does not have access to this function, it is
handled in hardware.

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

USB reset

The USB specification defines a USB reset, which shall not be confused with a chip reset.

The USB reset results from a single-ended low state (SE0) on the D+ / D- lines for a time TDETRST,
as specified in the USB specification chapter 7. Only the host is allowed to drive a USB reset condition on
the bus.

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 UBSD peripheral automatically interprets a SE0 longer than tUSB,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 will get disabled, and the USBADDR will be reset to 0.

After having been connected to the USB bus (i.e. after VBUS gets 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 TRSTRCY (as per USB
specification chapter 7). Software shall take into account that it takes tUSB,RSTRCY
for the hardware to recover from a USB reset condition.

USB suspend and resume

Normally, the host will maintain activity on the USB at least every millisecond per USB specification.

To signal that the device shall go into low power mode, 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 into a low power mode
within a specified time.

The USB host can decide at any moment to suspend USB activity. When this happens, the device is
obligated per USB specification to enter a low power mode. The host can decide at any moment to resume
USB activity, on its own initiative. If Remote WakeUp has been enabled by the host, the device may also
issue a RESUME request to wake up the host.

Entering suspend

The USBD peripheral automatically detects a lack of activity for more than tUSB,SUSPEND and will
generate the corresponding USBEVENT event, with SUSPEND bit set in the EVENTCAUSE register. The software
shall ensure that the current drawn from the USB supply line VBUS is within the specified limits
before T2SUSP as defined in chapter 7 of the USB specification.

In order to save power, and provided that no other peripheral needs it, the crystal oscillator (HFXO)
in CLOCK may be disabled by software during USB suspend, while the USB pull-up is disconnected, or when
VBUS is not present. Software must explicitly enable it at any other time. The USBD will not
be able to respond to USB traffic unless HFXO is enabled and stable.

Host-initiated resume

If the host resumes bus activity with or without a RESUME condition (in other words: bus activity is
defined as any non-J state), the USBD peripheral will generate a USBEVENT event, with RESUME bit set
in the EVENTCAUSE register, and the device has to be responsive to any incoming request on the USB bus
within the time TRSMRCY defined in chapter 7 of the USB specification. It is also allowed
to revert to normal power consumption mode.

If the host resumes bus activity simply by restarting sending frames, the USBD peripheral will
generate SOF events. Also here the device has to be responsive to any incoming request on the USB bus,
and can be in normal power consumption mode.

Device-initiated remote wake-up

Assuming that remote wake-up is supported by the device and has been enabled by the host, if the device meets
a wake-up condition while the device is suspended, the device can request the host to resume.

To do so, the software shall first make sure that HFXO gets enabled.

It can then instruct the USBD peripheral to drive a RESUME condition (K state) on the USB bus through the
DPDMDRIVE task, and hence attempt to wake up the host. By choosing Resume in DPDMVALUE,
the duration of the RESUME state is under hardware control (TUSB,DRIVEK).
By choosing J or K, the duration of that state is under software control (the J or K state is maintained
until a DPDMNODRIVE task is issued), and has to meet TDRSMUP from USB specification chapter 7.

The value in the DPDMVALUE register will only be captured and used when the DPDMDRIVE task is sent.

Note that the device shall ensure that it does not initiate such a remote wake-up request before
TWTRSM (as per USB specification chapter 7) after the bus has entered idle state.
Using the recommended Resume value in DPDMVALUE, rather than K, takes care of this, and postpones the
RESUME state accordingly.

As just explained, the DPDMVALUE register contains the value at which the bus shall be forced after a
DPDMDRIVE task. If the software needs to read back the actual D+ and D- lines state, it can do so at any
time by reading the BUSSTATE register.

EasyDMA

The USBD peripheral includes EasyDMA so that USB buffers are located in Data
RAM .

The EPOUT[n].MAXCNT (n=1..7) and ISOOUT.MAXCNT registers define the length of the buffer,
in bytes, for next transfer of incoming data. Since the host decides how many bytes are being sent
over USB, the MAXCNT value can be copied from the respective SIZE.EPOUT[n] (n=1..7) or SIZE.ISOOUT register.

The EPOUT[0].MAXCNT register defines the length of the control endpoint OUT buffer, in bytes.
If the USB host does not misbehave, the SIZE.EPOUT[0] register will indicate the same value than MaxPacketSize from the device descriptor or wLength from the SETUP command, whichever is the
smallest.

The .AMOUNT registers indicate how many bytes have actually been transferred over EasyDMA
during last transfer.

The STARTEPIN[n], STARTEPOUT[n] (n=0..7), STARTISOIN and STARTISOOUT tasks capture the
.PTR and .MAXCNT registers values; for IN endpoints,
a transaction over USB gets automatically triggered when the EasyDMA transfer is complete; for
OUT endpoints, it is up to software to allow the next transaction over USB, see the examples in
Control transfers, Bulk and interrupt transactions
and Isochronous transactions.

The STARTED event confirms that the .PTR, .MAXCNT and .CONFIG registers values of
the endpoints flagged in the EPSTATUS register have been captured; those can then be modified by
software for the next transfer.

The ENDEPIN[n], ENDEPOUT[n] (n=0..7), ENDISOIN and ENDISOOUT events indicate that the whole
buffer in Data RAM has been consumed. The buffer can be accessed safely by software.

Only a single EasyDMA transfer can take place in USBD at any time. It is up to the software
to ensure that no STARTEPIN[n], STARTISOIN, STARTEPOUT[n] or STARTISOOUT task is sent before having
received the ENDEPIN[n], ENDISOIN, ENDEPOUT[n] or ENDISOOUT event from an on-going transfer.

EasyDMA and traffic on USB are tightly related. A number of events provide insight of what is happening
on the USB bus, and a number of tasks allow to somewhat automate response to traffic.

The EPDATA event indicates that a successful (acknowledged) data transaction has occurred on
the data endpoint(s) flagged in the EPDATASTATUS register.

In the particular case of the control endpoint 0, OUT transactions are allowed through the EP0RCVOUT
task. A successful (acknowledged) data transaction on endpoint 0 is signalled by the EP0DATADONE
event. The EP0STATUS task allows a status stage to be initiated, and the EP0STALL task allows
stalling further traffic (data or status stage) on the control endpoint.

The EP0SETUP event indicates that a SETUP token has been received on the control endpoint 0.
EasyDMA will not copy the SETUP data to Data RAM (it will only transfer data from the data stage),
they are available as separate registers in the USBD peripheral: BMREQUESTTYPE, BREQUEST,
WVALUEL, WVALUEH, WINDEXL, WINDEXH, WLENGTHL and WLENGTHH.

At any time, the USBEVENT event may be sent, and the EVENTCAUSE register provides details on
what happened, for instance if a CRC error is detected during a transaction, or if bus activity
stops or resumes.

Enabling endpoints is controlled through the EPINEN and EPOUTEN registers.

Stalling bulk/interrupt endpoints is controlled through the EPSTALL register.

Note that due to USB specification requirements, the effect of the stalling control endpoint 0
may be overridden by hardware, in particular when a new SETUP token is received.

Control transfers

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

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

Note: the control endpoint buffer size in Data RAM can be of any size in bytes, and there is no constraint
to keep it 32-bit aligned.

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

The software can choose to STALL the command (both data and status stages) through the EP0STALL task,
for instance if the command is not supported, or its wValue, wIndex or wLength parameters are wrong.
A stalled Control Read transfer is depicted below, but the same mechanism (same tasks) applies to
stalling a Control Write transfer (not depicted).

Refer to the chapter 9 of the USB Specification v2.0 and relevant Class specifications for rules on when
to STALL a command.

Figure 4. Control read gets STALLed

Important: the USBD peripheral handles the SetAddress transfer by itself. As a consequence, the software
shall not process this command, other than updating its state machine (see Device state diagram),
nor initiate a status stage. If necessary, the address assigned by the host can be read out from the
USBADDR register after the command has been processed.

Control Read transfer

This section describes how the software behaves to respond to a Control Read transfer.

As mentioned earlier, the USB controller will NAK any incoming IN token until software has finished decoding
the command, determined the type of transfer, and prepared the next stage (data or status) appropriately.

For a control-read, transferring the data from Data RAM memory into USBD
will trigger a valid, ACKed IN transaction on USB.

The software has to prepare EasyDMA by pointing to the buffer containing the data to be transferred. If
no other EasyDMA transfer is on-going with USBD, software can send the STARTEPIN0 task, which will initiate
the data transfer and transaction on USB.

A STARTED event (with EPIN0 bit set in the EPSTATUS register) will get fired as soon as the
EPIN[0].PTR and .MAXCNT registers
have been captured. Software may then prepare them for next data transaction.

A ENDEPIN[0] event will get fired when the data has been transferred from memory to the USBD peripheral.

Finally, an EP0DATADONE event will get fired when the data has been transmitted over USB and acknowledged
by the host.

The software can then either prepare and transmit the next data transaction by repeating the above sequence,
or initiate the status stage through the EP0STATUS task.

Figure 5. Control read transfer

Note the possibility to enable a shortcut from the EP0DATADONE event to the EP0STATUS task,
typically if the data stage is expected to take a single transfer.

If there is no data stage, the software can initiate the status stage through the EP0STATUS task
right away, as depicted below.

Figure 6. Control read no data transfer

Control Write transfer

This section describes how the software behaves to respond to a Control Write transfer.

The software has to prepare EasyDMA by pointing to the buffer in Data RAM that shall contain the incoming
data. If no other EasyDMA transfer is on-going with USBD, software can then send the EP0RCVOUT task, which
will make the USBD to accept (ACK) the first OUT+DATA transaction from the host.

An EP0DATADONE event will get fired when a new OUT+DATA has been transmitted over USB, and is about to
get acknowledged by the device.

A STARTED event (with EPOUT0 bit set in the EPSTATUS register) will get fired as soon as the
EPOUT[0].PTR and .MAXCNT registers
have been captured, after receiving the first transaction. Software may then prepare them for next data transaction.

A ENDEPOUT[0] event will get fired when the data has been transferred from the USBD peripheral to Data RAM.

The software can then either prepare to receive the next data transaction by repeating the above sequence,
or initiate the status stage through the EP0STATUS task. Until then, further incoming OUT + DATA transactions
get a NAK response by the device.

Bulk and interrupt transactions

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

Table 1. Bulk/interrupt endpoint numbering

Bulk endpoint #

USB IN endpoint

USB OUT endpoint

[1]

0x81

0x01

[2]

0x82

0x02

[3]

0x83

0x03

[4]

0x84

0x04

[5]

0x85

0x05

[6]

0x86

0x06

[7]

0x87

0x07

A bulk/interrupt transaction consists of a single data stage. Two consecutive, successful transactions are
distinguished through alternating leading 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, and in
general software does not need to care about it.

If an 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 specific cases, the software may want to force 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 a
ClearFeature, SetInterface or selecting an alternate setting. Controlling the data toggle of data
IN or OUT endpoint n=1..7 is done through the DTOGGLE register.

The maximum size of a bulk/interrupt transaction in USB Full Speed is 64 Bytes, and
has to be a multiple of
4 bytes, and be 32-bit aligned in Data RAM. However, the amount of DATA bytes transmitted on the USB data endpoint
can be of any size (up to 64 bytes).

When the transaction is done over USB, a EPDATA event is sent, and the hardware will automatically NAK further
IN tokens, until software is ready to send more data and has finished configuring EasyDMA, has started it,
and the whole buffer content has been moved to the USB controller (signalled by the ENDEPIN[n] event).

Each IN or OUT data endpoint has to be explicitly enabled by software through the EPINEN or EPOUTEN register,
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 so through the EPSTALL register (in which case the endpoint is said to be halted).

The halted (or not) state of a given endpoint can be read back from the HALTED.EPIN[n] or HALTED.EPOUT[n]
register. The format of the returned 16 bit value can be copied as is as response to a GetStatusEndpoint request
from the host.

Note that 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 get enabled and/or halted through the same mechanisms, but
due to USB specification, receiving a SETUP will override its state.

Bulk and interrupt IN transaction

The host issues IN tokens to receive bulk/interrupt data. In order to send data, the software has to enable the
endpoint and prepare an EasyDMA transfer on the desired endpoint, as illustrated below.

Bulk/interrupt IN endpoints are enabled or disabled through their respective INn bit (n=1..7) in EPINEN register.

It is also possible to stall or un-stall an endpoint through the EPSTALL register.

Figure 9. Bulk/interrupt IN transaction

It is possible (and some situations mandate it) to respond to an IN with a zero-length data packet.

Note: on many USB hosts, not responding (DATA+ACK or NAK) to three IN tokens on a interrupt endpoint
would have the host disable that endpoint as a consequence. Re-enumerating the device
(unplug-replug) may be required to restore functionality. Make sure the relevant data endpoints are enabled for
normal operation as soon as the device gets configured through a SetConfig request.

Bulk and interrupt OUT transaction

When the host wants to transmit bulk/interrupt data, it issues an OUT Token packet followed by a DATA packet on a given
endpoint n.

A NAK handshake is returned until the software writes any value to SIZE.EPOUT[n], indicating that the
local buffer's content can be overwritten. Upon receiving the next OUT + DATA transaction, an ACK handshake is
returned to the host while a EPDATA event is sent (and EPSTATUS register flags set to indicate on which endpoint
this happened), and once the EasyDMA is prepared and enabled through writing the EPOUT[n] registers and sending
the STARTEPOUT[n] task, the incoming data will be transferred to Data RAM. Until that transfer is finished, the
hardware will automatically NAK further incoming OUT+DATA packets. Only when the EasyDMA transfer is done (signalled by
the ENDEPOUT[n] event) and the software has written any value to SIZE.EPOUT[n], the endpoint n will accept
incoming OUT + DATA again.

It is allowed for the host to send out a zero-length data packet.

Bulk/interrupt OUT endpoints are enabled or disabled through their respective OUTn bit (n=1..7) in the EPOUTEN register.
It is also possible to stall or un-stall an endpoint through the EPSTALL register.

Figure 10. Bulk/interrupt OUT transaction

Isochronous transactions

The USBD peripheral implements isochronous (iso) endpoints.

The iso endpoints have a fixed USB endpoint number, summarized in the table below.

Table 2. Isochronous endpoint numbering

Iso endpoint #

USB IN endpoint

USB OUT endpoint

[0]

0x88

0x08

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

EasyDMA allows transferring iso data directly from and to Data RAM; EasyDMA transfers must be initiated
by software, which can synchronize to the SOF events.

Because the timing of the start of frame is very accurate, the SOF event can be used for instance to synchronize 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 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 the EPINEN or EPOUTEN register,
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 kByte 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.
This is done through the ISOSPLIT register, which provides a number of pre-determined splits.

Isochronous IN transaction

When the host wants to receive isochronous (iso) data, it issues an IN token on the isochronous endpoint.

On the isochronous IN endpoint, after the data has been transferred using the EasyDMA, the USB controller
responds to the IN token with the data that had been transferred, using the ISOIN.MAXCNT for the size of
the packet.

The iso IN data endpoint has to be explicitly enabled by software through the ISOIN0 bit in the EPINEN register.

When the iso IN endpoint is enabled, and if no data had been transferred with EasyDMA, the response of the USBD
depends on the setting of the RESPONSE field in the ISOINCONFIG register. If set to NoResp, no response to an IN token
will be provided. If set to ZeroData, the USBD responds with a zero-length data.

Note: the maximum size of an isochronous IN transfer in USB Full Speed is 1023 Bytes, and the data buffer in
RAM has to be a multiple of
4 bytes, and be 32-bit aligned in Data RAM. However, the amount of bytes transferred on the USB data endpoint
can be of any size (up to 1023 Byte if not shared with an OUT iso endpoint).

Figure 11. Isochronous IN transfer

Isochronous OUT transaction

When the host wants to send isochronous (iso) data, it issues an OUT token on the isochronous endpoint, followed by data.

The iso OUT data endpoint has to be explicitly enabled by software through the ISOOUT0 bit in the EPOUTEN register.

The amount of last received iso OUT data is provided in the SIZE.ISOOUT register.

Software shall interpret the ZERO and SIZE fields as follows:

Table 3. Iso OUT incoming data size

ZERO

SIZE

last received data size

Normal

0

No data received at all

Normal

1..1023

1..1023 bytes of data received

ZeroData

(don't care)

Zero-length data packet received

When the EasyDMA is prepared and started, sending a STARTISOOUT task initiates an EasyDMA transfer to Data
RAM. Software shall synchronize iso OUT transfers to the SOF events. If OUT data is not consumed and
processed until next SOF, it will be overwritten by more recent data.

Note: the maximum size of an isochronous OUT transfer in USB Full Speed is 1023 Bytes, and the data buffer in
RAM has to be a multiple of
4 bytes, and be 32-bit aligned in Data RAM. However, the amount of bytes transferred on the USB data endpoint
can be of any size (up to 1023 Byte if not shared with an IN iso endpoint).

If the last received iso data packet is corrupted (wrong CRC), the USB controller sends an USBEVENT event (at
the same time as SOF) and indicates a CRC error on ISOOUTCRC in the EVENTCAUSE register. EasyDMA will transfer
the data anyway if it has been set up properly.

Figure 12. Isochronous OUT transfer

USB register access limitations

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

This is the case while USBD is not enabled (through the ENABLE register) and ready (signalled
by the READY bit in EVENTCAUSE after the USBEVENT event),
or when USBD has been placed in low power while the USB bus is suspended.

If any of the register listed below gets accessed (read or write) by software of through the
debugger, an ACCESSFAULT event will get fired, and if the associated interrupt has been enabled
through the INTEN or INTENSET register in USBD, an interrupt will be taken.

Following registers are affected by this behaviour:

firing any task, including through PPI

BUSSTATE

HALTED.EPIN[0..7]

HALTED.EPOUT[0..7]

USBADDR

BMREQUESTTYPE

BREQUEST

WVALUEL

WVALUEH

WINDEXL

WINDEXH

WLENGTHL

WLENGTHH

SIZE.EPOUT[0..7]

SIZE.ISOOUT

USBPULLUP

DTOGGLE

EPINEN

EPOUTEN

EPSTALL

ISOSPLIT

FRAMECNTR

Registers

Table 4.
Instances

Base address

Peripheral

Instance

Description

Configuration

0x40027000

USBD

USBD

Universal serial bus device

Table 5.
Register Overview

Register

Offset

Description

TASKS_STARTEPIN[0]

0x004

Captures the EPIN[0].PTR, EPIN[0].MAXCNT and EPIN[0].CONFIG registers values, and enables endpoint IN 0 to respond to traffic from host

TASKS_STARTEPIN[1]

0x008

Captures the EPIN[1].PTR, EPIN[1].MAXCNT and EPIN[1].CONFIG registers values, and enables endpoint IN 1 to respond to traffic from host

TASKS_STARTEPIN[2]

0x00C

Captures the EPIN[2].PTR, EPIN[2].MAXCNT and EPIN[2].CONFIG registers values, and enables endpoint IN 2 to respond to traffic from host

TASKS_STARTEPIN[3]

0x010

Captures the EPIN[3].PTR, EPIN[3].MAXCNT and EPIN[3].CONFIG registers values, and enables endpoint IN 3 to respond to traffic from host

TASKS_STARTEPIN[4]

0x014

Captures the EPIN[4].PTR, EPIN[4].MAXCNT and EPIN[4].CONFIG registers values, and enables endpoint IN 4 to respond to traffic from host

TASKS_STARTEPIN[5]

0x018

Captures the EPIN[5].PTR, EPIN[5].MAXCNT and EPIN[5].CONFIG registers values, and enables endpoint IN 5 to respond to traffic from host

TASKS_STARTEPIN[6]

0x01C

Captures the EPIN[6].PTR, EPIN[6].MAXCNT and EPIN[6].CONFIG registers values, and enables endpoint IN 6 to respond to traffic from host

TASKS_STARTEPIN[7]

0x020

Captures the EPIN[7].PTR, EPIN[7].MAXCNT and EPIN[7].CONFIG registers values, and enables endpoint IN 7 to respond to traffic from host