dcd_synopsys (STM32F4) doesn't work when USB descriptor exceeds 64 bytes

[majbthrd]

Describe the bug

In device examples where CONFIG_TOTAL_LEN in usb_descriptors.c exceeds 64 bytes, the host is unable to retrieve the USB descriptor.

Set up (please complete the following information):

• OS: Ubuntu 18.04
• Board: stm32f407disco
• Firmware Code: examples/device/cdc_dual_port, examples/device/net_lwip_webserver

To Reproduce

compile code, download to target, and plug it in

[cr1901]

This sounds like a regression; HID descriptors worked fine in the past and they exceeded 64 bytes.

[hathach]

yeah this is unusual, the cdc msc example descriptor will certainly exceed the 64 bytes in length. This probably related to other issue.

[duempel]

@majbthrd I think this problem could be related to the hardware you are using. Your used STM32F407 has two individual USB peripherals. One FS and the other one HS. I checked out the discovery board and noticed it's using only the USB_OTG_FS. This one is only capable of using 3 bidirectional endpoints (excluding EP0).

I checked the dual CDC example with a similar USB_OTG_FS controller and logged some packets:
The configuration is EP1 for CDC1 control, EP2 for CDC1 data, EP3 for CDC2 control and EP4 for CDC2 data. After the SET CONFIGURATION request from host, device responses with USBD_SET_CONFIG_FAILED. My Windows 10 system tries to set this configuration three times. After the 3rd time it does not request the device anymore:

I guess setting the configuration will fail at this point, since the hardware does not support EP4. Maybe it would be a good idea to skip building cdc_dual_ports exmaple for this board.

But I don't have an idea why the net class does not work correctly. It gets enumeration correctly and windows seems to use the right driver. But then it takes 10 seconds to answer the host request. I would appreciate any help to solve this problem.

[cr1901]

I don't have an STM32F4 anymore to test- @majbthrd, is it possible you can do a bisect to figure out when this issue was introduced?

[hathach]

ah @duempel is spot-on the cdc dual ports use more endpoints than STM32F407 can support. @majbthrd I think we can close this issue now.

@duempel dcd synopsys doesnt work well with usbnet as stated here #289 . You should post there with log/screenshot for further discussion.

[majbthrd]

Thanks @duempel. Your observation is a classic reminder of how correlation is not necessarily causation. Just because both problem projects had descriptors larger than 64 bytes didn't necessarily mean that this was the cause.

@cr1901, for the above reason, I'm not sure it is actually a regression.

I'll post some log information on #289; the problem appears to be the handling of tud_control_xfer()?

[hathach]

Thanks @duempel. Your observation is a classic reminder of how correlation is not necessarily causation. Just because both problem projects had descriptors larger than 64 bytes didn't necessarily mean that this was the cause.

@cr1901, for the above reason, I'm not sure it is actually a regression.

I'll post some log information on #289; the problem appears to be the handling of tud_control_xfer()?

this should be easily catches if LOG is enabled, the stack will throw an assert when it couldn't able to open an endpoint from dcd. I will add an LOG reminder for bug report.

[pigrew]

It was a few weeks ago, but my analysis (of the network example problem) was that the IRQ remained asserted after the ISR was executed, so it got in into an infinite loop of calling the ISR. I wasn't able to debug it any further than that.

I don't think there are many (any?) TU_LOG in the ISR (it's probably a bad idea...) I'm not sure that logging would help. I don't remember seeing anything out of the ordinary in the LOG=2 results.

[hathach]

It was a few weeks ago, but my analysis (of the network example problem) was that the IRQ remained asserted after the ISR was executed, so it got in into an infinite loop of calling the ISR. I wasn't able to debug it any further than that.

I don't think there are many (any?) TU_LOG in the ISR (it's probably a bad idea...) I'm not sure that logging would help. I don't remember seeing anything out of the ordinary in the LOG=2 results.

Yeah, leaving LOG within ISR even with level10 and rtt/swo is not that useful. Normally we only want to know an register value at specific location when troubleshooting. probably we just add bunch of printf() when troubleshooting with rtt/swo in isr would be ok for now. We will see if we should have LOG_ISR() with DEUBG = 10