USB Ch 9 Set Configuration (1) fails following Set Configuration (0)

[GrantMTG]

Operating System

Windows 10

Board

STM32F103BluePill

Firmware

Stock firmware example for stm32f103bluepill. HID example. File in question is usbd.c.

This is an uninformed guess, but if the Assert is removed, the test passes. I apologize if I don't understand the care and feeding of TU_ASSERT.

       case TUSB_REQ_SET_CONFIGURATION:
        {
          uint8_t const cfg_num = (uint8_t) p_request->wValue;

// GB:          if ( !_usbd_dev.cfg_num && cfg_num ) TU_ASSERT( process_set_config(rhport, cfg_num) );
          _usbd_dev.cfg_num = cfg_num;

          tud_control_status(rhport, p_request);
        }
        break;

What happened ?

This operation should be host and OS agnostic. Normally the firmware enumerates fine, but I must pass USB Command Verifier which performs some basic mandatory tests. The test is getting derailed fairly early on, so hopefully this isn't too hard to figure out.

I am running the stock HID example through the USB.org USB CV 2.0 (since that's what I have). It seems one of the early tests fails where the Set Configuration is issued a few times. From cold boot to startup, going from the defaults to Set Configuration (1) works OK, but if then Set Configuration (0) is sent and followed by Set Configration (1), then that last command stalls. See captures.

How to reproduce ?

1. Grab any of the USB.org test applications for your host.
2. Run the Chapter 9 automated tests on the stm32f103bluepill firmware/hardware (I'm guessing any TinyUSB firmware).
3. The test should fail right after the Descriptor Tests when it tries to run Configuration tests. Failure, with assert present: Success, with assert commented out.

Debug Log

No response

Screenshots

No response

[hathach]

thank for your PR, I am able to reproduce the issue. The configuration switching requires an extra works with additional dcd API to make sure it is working correctly. Although it is possible to cheat the test since we only have 1 configuration, it is still better to implement it properly. I will try to get the stack fully passed the USBCV compliance test asap, so stay tuned.

PS: I did fixed an TD 9.4 test as well which is easier.

[hathach]

getting it passed for now with a new empty API. There is a really stretch test with 150 enumerations with CV, really nice thing

Now Starting Test: TD 9.16 - Enumeration Test(repeat 150 times)
Start time: Aug 26, 2021 - 17:13:02
Device speed is Full.
Beginning enumeration test with 150 enumerations.  This may take several minutes to complete.
......................... 25 enumerations
......................... 50 enumerations
......................... 75 enumerations
......................... 100 enumerations
......................... 125 enumerations
......................... 150 enumerations
Enumerated 150 iterations.
Device tree re-enumerated.
Recovered Device Under Test after device tree re-enumeration.
Device speed of Device Under Test: Full Speed.

[GrantMTG]

Thank you for your hard work and time! It is a nice tool. Just a heads up, I also will be running the HID View test as well.

[hathach]

chapter 9 and hid test is all passed ( i am testing on nrf52840), trying to get it passed msc just now https://github.com/hathach/tinyusb/tree/usbcv-compliant-test

[GrantMTG]

Great job! And fast. I think it will be a badge of honour to add this to your features list. A new bullet point. :-)

[hathach]

1058 get the stack passed the 3 test suite: chapter9, hid, msc, but I only did the test and update to my frequent used nRF52840 mcu. I haven't tested the stm32f1 just yet though you could give it a try. We will eventually get there #1059 will keep track of compliance status of all ports.