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,