PKP
VS1000 P
ROGRAMMER
’
S
G
UIDE
VSMPG
update the value of USB_RDPTR, indicating that the packet is no longer needed.
The USB hardware automatically NAK’s incoming data packets if there is less than
40 words space left in the buffer memory. In this situation the hardware still accepts
SETUP packets. If receiving a packet would cause the USB_WRPTR to be overrun by
USB_RDPTR, e.g. there is no more room for even the SETUP packet, even the SETUP
packets are NAK’ed.
20.3.2
Sending Packet to PC (EP0IN, EP1IN, ... , EP3IN)
To send a USB packet, software must prepare the packet to the transmit buffer area,
starting at a 64-word boundary. The data is to be stored in Big Endian format, e.g.
the first byte to be sent should be in the most significant 8 bits of the first word. Next,
software should load the USB_EP_SEND register of the chosen endpoint with the start
location selector and size of the transmittable packet (in bytes). The most significant bit
of the register (txpkt-ready) should be set to “1”.
When the internal Transmit Holding Register for the endpoint is ready, the value of the
USB_EP_SEND register is loaded to the internal Transmit Holding Register and txpkt-
ready bit of the USB_EP_SEND register is set to “0”. This indicates that the packet is
queued for transmission and the USB_EP_SEND register can be loaded with informa-
tion about the next sendable packet (if any).
To get information about when the packet has actually been transmitted to the PC, the
Transmitter Idle (in-xmit-empty) bit of the endpoint’s USB_EP_ST register can be polled
(or the corresponding interrupt used).
20.3.3
How to know that the PC is expecting data
During software development, when protocol matters can be still somewhat unclear, it
is sometimes difficult to know when the PC actually is expecting you to send a packet
to some endpoint. In the USB hardware there is a feature to assist in finding out this
information: the endpoint’s in-nak-sent bit of the endpoint’s USB_EP_ST register. Using
this bit can avoid a common pitfall: loading a transmitter register with packet that is never
actually requested by a PC. That would cause the packet information to remain in the
transmitter register (until next USB reset), which again would cause the packet to be
sent as an answer to the
next
request of the PC, causing unexpected results.
20.3.4
Stalling
STALL is a special condition on the USB bus, which more or less states, that “I can’t
handle this data packet now nor in the future”. For example when the software needs to
STALL reception of data from PC, software should set out-forcestall to “1” and out-stall-
sent to “0”. The hardware will then wait for the next OUT token from the PC and respond
Rev. 0.20
2011-10-04
Page