USB GET_CONFIG short resp

Hi I’m using a NxpK66 with USB Host mode to enumerate the Photons USB.
So when it does the first GET_CONFIG request it seems that the Photon’s response is a truncated message.
So send USB Host request
80 6 0 1 0 0 12 0 - GET_CONFIG on addr=0 and endpoint=0
Response is 8bytes … even though the first byte says it is 0x12bytes long.
12 01 00 02 02 00 00 40

Also same if
80 6 0 1 0 0 40 0 - GET_CONFIG on addr=0 and endpoint=0
Response is only 8bytes … even though the first byte says it is 0x12byes long.
12 01 00 02 02 00 00 40
So I was wondering if this was known about ?
(its actually messing with my host software processing and trying to figure what is wrong.)

Further along the enumeration process, when the address has been set, the Photon does do a full response to the same request

Host 80 06 00 01 00 00 12 00 GET_CONFIG request
Photon Resp 12 01 00 02 02 00 00 40 04 2B 06 C0 00 02 01 02 03 01 - full -0x12 bytes response


First of all, I assume by GET_CONFIG you mean GET_DESCRIPTOR with bDescriptorType = 1 (DEVICE).

The Device descriptor length is indeed 0x12 bytes and that value does not change within the descriptor (bLength field):

/* USB Standard Device Descriptor */
uint8_t USBD_DeviceDesc[USB_SIZ_DEVICE_DESC] =
        0x12,                       /*bLength */
        USB_DEVICE_DESCRIPTOR_TYPE, /*bDescriptorType*/
        0x00,                       /*bcdUSB */
        0xef,                       /*bDeviceClass: Misc */
        0x02,                       /*bDeviceSubClass*/
        0x01,                       /*bDeviceProtocol*/
        USB_OTG_MAX_EP0_SIZE,       /*bMaxPacketSize*/
        LOBYTE(USBD_VID_SPARK),     /*idVendor*/
        HIBYTE(USBD_VID_SPARK),     /*idVendor*/
        LOBYTE(USBD_PID_CDC),       /*idProduct*/
        HIBYTE(USBD_PID_CDC),       /*idProduct*/
        LOBYTE(0x0250),             /*bcdDevice (2.50) */
        HIBYTE(0x0250),             /*bcdDevice (2.50) */
        USBD_IDX_MFC_STR,           /*Index of manufacturer  string*/
        USBD_IDX_PRODUCT_STR,       /*Index of product string*/
        USBD_IDX_SERIAL_STR,        /*Index of serial number string*/
        USBD_CFG_MAX_NUM            /*bNumConfigurations*/
} ; /* USB_DeviceDescriptor */

However during enumeration the Host may not request more than 8 bytes at first, because it does not yet know the maximum transfer length for endpoint 0 (bMaxPacketSize0). Why 8 bytes? Because the eighth byte in the Device descriptor is exactly bMaxPacketSize0 and also it’s the minimum value for bMaxPacketSize0 for FS USB.

So, the usual sequence to get device descriptor looks like this:

  • GET_DESCRIPTOR(1) wLength = 0x08 (which may also be set to 0x40 - maximum, but devices usually reply with only 8 bytes)
  • Learn device bMaxPacketSize0 and bLength of Device descriptor
  • bMaxPacketSize0 is configured on the Host controller for EP0 of the device (somehow; I’m not too familiar with USB Host Controllers)
  • (I believe a RESET is usually sent here)
  • GET_DESCRIPTOR(1) (depending on bMaxPacketSize0 this might be split into several transactions)
  • A full device descriptor is returned

Also, it’s within spec of USB that the device may respond with less data than requested in wLength field of SETUP packet, since the host may only specify the maximum transfer length.

Again, this is all written in context of Full Speed USB.


Yes - GET_DESCRIPTOR with bDescriptorType = 1 (DEVICE)
Thankyou for the explanation.
We’ve got a couple of people doing an open source Host on the Teensy3x, and having a discussion about what is the way that the USB spec requires enumeration. So appreciate the explanation.
I have it enumerating the Photon now - still working to getting full CDC_ACM
The purpose is to be able to use the USB as plug’n’play serial CDC_ACM from Freescale K66/Teensy36 to Photon/Electron
That is I currently have serial channel on the Photon over a uart working, and I propose to switch that to the USB channel.
I propose to internally test it from a win10 ComPort to verify the processing on the Photon.
Then emulate that on the K66/Teesny36
Do you see any problems with that or anything I should know?
Many thanks