USB CDC descriptor problem

Ruben,
here are the descriptors for the STR9 as provided by ST. I hope this helps...

/* USB Standard Device Descriptor */
const u8 Virtual_Com_Port_DeviceDescriptor[] = {
        0x12,   /* bLength */
        USB_DEVICE_DESCRIPTOR_TYPE,     /* bDescriptorType */
        0x00,
        0x02,   /* bcdUSB = 2.00 */
        0x02,   /* bDeviceClass: CDC */
        0x00,   /* bDeviceSubClass */
        0x00,   /* bDeviceProtocol */
        0x40,   /* bMaxPacketSize0 */
        0x83,
        0x04,   /* idVendor = 0x0483 */
        0x40,
        0x57,   /* idProduct = 0x7540 */
        0x00,
        0x01,   /* bcdDevice = 1.00 */
        1,              /* Index of string descriptor describing manufacturer */
        2,              /* Index of string descriptor describing product */
        3,              /* Index of string descriptor describing the device's serial number */
        0x01    /* bNumConfigurations */
};


const u8 Virtual_Com_Port_ConfigDescriptor[] = {
/*Configuation Descriptor*/
        0x09,   /* bLength: Configuation Descriptor size */
        USB_CONFIGURATION_DESCRIPTOR_TYPE,      /* bDescriptorType: Configuration */
        VIRTUAL_COM_PORT_SIZ_CONFIG_DESC,       /* wTotalLength:no of returned bytes */
        0x00,
        0x02,   /* bNumInterfaces: 2 interface */
        0x01,   /* bConfigurationValue: Configuration value */
        0x00,   /* iConfiguration: Index of string descriptor describing the configuration */
        0xC0,   /* bmAttributes: self powered */
        0x00,   /* MaxPower 0 mA */
/*Interface Descriptor*/
        0x09,   /* bLength: Interface Descriptor size */
        USB_INTERFACE_DESCRIPTOR_TYPE,  /* bDescriptorType: Interface */
                        /* Interface descriptor type */
        0x00,   /* bInterfaceNumber: Number of Interface */
        0x00,   /* bAlternateSetting: Alternate setting */
        0x01,   /* bNumEndpoints: One endpoints used */
        0x02,   /* bInterfaceClass: Communication Interface Class */
        0x02,   /* bInterfaceSubClass: Abstract Control Model */
        0x01,   /* bInterfaceProtocol: Common AT commands */
        0x00,   /* iInterface: */
/*Header Functional Descriptor*/
        0x05,   /* bLength: Endpoint Descriptor size */
        0x24,   /* bDescriptorType: CS_INTERFACE */
        0x00,   /* bDescriptorSubtype: Header Func Desc */
        0x10,   /* bcdCDC: spec release number */
        0x01,
/*Call Managment Functional Descriptor*/
        0x05,   /* bFunctionLength */
        0x24,   /* bDescriptorType: CS_INTERFACE */
        0x01,   /* bDescriptorSubtype: Call Management Func Desc */
        0x00,   /* bmCapabilities: D0+D1 */
        0x01,   /* bDataInterface: 1 */
/*ACM Functional Descriptor*/
        0x04,   /* bFunctionLength */
        0x24,   /* bDescriptorType: CS_INTERFACE */
        0x02,   /* bDescriptorSubtype: Abstract Control Management desc */
        0x02,   /* bmCapabilities */
/*Union Functional Descriptor*/
        0x05,   /* bFunctionLength */
        0x24,   /* bDescriptorType: CS_INTERFACE */
        0x06,   /* bDescriptorSubtype: Union func desc */
        0x00,   /* bMasterInterface: Communication class interface */
        0x01,   /* bSlaveInterface0: Data Class Interface */
/*Endpoint 2 Descriptor*/
        0x07,   /* bLength: Endpoint Descriptor size */
        USB_ENDPOINT_DESCRIPTOR_TYPE,   /* bDescriptorType: Endpoint */
        0x82,   /* bEndpointAddress: (IN2) */
        0x03,   /* bmAttributes: Interrupt */
        VIRTUAL_COM_PORT_INT_SIZE,      /* wMaxPacketSize: */
        0x00,
        0xFF,   /* bInterval: */
/*Data class interface descriptor*/
        0x09,   /* bLength: Endpoint Descriptor size */
        USB_INTERFACE_DESCRIPTOR_TYPE,  /* bDescriptorType: */
        0x01,   /* bInterfaceNumber: Number of Interface */
        0x00,   /* bAlternateSetting: Alternate setting */
        0x02,   /* bNumEndpoints: Two endpoints used */
        0x0A,   /* bInterfaceClass: CDC */
        0x00,   /* bInterfaceSubClass: */
        0x00,   /* bInterfaceProtocol: */
        0x00,   /* iInterface: */
/*Endpoint 3 Descriptor*/
        0x07,   /* bLength: Endpoint Descriptor size */
        USB_ENDPOINT_DESCRIPTOR_TYPE,   /* bDescriptorType: Endpoint */
        0x03,   /* bEndpointAddress: (OUT3) */
        0x02,   /* bmAttributes: Bulk */
        VIRTUAL_COM_PORT_DATA_SIZE,             /* wMaxPacketSize: */
        0x00,
        0x00,   /* bInterval: ignore for Bulk transfer */
/*Endpoint 1 Descriptor*/
        0x07,   /* bLength: Endpoint Descriptor size */
        USB_ENDPOINT_DESCRIPTOR_TYPE,   /* bDescriptorType: Endpoint */
        0x81,   /* bEndpointAddress: (IN1) */
        0x02,   /* bmAttributes: Bulk */
        VIRTUAL_COM_PORT_DATA_SIZE,             /* wMaxPacketSize: */
        0x00,
        0x00    /* bInterval: ignore for Bulk transfer */
};

/* USB String Descriptors*/
const u8 Virtual_Com_Port_StringLangID[VIRTUAL_COM_PORT_SIZ_STRING_LANGID] = {
        VIRTUAL_COM_PORT_SIZ_STRING_LANGID,
        USB_STRING_DESCRIPTOR_TYPE,
        0x09,
        0x04
};      /* LangID = 0x0409: U.S. English */

const u8 Virtual_Com_Port_StringVendor[VIRTUAL_COM_PORT_SIZ_STRING_VENDOR] = {
        VIRTUAL_COM_PORT_SIZ_STRING_VENDOR,     /* Size of Vendor string */
        USB_STRING_DESCRIPTOR_TYPE,             /* bDescriptorType*/
        /* Manufacturer: "STMicroelectronics" */
        'S',0, 'T',0, 'M',0, 'i',0, 'c',0, 'r',0, 'o',0, 'e',0,
        'l',0, 'e',0, 'c',0, 't',0, 'r',0, 'o',0, 'n',0, 'i',0,
        'c',0, 's',0
};

const u8 Virtual_Com_Port_StringProduct[VIRTUAL_COM_PORT_SIZ_STRING_PRODUCT] = {
        VIRTUAL_COM_PORT_SIZ_STRING_PRODUCT,          /* bLength */
        USB_STRING_DESCRIPTOR_TYPE,        /* bDescriptorType */
        /* Product name: "STR71x Virtual Com Port" */
        'S',0, 'T',0, 'R',0, '7',0, '1',0, 'x',0, ' ',0, 'V',0,
        'i',0, 'r',0, 't',0, 'u',0, 'a',0, 'l',0, ' ',0, 'C',0,
        'O',0, 'M',0, ' ',0, 'P',0, 'o',0, 'r',0, 't',0, ' ',0,
        ' ',0

};
const u8 Virtual_Com_Port_StringSerial[VIRTUAL_COM_PORT_SIZ_STRING_SERIAL] = {
        VIRTUAL_COM_PORT_SIZ_STRING_SERIAL,           /* bLength */
        USB_STRING_DESCRIPTOR_TYPE,        /* bDescriptorType */
        'D',0, 'e',0, 'm',0, 'o',0, ' ',0, '1',0, '.',0, '0',0,
        '0',0, '0',0
};

"If I try to set number of endpoints to 2 in the Data Class Interface descriptor, windows return an error (code 10), and can't initialize the device."

I don't see any error (except for the number of EP) on the descriptors.

Disconnect the device from the PC,
On the Device Manager, delete the device instance of this CDC once.
Then, re-install the device.
You can see disconnected device on the Device Manager as follows.

1) Copy these two lines to a blank text file, and rename the file to DevManager.bat

set devmgr_show_nonpresent_devices=1
start devmgmt.msc

2) Double click DevManager.bat, and Device Manager comes up.
On 'View' menu, select 'Show hidden devices'

CDC device is displayed under "Port (COM & LPT)" branch on the Dev Manager.


The CDC device requires custom INF file to install to the PC.
Is there any problem on the INF file?

You can see working INF file in this example (USB_CDC_skeleton_15.zip) on my post to SiLabs forum.
"USB CDC implementation for 'F32x & 'F34x" on SiLabs USB forum
www.cygnal.org/.../000945.html

Modify the VID/PID of the INF file, to that on the device descriptor of your device.

Tsuneo

Hello!

I tryed quickly to do what you say and it seems that not work...but the device is halted, windows doesn't return any error code. I want to see it with calm, and try again. I will tell you if it works.

Thank you very much in advance for your time!

Regards, Rubén.

"I tryed quickly to do what you say and it seems that not work...but the device is halted, windows doesn't return any error code."

Then, you made one step forward with the correct descriptors. :-)
You come across next problem.

On the course of enumeration, Windows issue many USB requests to the device. The enumeration stops at some request handling on the device. At the next step, we have to find the request handling in problem.

Do you have any hardware USB bus analyzer?
If you don't, download this software sniffer and 'evaluate' it.

SourceUSB
http://www.sourcequest.com/

Monitor the USB traffic using this sniffer, just after device plug-in.
What is the last request on the enumeration?
Does the request succeed?

When you can specify the request in problem, review the part of the firmware code which handles the request.

Tsuneo

Hello Tamir,

I were looking for a difference between the descriptors, but are the same. thanks for your time anyway!

I'll continue working in the solution.

Regards, Ruben.

Hello Tsuneo.

Unfortunally, I tryed again (many times) to reinstall the device, and only was a windows bug during re-installation what happened last day.
After reset windows, I get the same error: (code 10) can't initialize. I tryed to reinstall serveral times after reset, but nothing changes.
I use an INF file, based on your sample that I saw a few days ago (thanks for your example, was very useful to develop my firmware ;)).
I installed the device with diferent INF files based on exmples and tutorials I read, but always were a problem with the driver usbser.sys, because Vista can't call directly this driver. I solved the problem of the driver, but can't use 2 endpoints at same time.

In the other hand, I try to analyze the requests manually, debugging firmware and writing requests in a paper. I suspect that there are an error during enumeration, in configuration descriptors, but I'm not sure.
The requests that use my device are in order of appearence:

Where " means that last value is repeated.

-------------------------------------------------------
Num.of Frame __1___2 _3 _4 _5 _6 _7 _8 _9 10 11 12 _13|
-------------------------------------------------------
bmRequestType 128 0 128 _" _" _" _" __" _" _" _0 161 33
bRequest_______6 _5 _6 _6 _6 _6 _6 _6 _6 _6 _9 33 _34 |
wValueL________0 _0 _0 _0 _3 _0 _2 _0 _0 _0 _1 _0 _0 |
wValueH________1 _1 _1 _2 _3 _3 _3 _6 _2 _2 _0 _0 _0 |
wIndexL________0 _0 _0 _0 _9 _0 _9 _0 _0 _0 _0 _0 _0 |
xIndexH________0 _0 _0 _0 _4 _0 _4 _0 _0 _0 _0 _0 _0 |
wLengthL______64 _0 18 255 " _" _" _10 _9 _0 _0 _7 _0 |
wLengthH______0 _0 _0 _0 _0 _0 _0 _0 _1 16 _0 _0 _0 |
-------------------------------------------------------
(Uff I almost go crazy to make it readeable, the forum doesn't accept tabulator or 2 consucutive spaces)
Requests in every frame:

Frame1: Get descriptor, Device descriptor
***********(Bus reset)************
Frame2: Set Address (sometimes, change to 2, but I think is not relevant)
Frame3: Get descriptor, device descriptor, length = 18
Frame4: Get descriptor, configuration, length = 255, but I send 67Bytes (specified in total length)
Frame5-Frame7: Strings descriptors
Frame8: Get descriptor, Device qualifier. I add the device qualifier to enumeration, but it seems not to be relevant in device enumeration, and I delete this request and return Stall.
Frame9: Get descriptor, configuration, length = 19. I send the header functional desc., call management functional desc., abstract control management desc., and union functional descriptor.
Frame10: request again for configuration descriptor, but with length of 160 bytes (?). I send again all configuration descriptors like in F4, but I don't know if it's correct.
Frame11: Set Configuration 1
Frame12: Get line coding, length = 7 (this frame, is requested 2 times). I don't know if there are a problem to read it
Frame13: Set control line coding

When I connect any program to virtual port, there are some requests:
1: Frame12 (get line coding) for 6 consecutive times!
2: Set Line coding
3: Set control, line conding with wValueL = 2.
4: Frame12 (get line coding) for 2 more times
5: Set line coding one more time

After that, I connect with the device, but only to do the communication in the way that tells the first of the 2 endpoints in the data interface. The second is ignored because only can accept 1 ep.

I install the program from sourcequest. The first time program runs and tell me that second endpoint from data interface (bulk) have maxPacketSize = 512 Bytes and 67ms in the interval. I think that must be default values because I don't use this values anywhere.
I reset windows and all the USB devices doesn't work (nor mouse neither keyboard). Fortunally I have a remote control program and solved the problem but I can't use this analyzer. It's not the first time Vista loose all USb when I install any program related.
So after this long post, I'll continue trying to make the device works.

Thanks in advance for your time and regards, Rubén.

"Frame8: Get descriptor, Device qualifier. I add the device qualifier to enumeration, but it seems not to be relevant in device enumeration, and I delete this request and return Stall."

It's fine.
The host issues Get_Descriptor( Device qualifier ) when you set the USB version (bcdUSB) to 2.0 on the device descriptor, to examine the high-speed capability of the device. For full-speed device, stall this request, as you did. Or set the USB version to 1.1.

"Frame8: Get descriptor, Device qualifier. I add the device qualifier to enumeration, but it seems not to be relevant in device enumeration, and I delete this request and return Stall.
Frame9: Get descriptor, configuration, length = 19. I send the header functional desc., call management functional desc., abstract control management desc., and union functional descriptor.
Frame10: request again for configuration descriptor, but with length of 160 bytes (?). I send again all configuration descriptors like in F4, but I don't know if it's correct."

When the requested number of bytes is shorter than the configuration descriptor set, cut off the returned bytes just at the requested number, even if it doesn't mean the boundary of descriptors.

When the requested number is greater than the actual descriptor(s), return the whole bytes of just the descriptor(s).

"Frame13: Set control line coding"

Ah, the catchy request (Set_Line_Coding) !
You aren't the only one who was trapped by this request handling. I've seen many one who attempt to implement CDC.

I suppose this is the first control write transfer you've ever seen. Other requests are control read or no-data control transfer. That is, you have to handle just this request differently from other request in the low-level request handling (control transfer handling).

The request handling starts with the dispatch of the SETUP packet, which is common to all control transfers. If you see the control write transfer on the SETUP handling, you have to expect that the data is sent to the OUT EP of the default EP, at the next USB interrupt (DATA stage). Usually, set the state of the stack to RX at the SETUP handling.

In the next USB interrupt, seeing the RX state, read out the default OUT EP for the request parameter. Repeat this until you finish to read out the last data whose number is specified in the wLength field of the SETUP.

Then, handle the request with the parameter.
In Set_Line_Coding case, set the baudrate, data bits, parity and stop bit(s) of the UART, as specified on the parameter.

When you successfully handle the request, put a ZLP (Zero-Length Packet) to the default IN EP, as the STATUS stage. If the parameter is not supported on your device, return STALL at the IN EP.

Tsuneo

Hello Tsuneo!

Now I solved one problem, but I'm not satisfied at all...because I can't understand where were the error and there are new problems...

Related with descriptor length. Yes, I do what you comment: I send the requested length if it's lesser than configuration descriptor length, or total length of configuration descriptor, if requested length is greater. But in the case of the 19 bytes requestes, I must send header functional desc., call management functional desc., abstract control management desc., and union functional descriptor ('Class Headers' to short from now on). If I send configuration descriptor without take care of boundary, enumeration stops, and windows return error and can't use the device.

Frame 13 is 'set control line status' not 'set line coding '(it was my fault :P). Anyway, now I can read 'set line coding correctly' (thanks!) and I can see that USB send me the configuration I use in my host software. It's not important, but it makes me happy to know that it's working fine ;).

As I suspected, the problem was in the sent configuration descriptor. When I send the descriptor, it was like if the host couldn't read last endpoint descriptor (only the first one of the 2 last endpoints was working fine). I suppose that my descriptor has 67 bytes of total length, and would be a problem to send 2 frames (64 bytes + 3). I can't see the error, but I'm sure that there is the problem.

As the 'Class Headers' are requested later individually, I put them at the end of the configuration descriptor in order to get that the host made a correct reading of endpoint configuration, and it works! I can use now the 2 endpoints at same time, and windows recognize the device...but I don't know why, I can only send 2 bytes to host by EP2. EP2 is a 64 bytes IN FIFO, double-buffered. When I charge the 2 buffers, it don't send anything more to the host. Sometimes the register tells me that FIFO is full, sometimes is free to charge new data, but it doesn't matters, because don't send the next data.

Well, lots of thanks for your attention again, you're very kind. I hope this post help more people, and if you, or anybody have any idea about the new problem...I would be very grateful.

Regards! Ruben.

I monitored my CDC implementation on a hardware bus analyzer.
This is the result.

CDC-ACM (port) enumeration sequence

WinXP SP2, SP3
                        wValue  wIndex   wLen
Bus Reset
Get_Descriptor(DEVICE)  0x0100  0x0000  0x0040
Bus Reset
Set_Address               0002    0000    0000
Get_Descriptor(DEVICE)    0100    0000    0012
Get_Descriptor(CONFIG)    0200    0000    0009
Get_Descriptor(STRING)    0300    0000    00FF
Get_Descriptor(STRING)    0303    0409    00FF
Get_Descriptor(CONFIG)    0200    0000    00FF
Get_Descriptor(STRING)    0300    0000    00FF
Get_Descriptor(STRING)    0302    0409    00FF
Get_Descriptor(STRING)    0300    0000    00FF
Get_Descriptor(STRING)    0302    0409    00FF
Get_Descriptor(DEVICE)    0100    0000    0012
Get_Descriptor(CONFIG)    0200    0000    00FF
Set_Configuration         0001    0000    0000
Get_Line_Coding           0000    0000    0007
Set_Control_Line_State    0000    0000    0000
IN transaction to the Interrupt IN EP


Vista SP1
                        wValue  wIndex   wLen
Bus Reset
Get_Descriptor(DEVICE)  0x0100  0x0000  0x0040
Bus Reset
Set_Address               0002    0000    0000
Get_Descriptor(DEVICE)    0100    0000    0012
Get_Descriptor(CONFIG)    0200    0000    00FF
Get_Descriptor(STRING)    0303    0409    00FF
Get_Descriptor(STRING)    0300    0000    00FF
Get_Descriptor(STRING)    0302    0409    00FF
Get_Descriptor(DEVICE)    0100    0000    0012
Get_Descriptor(CONFIG)    0200    0000    00FF
Set_Configuration         0001    0000    0000
Get_Line_Coding           0000    0000    0007
Set_Control_Line_State    0000    0000    0000
IN transaction to the Interrupt IN EP

Other than the device_qualifier (because of in-between hub),
Frame No.9 and 10 are different from your observation.
Your frame No.9 should be Get_Descriptor(DEVICE), with wLength =18 bytes,
And No.10 Get_Descriptor(CONFIG) with wLength =255 bytes

Tsuneo

Hello, Tsuneo.

I try to install USBlyzer in another computer with Vista Business, and it seems that works (in Vista Ultimate it doesn't work rigth, because any program that try to open the port tell that it can't be open or that is already used by another telephone program).

I can see that when I try to send by EP2 IN (bulk tranfer) any data the analyzer notify:

Type---Request--------------------Request Details
URB----Bulk or Interrupt Transfer--4096
URB----Bulk or Interrupt Transfer--0

and after the second notification the Status=Unsucceful(Stall PID). Both IRP=84389C80H.

If I run program step by step, it returns the same except for the second notify:

Type---Request--------------------Request Details
URB----Bulk or Interrupt Transfer--4096
URB----Bulk or Interrupt Transfer--11

and after the second notification the Status=Success(Success).

When I look at request summary, I can see the following comments about the first bulk transfer:

USB Bulk or Interrupt Transfer issued
Device Object: USBPDO-7
Driver Object: usbhub
URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
Endpoint 82h: 2 in, Bulk
Buffer Length: 1000h (4096)

The second bulk notification when return unsuccseful:

URB Bulk or interrupt transfer failed
all is the same except for.
URB Status: USBD_STATUS_STALL_PID
and there is no Buffer Length.

The second bulk notification whem return success:

USB Bulk or Interrupt Transfer succeeded
all the same but,
URB Status: USBD_STATUS_SUCCESS
and,
Bytes Received: 11

I don't know why debugging step by step it return a different values, maybe is related with communications speed?

Why after host return Bulk transfer succeeded don't let me start another bulk transfer?

Should I notifify a new serial status?

Now I will try to get enumeration frames in the USB analyzer. I don't know the reason why Vista send me different requests than you.

Regards.

When the sniffer reports STALL on the bulk-IN EP, your firmware actually STALL the EP. I think it is a bug on the firmware.

"maybe is related with communications speed?"
"Should I notifify a new serial status?"

The bulk IN and OUT transfers of CDC is affected neither by the baudrate setting (Set_Line_Coding) nor by the Serial_State notification over the interrupt IN EP. The bulk IN and OUT transfers are controlled independently following to the USB intrinsic NAK flow-control.

Did you check your Frame No.9 and No.10 on the enumeration?

Tsuneo

Hello.

I check the frames with USb analyzer, and discover that were a problem with a configuration descriptor. Now I see that host don't ask me for a configuration descriptor of 160 Bytes, and it seems that there is no error in configuration descriptor.
Anyway the behaviour of the device it's the same.
Now, the frames I can see in the enumeration are:

 1.Get Device Descriptor   128  6  0  1  0  0 64  0
 Bus Reset
 2.Set Address              0   5  1  0  0  0 000 0
 3.Get Device Descriptor   128  6  0  1  0  0 018 0
 4.Get Configuration Des.  128  6  0  1  0  0 255 0
 5.Get String Descriptor   128  6  3  3  9  4 255 0
 6.Get String Descriptor   128  6  0  3  0  0 255 0
 7.Get String Descriptor   128  6  2  3  9  4 255 0
 8.Get Device Qualifier    128  6  0  6  0  0 010 0
 9.Get Device Descriptor   128  6  0  1  0  0 018 0
10.Get Configuration Des.  128  6  0  1  0  0 009 1
11.Get Line Coding         161 33  0  0  0  0 007 0
12.Set Control Line State   33 34  0  0  0  0 000 0

Frame Nº9 is Get Device Descriptor with length of 18, and the next Configuration descriptor with length of (109??). I thought this frame has a length of 19, and there was an error. Now I send all descriptors here and USB analyzer don't return an error.
I don't understand why I only can send the first frame, and it don't works anymore...I see in the analyzer some frames OUT in EP 2, that is configured IN (and can't work as out), and is sent from host the following data:

1B DF 08 0A 00 00 00 0E 05 20 01 00 00 00 58 13 00 00 5F 29

These frames are not always identical, but are similar...

Regards.

After spending a long time changing the code, I always get the same result:

it seems that the device send the first frame by EP2 (IN Bulk) after connecting with serial port, the length and data sent is correct.

After this frame, the 'response' is that the frame is 4096 Bytes length.

The next operation device realices is to send a frame by EP3 (IN, Interrupt) (I don't know why, I don't try to send any frame by this EP, but the Serial State when the device connects to serial Port), but the status report tells me 'USBD_STATUS_BUFFER_OVERRRUN'.

Finally, there appears another try of sending a frame by EP2 (IN, Bulk), but the status says: 'USBD_STATUS_STALL_PID'.

I'm sure there are an error in the code, when I try to send the data by EP2, but I can't see it. I try to make a 'data toggle' in EP3 some times, and it works...for one time and no more (I suppose it was a set of circumstances, a simple coincidence), but it makes me think that I'm doing something wrong in the protocol sending data? (and the device is configurated correctly).

Well, finally the problem is solved!

There was an error, after sending set_control_line_status by interrupt EP, device don't send a ZLP correctly due a firmaware error, it was all...uff...I almost go crazy :P.

Thanks for your attention, speccially for Tsuneo.

Regards.

Hi, i'm student in indonesia. i have a final project, i will develop some embedded system application that works with usb. after +-2 month i learning max3420, i still can't reply host OUT request. can you help me? can you send me your code?

thanks a lot

suriva (suriva.25 at gmail dot com)