GIGA R1: devices such as FTDI adapters with control endpoint transfer size=8 reading device descriptor does not work

[KurtE]

As I have mentioned on the forum:
https://forum.arduino.cc/t/can-not-find-examples-for-usbhostserial/1182486/17
I am trying to hack up some code similar to the USBHostSerial code that works with other USB to Serial adapters other than those which are CDC ACM devices. Ones like FTDI, Prolific...

On the forum thread: I posted an example sketch which reproduces this, but just about any sketch that will print out the
wrong IDS. VID: 0103 PID: 0000

Where other code bases on some other Arduinos, plus Windows and Ubuntu return the IDs:
vid=403 pid=6001

Note: I just tried plugging it in to the GIGA board, with my Logic Analyzer hooked up to it, with my modified USB Analyzer and HLA, which helps reduce the data down...

The Packets that I received on the GIGA:

16.308830162 ; SETUP ; 0x0 ; 0x0 ; [GET_DESCRIPTOR - DEVICE #:0 I:0x0 L:0x8] ;  0x80 0x6 0x0 0x1 0x0 0x0 0x8 0x0
16.308907428 ; IN ; 0x0 ; 0x0 ;  ;  0x12 0x1 0x0 0x2 0x0 0x0 0x0 0x8
16.308963208 ; SETUP ; 0x0 ; 0x0 ; SET_ADDRESS I:0x0 L:0x0] ;  0x0 0x5 0x1 0x0 0x0 0x0 0x0 0x0
16.317414284 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - DEVICE #:0 I:0x0 L:0x8] ;  0x80 0x6 0x0 0x1 0x0 0x0 0x8 0x0
16.317496376 ; IN ; 0x0 ; 0x1 ;  ;  0x12 0x1 0x0 0x2 0x0 0x0 0x0 0x8
20.478046968 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - DEVICE #:0 I:0x0 L:0x12] ;  0x80 0x6 0x0 0x1 0x0 0x0 0x12 0x0
20.478125602 ; IN ; 0x0 ; 0x1 ;  ;  0x12 0x1 0x0 0x2 0x0 0x0 0x0 0x8
20.478314948 ; IN ; 0x0 ; 0x1 ;  ;  0x3 0x4 0x1 0x60 0x0 0x6 0x1 0x2
20.478336022 ; IN ; 0x0 ; 0x1 ;  ;  0x3 0x1
20.502892408 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - CONFIG #:0 I:0x0 L:0x9] ;  0x80 0x6 0x0 0x2 0x0 0x0 0x9 0x0
20.503027744 ; IN ; 0x0 ; 0x1 ;  ;  0x9 0x2 0x20 0x0 0x1 0x1 0x0 0xa0
20.50305689 ; IN ; 0x0 ; 0x1 ;  ;  0x2d
20.510192198 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - CONFIG #:0 I:0x0 L:0x20] ;  0x80 0x6 0x0 0x2 0x0 0x0 0x20 0x0
20.510326864 ; IN ; 0x0 ; 0x1 ;  ;  0x9 0x2 0x20 0x0 0x1 0x1 0x0 0xa0
20.510358858 ; IN ; 0x0 ; 0x1 ;  ;  0x2d 0x9 0x4 0x0 0x0 0x2 0xff 0xff
20.510387752 ; IN ; 0x0 ; 0x1 ;  ;  0xff 0x2 0x7 0x5 0x81 0x2 0x40 0x0
20.510416558 ; IN ; 0x0 ; 0x1 ;  ;  0x0 0x7 0x5 0x2 0x2 0x40 0x0 0x0

I don't have time today, but it almost looks like the device is still only returning a max of something like 8 bytes at a time...
And You are probably indexing off the end of the data, and maybe not waiting for the additional data packets to be returned.

If I remember correctly on the Teensy USBHost code, we first asked for the device descriptor, for its first 8 bytes, and then update the control endpoint to the size specified in those first 8 bytes and then asked for the whole endpoint...

[AndrewCapon]

Are you using the most recent version from GitHub?

I had this 8 byte issue before, pretty sure using the version from GitHub fixed this.

[AndrewCapon]

I think the last setSizeControlEndpoint was not there before:

                            devices[i].setSizeControlEndpoint(8);

                            devices[i].activeAddress(false);

                            // get first 8 bit of device descriptor
                            // and check if we deal with a hub
                            USB_DBG("usb_thread read device descriptor on dev: %p\r\n", &devices[i]);
                            res = getDeviceDescriptor(&devices[i], buf, 8);

                            if (res != USB_TYPE_OK) {
                                USB_ERR("usb_thread could not read dev descr");
                                continue;
                            }

                            // set size of control endpoint
                            devices[i].setSizeControlEndpoint(buf[7]);

Without that last setSizeControlEndpoint the size sticks at 8 when the enumerate code is run.

[AndrewCapon]

Actually I think I'm wrong, I have been testing loads of midi devices and one of them returns the size requested in buf[7], so 8.

using instead:

devices[i].setSizeControlEndpoint(64);

And this device then enumerates.

[AndrewCapon]

Incorrectly it seems, ignore me!

[AndrewCapon]

Right, I think this is related to : #31 (with 8 bytes instead of 64)

The device I have here wants to deal with 8 byte packets, I guess the same as your one.

So when it tries to get the full 18 bytes to get the VID and PID, this going to require 3 packets.

The existing code should request these three packets but it doesn't work for me here:

        if ((type == EP_TYPE_BULK) || (type == EP_TYPE_CTRL)) {
            switch (urb_state) {
                case URB_DONE:
#if defined(MAX_NOTREADY_RETRY)
                    td->retry = 0;
#endif
                    if (td->size >  max_size) {
                        /*  enqueue  another request */
                        td->currBufPtr += max_size;
                        td->size -= max_size;
                        length = td->size <= max_size ? td->size : max_size;
                        HAL_HCD_HC_SubmitRequest(hhcd, chnum, dir, type, !td->setup, (uint8_t *) td->currBufPtr, length, 0);
                        HAL_HCD_EnableInt(hhcd, chnum);
                        return;
                    }
                    break;
                case  URB_NOTREADY:
#if defined(MAX_NOTREADY_RETRY)
                    if (td->retry < MAX_NOTREADY_RETRY) {
                        td->retry++;
#endif
                        // Submit the same request again, because the device wasn't ready to accept the last one
                        length = td->size <= max_size ? td->size : max_size;
                        HAL_HCD_HC_SubmitRequest(hhcd, chnum, dir, type, !td->setup, (uint8_t *) td->currBufPtr, length, 0);
                        HAL_HCD_EnableInt(hhcd, chnum);
                        return;

                        return;
#if defined(MAX_NOTREADY_RETRY)
                    } else {
                        // MAX_NOTREADY_RETRY reached, so stop trying to resend and instead wait for a timeout at a higher layer
                    }
#endif
                    break;
            }
        }

for status : 0 = URB_IDLE, 1=URB_DONE, 2 = URB_NOTREADY

So you can see the first URB_DONE, then the code requests another 8 byte packet, we get two URB_IDLE then multiple URB_NOTREADY where the code keeps retrying the last 8 bytes.

May be different there but that's what I'm seeing here.

[AndrewCapon]

I just tried a prolific one I have here but it works, it is using 64 byte packets though.

[KurtE]

I am running version 0.2.0 - and I don't see any other changes since then. Mine is slightly mucked up for debug, plus maybe forced to not simple callbacks...

Looking at the data from Logic Analyzer:

20.478046968 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - DEVICE #:0 I:0x0 L:0x12] ;  0x80 0x6 0x0 0x1 0x0 0x0 0x12 0x0
20.478125602 ; IN ; 0x0 ; 0x1 ;  ;  0x12 0x1 0x0 0x2 0x0 0x0 0x0 0x8
20.478314948 ; IN ; 0x0 ; 0x1 ;  ;  0x3 0x4 0x1 0x60 0x0 0x6 0x1 0x2
20.478336022 ; IN ; 0x0 ; 0x1 ;  ;  0x3 0x1

The line:
devices[i].setSizeControlEndpoint(buf[7]);
Set the size to 8 Valid sizes are ( 8, 16, 32, 64). Wonder if your other devices have larger values...
When it asked for 0x12 (18) bytes it did properly return 3 packets.
Combining them we have:

 0        1      2    3    4    5    6    7     8     9    10   11    12   13  14   15  16   17 
0x12 0x1 0x0 0x2 0x0 0x0 0x0 0x8 0x3 0x4 0x1 0x60 0x0 0x6 0x1 0x2 0x3 0x1

So ID vendor(bytes 8-9): 0x403 and Product: 0x601

But it returned vid 0x103... Maybe like it skipped the middle packet. Maybe assuming end point size of 16?

[AndrewCapon]

Is the device you are having trouble with returning 8 in buf[7]?

What I was seeing with midi devices was that I was never getting > 64 bytes returned, so just a single packet. I was not seeing what you are seeing there with multiple packets with the existing code. They all had 64 byte packets.

[KurtE]

Yes it is returning 0x8 in buf[7]

Where as the PL2303 device the USB data looks like:

14.689485844 ; SETUP ; 0x0 ; 0x0 ; [GET_DESCRIPTOR - DEVICE #:0 I:0x0 L:0x8] ;  0x80 0x6 0x0 0x1 0x0 0x0 0x8 0x0
14.689516876 ; IN ; 0x0 ; 0x0 ;  ;  0x12 0x1 0x10 0x1 0x0 0x0 0x0 0x40
14.689572596 ; SETUP ; 0x0 ; 0x0 ; SET_ADDRESS I:0x0 L:0x0] ;  0x0 0x5 0x1 0x0 0x0 0x0 0x0 0x0
14.691096216 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - DEVICE #:0 I:0x0 L:0x8] ;  0x80 0x6 0x0 0x1 0x0 0x0 0x8 0x0
14.691125776 ; IN ; 0x0 ; 0x1 ;  ;  0x12 0x1 0x10 0x1 0x0 0x0 0x0 0x40
17.252858628 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - DEVICE #:0 I:0x0 L:0x12] ;  0x80 0x6 0x0 0x1 0x0 0x0 0x12 0x0
17.252888864 ; IN ; 0x0 ; 0x1 ; SET_PROTOCOL(0x0xb) ;  0x12 0x1 0x10 0x1 0x0 0x0 0x0 0x40 0x7b 0x6 0x3 0x23 0x0 0x4 0x1 0x2 0x0 0x1
17.253834594 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - CONFIG #:0 I:0x0 L:0x9] ;  0x80 0x6 0x0 0x2 0x0 0x0 0x9 0x0
17.253865 ; IN ; 0x0 ; 0x1 ; 0x32(0x0x2) ;  0x9 0x2 0x27 0x0 0x1 0x1 0x0 0x80 0x32
17.254269648 ; SETUP ; 0x0 ; 0x1 ; [GET_DESCRIPTOR - CONFIG #:0 I:0x0 L:0x27] ;  0x80 0x6 0x0 0x2 0x0 0x0 0x27 0x0
17.254299062 ; IN ; 0x0 ; 0x1 ; 0x32(0x0x2) ;  0x9 0x2 0x27 0x0 0x1 0x1 0x0 0x80 0x32 0x9 0x4 0x0 0x0 0x3 0xff 0x0 0x0 0x0 0x7 0x5 0x81 0x3 0xa 0x0 0x1 0x7 0x5 0x2 0x2 0x40 0x0 0x0 0x7 0x5 0x83 0x2 0x40 0x0 0x0
17.258187612 ; SETUP ; 0x0 ; 0x1 ; [SET_CONFIGURATION I:0x0 L:0x0] ;  0x0 0x9 0x1 0x0 0x0 0x0 0x0 0x0

So it has 64 byte control packets. And retrieved the proper VID/PID...

Before it crashes... Currently in the Red blink...
But that is a different issue...

[AndrewCapon]

So with 64 byte packets here with the existing code the issue I was seeing was when the configuration data was > 64 bytes, only 64 bytes were ever returned.

Changing to using HAL_HCD_HC_SubmitRequest() to request the full amount of data, say 101 bytes then fixed this issue for me. Which is what I was going on about in the other issue.

I now have a midi device that only uses 8 byte packets, this is not working correctly at all HAL_HCD_HC_SubmitRequest() is not returning all the data with an 8 byte packet. Interestingly if I set the packet size to 64 and then request 8 times more data I get the 64 byte packets with the correct 8 bytes at the beginning of each.

At the moment for me here I'm wondering about an underlying HAL issue with 8 byte packets.

[KurtE]

Could be HAL or their library, not sure where the code is that detects that requested data exceeded the size of a packet, and then requests or waits for the right number of data packets to come back in this case and pack the data into the correct buffer...

Let alone what is there any support anywhere in this library and/or HAL when I plug in a high speed device who typically might send 512 byte packets, although I think the control endpoint stays at max 64 byte...

[AndrewCapon]

The code as it is is using the code I posted above to split the packets, this code is in this repository. So they never call HAL_HCD_HC_SubmitRequest() with greater than the packet size, they do all the work here.

This is the code I was pretty sure is not working, so I changed it to let HAL_HCD_HC_SubmitRequest() split the packets as it already does this for you and this solved my issues with 64 byte packets and everything now works. You can see what I did in the PR in the other issue: #33

Unfortunately HAL_HCD_HC_SubmitRequest() doesn't seem to be working with 8 byte packets, the top level code looks fine it is requesting the correct number of packets, something is going wrong though.

I hate USB stuff!

[AndrewCapon]

Concerning packet sizes but from the device side I also found this one: arduino/ArduinoCore-mbed#736