AnsweredAssumed Answered

USB OUT token NAK by BF525, Status Phase IN token NAK

Question asked by jroegele on Feb 22, 2011
Latest reply on Aug 10, 2011 by CraigG
Branched to a new discussion

Hello, I am using the USB peripheral of the BF525, and have implemented the CDC class in a manner that makes use of the standard USB-serial driver on the host OS. Sometimes I am seeing a control transaction on EP0 that looks like this:


SETUP packet     2D 02 A8

DATA0 packet     C3 21 20 00 00 00 00 07 00 5F D2

ACK packet          D2


OUT packet          E1 02 A8

DATA1 packet     4B 00 C2 01 00 00 00 08 C8 1B

NAK packet          5A


In reading USB documentation, it appears to me that the device is allowed to NAK an OUT packet, and that if the NAK occurs on either a Control or Bulk endpoint, the host should subsequently retry the OUT packet.


The problem is that the standard serial driver on the host OS does not seem to handle a NAK here well. On my Linux install, it actually never ever retries. On my Windows install, it does retry and this time the device returns a NYET packet (I'm using high-speed USB), and then it seems it does not retry but instead moves on to the next control transaction, which leaves the BF525 confused and causes problems.


Has anyone else seen this behaviour? I have implemented the same logic on another design with the BF561 and a NetChip USB device, and I do not see this problem, but in fact I do not ever see any NAKs on OUT tokens. I think because the NetChip has two buffers for EP0 it can always fit the EP0 transaction without needing to NAK or NYET. I'm wondering if in general almost nothing ever NAKs and so the host drivers are never really tested against this? I feel like I'm missing something.


Is there an optimization that might be possible to the BF525 firmware to prevent the NAK/NYET? It seems to be practically it cannot be done, and if I understand the USB spec properly, should not have to be done. The issue is if I can't make use of the standard OS USB driver, then it doesn't matter if it meets the spec or not!!!




I think that I have convinced myself that the device can NAK an OUT token within the USB specification (although confirmation would be great). Perhaps my more pointed question would be in the sequence that follows. The host (Windows) retries and the device next replies with a NYET to the OUT token, which is also okay, as far as I can tell, as this is a high-speed USB device. The host then sends an IN token expecting a ZLP back from the device to complete the Status phase, but the device (BF525) actually sends a NAK to this IN token. So the question really is, can the device NAK in the Status phase? And if so what are the consequences? What ends up happening is that the host just starts a new control transaction after the NAK, but the first IN token received as part of this new transaction is causing the BF525 to return a ZLP, as if it was expecting the host to retry the IN token from the previous transaction Status phase until it ACKed back. So what is the correct behaviour in this case? Is the BF525 behaving within the USB spec? I have attached a Word document showing the USB trace to help.



Thanks in advance for any comments/suggestions,