In
Figure 3 below, wireless
USB packet 291 is an MMC from the host which includes a WdtCTA used as
acknowledge for the previous In data packet (wireless USB packet 288).
Only when the device receives this MMC, can it claim that the
particular
In data packet has been received by the host. In this particular
case, the device cannot claim the CSW packet has been successfully
delivered to host until it receives the acknowledge embedded in the
packet 291. But what if this packet gets lost in the air? From this
particular host implementation, we can see it will only send the MMC
with acknowledge once. In the wireless world, the possibility of losing
this packet is not negligible.
 |
| Figure
3: In the wireless world, the possibility of losing packet 291 - an MMC
from the host which includes a WdtCTA used as acknowledge for the
previous In data packet - is not negligible. |
In some traditional USB class drivers written for mass storage, the
state machine inside the class driver will only get triggered when it
receives a status completion event (in most cases, it is an interrupt
from the device controller or an event from lower-level stacks).
More specifically, in the mass storage state machine, the class
driver will always expect a completion on the IN pipe for receiving the
13bytes of CSW before it pursues further operation, for example, moves
the state machine to CBW stage and programs the device controller to
receive CBW on the OUT pipe.
If the ACK for the CSW gets smashed, although it is actually
received by wireless USB host, there will be a mismatch between the
class driver state machine at the host side and at the device side. The
host will move the class state machine to CBW stage and will be ready
to send out CBW anytime if it finds the particular OUT pipe active.
But unfortunately, the OUT pipe enabling operation is normally
triggered by some software operation in the CBW stage of the device
class state machine. This means that on the bus there won't be any
DN_EPRdy for EPxOUT sent out to indicate that the pipe is active. At
the same time, the device class state machine will remain in the CSW
stage, waiting for a completion of the CSW (there is no way for the
device to know that the CSW packet has been received by the host unless
further transfer has been scheduled from device). Due to this mismatch,
deadlock is generated.
Device-side management
The class driver on the device side needs to manage this case carefully
with the consideration of "packet lost" situation. A typical solution
to this problem in mass storage is to change the state machine so that
the OUT pipe for CBW will be activated inside the CSW stage of the
device class state machine, so the device side will not block the
activities on the bus for the next CBW. This solution is valid to
address the lost ACK for CSW in mass storage class and other
situations.
In the wireless USB world - even the wired USB world - any class
driver on the device side that defines a protocol which sends a packet
to an OUT endpoint after the transfer of an IN endpoint is finished
must take care that it enables the reception of OUT packets after
programming the IN transfer. It must not wait to enable the reception
of OUT data until it has seen an IN transfer complete interrupt.
Bart Vertenten is Chief Architect for
Connectivity Solutions, Mobile & Personal Applications and Sun Yuxi
is Senior Systems Engineer in the UWB Group at NXP
Semiconductors