Support for TUSB_REQ_FEATURE_TEST_MODE

[shuchitak]

Describe the PR
Adds support for TUSB_REQ_FEATURE_TEST_MODE feature in usbd.c

Additional context
Added callback functions tud_test_mode_req_status_xfer_cb(), usbd_set_test_mode() and dcd_set_test_mode() that are
called to transition the USB device into the electrical compliance test mode.

[Rocky04]

I was also working on a test mode support for TinyUSB. 😃 You can check it out here: #2416
Maybe we can work together so that this feature can be added.

My comments about your implementation:

• According to the USB 2.0 specification the behavior of the device is not specified if wLength is non-zero. So there should be no reason to filter for that. So I think it's better to just ignore it.
• TinyUSB should not acknowledge the request and rather stall it if the specific test mode isn't supported. Like there is no hardware support for GigaDevice MCUs (at least for the ones I'm working with). So the support needs to be emulated in host mode. Then it's possible that may only some modes are manually implemented.
• It seems you forgot the call to enter the test mode when the request is handled. I would expect that the callback would call it. I don't see why this should depend on a specific implementation. Only dcd_set_test_mode would be MCU related.
• The test mode selector from the request isn't stored anywhere so the callback wouldn't be aware which one should be entered. I forgot that the request is passed through.

I like the control callback handling, better than my event workaround.

[shuchitak]

I was also working on a test mode support for TinyUSB. 😃 You can check it out here: #2416 Maybe we can work together so that this feature can be added.

My comments about your implementation:

• According to the USB 2.0 specification the behavior of the device is not specified if wLength is non-zero. So there should be no reason to filter for that. So I think it's better to just ignore it.
• TinyUSB should not acknowledge the request and rather stall it if the specific test mode isn't supported. Like there is no hardware support for GigaDevice MCUs (at least for the ones I'm working with). So the support needs to be emulated in host mode. Then it's possible that may only some modes are manually implemented.
• It seems you forgot the call to enter the test mode when the request is handled. I would expect that the callback would call it. I don't see why this should depend on a specific implementation. Only dcd_set_test_mode would be MCU related.
• The test mode selector from the request isn't stored anywhere so the callback wouldn't be aware which one should be entered. I forgot that the request is passed through.

I like the control callback handling, better than my event workaround.

Hi @Rocky04, I saw your PR. I agree with your comments about not handling wLength=0 and returning stall if the device doesn't handle test mode.
I had handled the transition to test mode in a callback function since that involved adding fewer lines of code. I'd confirmed with my device that this scheme was working.
I'm happy to close this PR and continue with yours. I'll pull your changes and confirm that the test modes work as expected on my device. Thanks!

[Rocky04]

I borrowed some of your ideas and already changed my implementation.

The entering of the test mode needs to be done after the request has finished. Using the control complete callback is a great way of ensuring that. Otherwise the device is in the test mode before the host got the acknowledgement. So that the test mode already took over the signaling and the host request times out.

I already saw people who do signaling tests only relying on the shown status of the compliance tool. They thought it was working only because the tool stated a success even the device never actually entered the test mode, only because the device blindly acknowledged the request.

[shuchitak]

Closing since duplicate of #2416