Synopsis OTG_FS controller - how raw data are processed ?

[M G_2]

Dear Community,

I was trying to make composite USB2.0 device (FullSpeed) consisting of a UVC and HID component. Both the components I’ve tested before as a standalone device successfully. However after making a composite device accordingly to the HID-CDC example in the STM32F105/7xx, STM32F2xx and STM32F4xx USB On-The-Go Host and Device Library I found myself lost. Using a hardware USB analyzer (and some help from OSR community)  I found so far that after receiving the composite device descriptor by the PC host a class request (0x0A) failed with the USB analyzer message: �?The device was not able to process this request. At least one transaction contains a STALL token, which means that the device did not expect this request. “

The payload of the failing class request is:

0x21 0x0A 0x00 0x00 0x02 0x00 0x00 0x00

Accordingly to usb in a nutshell  (https://www.beyondlogic.org/usbnutshell/usb6.shtml) this means it is a class request for the device having the bRequest  value: 0x0A.(USB_REQ_GET_INTERFACE) which should either be dispatched into the video class driver or hid class driver.

Since it is to me not clear how the Synopsis FS_OTG core inside the Stm32F407 is processing the raw data from the bus I would be very glad if someone could post a link with information regarding this.

[waclawek.jan · Accepted solution]

This has nothing to do with the OTG module as such: is a Setup packet, arriving at Endpoint 0, and you have been obviously already successfully received and handled the same Setup packets for Set address, Device descriptor and Configuration descriptor. So just follow the way how Setup packets are handled and dispatched in the software.

I don't Cube so can't help with the details.

JW

[M G_2]

Dear Jan,

thank you very much -   clarifying the fact, that setup packets are arriving at ep0 and thus passing the USB stacks internal mechanism:

               DCD_HandleSof_ISR(pdev) ->

               static uint8_t USBD_SetupStage(USB_OTG_CORE_HANDLE *pdev)->

               static void USBD_GetDescriptor(USB_OTG_CORE_HANDLE *pdev, USB_SETUP_REQ *req) ->

               class request GetCfgDesc…

 allowed me to track this particular setup packet which finally lead me to the fact, that USBD_ITF_MAX_NUM was not updated to the new number of interfaces used.  Thus it is clear that while the device is at the setup level the 8bytes of data is arriving inside the USB_OTG_GINTSTS_TypeDef struct and can be analyzed there without any further knowledge about the synopsis core.

Best Regards,

Matthias