CMP EMBEDDED.COM

Login | Register     Welcome Guest  
HOME DESIGN PRODUCTS COLUMNS E-LEARNING CONFERENCES CODE FORUMS/BLOGS NEWSLETTERS CONTACT FEATURES RSS RSS

How to mitigate packet loss in wireless USB networking applications



Embedded.com
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

1 | 2

Rate this article: Low High
Current rating
  • .
Embedded.com Career Center
Looking for a new job?
SEARCH JOBS

Browse all jobs

SPONSOR
RECENT JOB POSTINGS





 :