Using the USB sample code of the RL-ARM library on MCB2300 develoment board. Started with the mass storage device example and modified for our application.
Is this example valid to USB specification? In particular concerned about flow control. I'm not clear if flow control in hw or sw or both. If not hardware, do these examples implement proper flow control? Our application may get some data and send time processing before reading more data.
"I'm not clear if flow control in hw or sw or both."
USB spec defines the intrinsic flow control using NAK, which is automatically handled by USB engine on MCU and host controller on PC. Of course, the USB engines on the NXP LPC family are equipped this hardware flow control.
The NAK flow control works as follows.
If an IN endpoint (EP) on a MCU is empty when a host accesses to it, the EP returns NAK. The host retries the IN transaction while the EP returns NAK, without any error. When the firmware loads a packet to the EP, the packet is retrieved by the host on the next IN transaction.
If an OUT EP is occupied by the last packet when a host sends next packet, the EP returns NAK. The host retries the OUT transaction of the same packet content while the EP returns NAK, without any error. When the firmware unloads the last packet from the EP, the EP becomes empty, and the next packet is accepted by the EP.
This NAK flow control is applied to bulk and interrupt EPs. Also, you'll see it on the data and status stage of control transfer on the default EP.
NAKing is not any error. Then, unless host app or device driver cancel the transfer (usually by timeout), it continues forever.
The bulk endpoints of LPC2368/78 has double buffer. The OUT and IN EPs can hold two packets. Naking starts when both of buffer are full (OUT), or both are empty (IN).
Tsuneo
Thanks for the very concise response.
I am actually using a WinUSB test application on the host that you directed to me previously. When I send some data to my device that requires > 2 USB packets (64 bytes /packet) the host app reports a BULK out error. This error comes directly from the WinUSB api. I am purposly slowing the processing on the device side to test the flow control. Seems like I get the first packet, process, meanwhile the host tries to send the other 2. Since the device is busy and not had a chance to read again, a NACK is sent but it appears to cause an error on the host/WinUSB app.
Seems like the flow control is invisible at the WinUSB api level, I'm stuck trying to explain or resolve this, any ideas?
Did you set timeout on the bulk pipe?
WinUsb_SetPipePolicy msdn.microsoft.com/.../aa476450.aspx PIPE_TRANSFER_TIMEOUT If the caller specifies a policy of PIPE_TRANSFER_TIMEOUT in PolicyType, WinUsb_SetPipePolicy sets the pipe transfer timeout policy parameter to the value that the caller specifies in Value.
The pipe transfer timeout policy parameter specifies the time-out interval, in milliseconds. The host cancels transfers that do not complete within the time-out interval. A value of zero means that transfers do not time out.
By default, the time-out value is zero, and the host never cancels a transfer because of a time-out. The Value parameter must point to a ULONG variable.
Yes I did find this and yes that was exactly the problem.
So I'm getting close here, but...
My device now receives packets from the host, however it eventually hangs up anywhere after receiving 10-100 USB packets. I traced it to the Keil USB sample code (UsbHw.c) in the read operation. As part of a read it calls a funtion (WrCmd) to send a Clear Buffer command to the USB hardware so we can receive more packets. Part of the Clear Buffer command is to wait for the command buffer empty flag to be set. This sometimes never happens.
Any ideas?
Paul