usbus/cdc_acm: Return stall on line coding not supported #17085
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The SetLineCoding request is optional to support (CDC PSTN subclass). No need to claim to support it to the host and actually discard the data if it is not supported by the implementation.
github-actions
bot
added
Area: sys
bergzand
added
CI: ready for build
bergzand
added
the
Type: enhancement
fjmolinas
reviewed
Nov 2, 2021
|
Have a packet dump from what I see on my side then: |
|
Thanks! |
bors bot
added a commit
that referenced
this pull request
Mar 9, 2023
17086: usbdev: Add dedicated stall functions r=benpicco a=bergzand ### Contribution description This PR adds dedicated stall functions for usbdev peripherals. Two functions are added. The first function (usbdev_ep_stall) to enable and disable the stall condition on generic endpoints. The second function is a dedicated function to set the stall condition on endpoint zero in both directions. This status can only be set and should automatically be cleared by the usbdev implementation (or hardware) after a new setup request is received from the host. ### Testing procedure - examples/usbus_minimal should still enumerate correctly on the host side. - #17085 can be used to demonstrate the ep0_stall function with the `tests/usbus_cdc_acm_stdio/` test ### Issues/PRs references None Co-authored-by: Koen Zandberg <[email protected]> Co-authored-by: Gunar Schorcht <[email protected]>
bors bot
added a commit
that referenced
this pull request
Mar 10, 2023
17086: usbdev: Add dedicated stall functions r=benpicco a=bergzand ### Contribution description This PR adds dedicated stall functions for usbdev peripherals. Two functions are added. The first function (usbdev_ep_stall) to enable and disable the stall condition on generic endpoints. The second function is a dedicated function to set the stall condition on endpoint zero in both directions. This status can only be set and should automatically be cleared by the usbdev implementation (or hardware) after a new setup request is received from the host. ### Testing procedure - examples/usbus_minimal should still enumerate correctly on the host side. - #17085 can be used to demonstrate the ep0_stall function with the `tests/usbus_cdc_acm_stdio/` test ### Issues/PRs references None Co-authored-by: Koen Zandberg <[email protected]> Co-authored-by: Gunar Schorcht <[email protected]>
|
@bergzand I have some trouble with this change when CDC ACM is used with a STM32 USB OTG HS core. It seems that the STALL condition is not automatically reset with the next SETUP, at least the USB device driver and therefore also the USBUS don't receive SETUPs anymore and subsequent SETUPs are answered with broken pipe error. This can be observed for example when using CDC ACM together with CDC ECM: In this case, the enumeration stops after EP0 was set to STALL on In Wireshark it can be observed that the result packet as response to the I can't say for sure yet if it's a bug of the USB OTG HS core in STM32. It might also be that in only happens in DMA mode because tinyUSB uses the USB OTG HS core in non-DMA mode and is working without any problems. It's quite difficult to debug or use printf due to critical timings. The problem is that CDC ACM advertises in So unless there was a situation where it didn't work without that change, I would suggest to revert that change. |
It seems to be related to DMA mode since it works for |
This was referenced Mar 11, 2023
bors bot
added a commit
that referenced
this pull request
Mar 14, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=kaspar030 a=gschorcht ### Contribution description This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device. #### Background In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work. #### Solution Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert. ### Testing procedure 1. Green CI 2. Compilation of ```python USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm ``` should lead to compilation error ```python sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded" _Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS, ^~~~~~~~~~~~~~ Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed ``` while compilation of ``` USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm ``` should work. ### Issues/PRs references Fixes issue #19359 partially. 19382: tests/pkg_nanors: use static allocation r=kaspar030 a=benpicco 19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=kaspar030 a=gschorcht ### Contribution description This PR disables the DMA mode for HS cores due to several problems found: - The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in #17085 (comment) - The Enumeration fails for CDC ECM interface which uses URB support (PR #17091) ### Testing procedure Use a STM32 board with USH OTG HS interface: ```python USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash ``` Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`) ```python [377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd [377629.854349] usb 1-2.3: device descriptor read/all, error -71 [377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd [377630.038261] usb 1-2.3: device descriptor read/all, error -71 [377630.038711] usb 1-2-port3: attempt power cycle [377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd [377630.666066] usb 1-2.3: device descriptor read/8, error -71 [377630.794076] usb 1-2.3: device descriptor read/8, error -71 [377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd [377631.002092] usb 1-2.3: device descriptor read/8, error -71 [377631.130091] usb 1-2.3: device descriptor read/8, error -71 [377631.238344] usb 1-2-port3: unable to enumerate USB device ``` or the enumeration of the CDC ECM interface stops with error. ```python [377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd [377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [377972.929230] usb 1-2.3: Product: stm32f723e-disco [377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org [377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32 [377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd ``` With this PR the enumeration should work as it should: ```python [378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd [378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd [378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [378484.395301] usb 1-2.3: Product: stm32f723e-disco [378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org [378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba [378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0 ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <[email protected]> Co-authored-by: Benjamin Valentin <[email protected]>
bors bot
added a commit
that referenced
this pull request
Mar 14, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=kaspar030 a=gschorcht ### Contribution description This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device. #### Background In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work. #### Solution Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert. ### Testing procedure 1. Green CI 2. Compilation of ```python USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm ``` should lead to compilation error ```python sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded" _Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS, ^~~~~~~~~~~~~~ Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed ``` while compilation of ``` USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm ``` should work. ### Issues/PRs references Fixes issue #19359 partially. 19382: tests/pkg_nanors: use static allocation r=kaspar030 a=benpicco 19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=kaspar030 a=gschorcht ### Contribution description This PR disables the DMA mode for HS cores due to several problems found: - The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in #17085 (comment) - The Enumeration fails for CDC ECM interface which uses URB support (PR #17091) ### Testing procedure Use a STM32 board with USH OTG HS interface: ```python USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash ``` Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`) ```python [377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd [377629.854349] usb 1-2.3: device descriptor read/all, error -71 [377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd [377630.038261] usb 1-2.3: device descriptor read/all, error -71 [377630.038711] usb 1-2-port3: attempt power cycle [377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd [377630.666066] usb 1-2.3: device descriptor read/8, error -71 [377630.794076] usb 1-2.3: device descriptor read/8, error -71 [377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd [377631.002092] usb 1-2.3: device descriptor read/8, error -71 [377631.130091] usb 1-2.3: device descriptor read/8, error -71 [377631.238344] usb 1-2-port3: unable to enumerate USB device ``` or the enumeration of the CDC ECM interface stops with error. ```python [377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd [377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [377972.929230] usb 1-2.3: Product: stm32f723e-disco [377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org [377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32 [377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd ``` With this PR the enumeration should work as it should: ```python [378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd [378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd [378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [378484.395301] usb 1-2.3: Product: stm32f723e-disco [378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org [378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba [378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0 ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <[email protected]> Co-authored-by: Benjamin Valentin <[email protected]>
bors bot
added a commit
that referenced
this pull request
Mar 14, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=kaspar030 a=gschorcht ### Contribution description This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device. #### Background In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work. #### Solution Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert. ### Testing procedure 1. Green CI 2. Compilation of ```python USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm ``` should lead to compilation error ```python sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded" _Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS, ^~~~~~~~~~~~~~ Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed ``` while compilation of ``` USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm ``` should work. ### Issues/PRs references Fixes issue #19359 partially. 19382: tests/pkg_nanors: use static allocation r=kaspar030 a=benpicco 19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=kaspar030 a=gschorcht ### Contribution description This PR disables the DMA mode for HS cores due to several problems found: - The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in #17085 (comment) - The Enumeration fails for CDC ECM interface which uses URB support (PR #17091) ### Testing procedure Use a STM32 board with USH OTG HS interface: ```python USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash ``` Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`) ```python [377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd [377629.854349] usb 1-2.3: device descriptor read/all, error -71 [377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd [377630.038261] usb 1-2.3: device descriptor read/all, error -71 [377630.038711] usb 1-2-port3: attempt power cycle [377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd [377630.666066] usb 1-2.3: device descriptor read/8, error -71 [377630.794076] usb 1-2.3: device descriptor read/8, error -71 [377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd [377631.002092] usb 1-2.3: device descriptor read/8, error -71 [377631.130091] usb 1-2.3: device descriptor read/8, error -71 [377631.238344] usb 1-2-port3: unable to enumerate USB device ``` or the enumeration of the CDC ECM interface stops with error. ```python [377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd [377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [377972.929230] usb 1-2.3: Product: stm32f723e-disco [377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org [377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32 [377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd ``` With this PR the enumeration should work as it should: ```python [378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd [378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd [378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [378484.395301] usb 1-2.3: Product: stm32f723e-disco [378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org [378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba [378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0 ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <[email protected]> Co-authored-by: Benjamin Valentin <[email protected]>
bors bot
added a commit
that referenced
this pull request
Mar 15, 2023
19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=gschorcht a=gschorcht ### Contribution description This PR disables the DMA mode for HS cores due to several problems found: - The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in #17085 (comment) - The Enumeration fails for CDC ECM interface which uses URB support (PR #17091) ### Testing procedure Use a STM32 board with USH OTG HS interface: ```python USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash ``` Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`) ```python [377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd [377629.854349] usb 1-2.3: device descriptor read/all, error -71 [377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd [377630.038261] usb 1-2.3: device descriptor read/all, error -71 [377630.038711] usb 1-2-port3: attempt power cycle [377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd [377630.666066] usb 1-2.3: device descriptor read/8, error -71 [377630.794076] usb 1-2.3: device descriptor read/8, error -71 [377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd [377631.002092] usb 1-2.3: device descriptor read/8, error -71 [377631.130091] usb 1-2.3: device descriptor read/8, error -71 [377631.238344] usb 1-2-port3: unable to enumerate USB device ``` or the enumeration of the CDC ECM interface stops with error. ```python [377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd [377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [377972.929230] usb 1-2.3: Product: stm32f723e-disco [377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org [377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32 [377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd ``` With this PR the enumeration should work as it should: ```python [378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd [378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd [378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [378484.395301] usb 1-2.3: Product: stm32f723e-disco [378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org [378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba [378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0 ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
The SetLineCoding request is optional to support (CDC PSTN subclass). No
need to claim to support it to the host and actually discard the data if
it is not supported by the implementation.
Testing procedure
Running the
tests/usbus_cdc_acm_stdio/case, use a serial console to change the baud rate. This should still work. Bonus points for sniffing the USB traffic with wireshark, that should look like this:Main thing is the "Broken pipe" in the reply packet which indicates a stall from the device side.
Issues/PRs references
None