Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sys/usbus: usbus_cdc_ecm does not work together with usbus_cdc_acm for STM32 #19359

Closed
gschorcht opened this issue Mar 7, 2023 · 9 comments · Fixed by #19397
Closed

sys/usbus: usbus_cdc_ecm does not work together with usbus_cdc_acm for STM32 #19359

gschorcht opened this issue Mar 7, 2023 · 9 comments · Fixed by #19397
Assignees

Comments

@gschorcht
Copy link
Contributor

Description

The combination of USBUS CDC ECM and CDC ACM interface does not work for different STM32 MCUs. It doesn't work for:

  • STM32F429ZI FS interface (CID 1100)
  • STM32F439ZI FS interface (CID 1200)
  • STM32F723IE HS interface (CID 3100)
  • STM32F746NG HS interface (CID 2100)

For these MCUs, the enumeration of the CDC ECM interface fails:

[224862.292833] usb 1-2.2: Product: nucleo-f439zi
[224862.292835] usb 1-2.2: Manufacturer: RIOT-os.org
[224862.292836] usb 1-2.2: SerialNumber: DC4DB8B40086FC7A
[224862.305285] cdc_acm 1-2.2:1.0: ttyACM1: USB ACM device
[224867.487946] cdc_ether: probe of 1-2.2:1.2 failed with error -22
...
[225333.844310] usb 1-4.1: Product: stm32f723e-disco
[225333.844311] usb 1-4.1: Manufacturer: RIOT-os.org
[225333.844313] usb 1-4.1: SerialNumber: A6BAC4E1B1E0806B
[225333.847348] cdc_acm 1-4.1:1.0: ttyACM1: USB ACM device
[225339.028774] cdc_ether: probe of 1-4.1:1.2 failed with error -32

It works for:

  • STM32F723IE FS interface (CID 3000)
  • STM32F746NG FS interface (CID 2000)
  • STM32F767ZI FS interface (CID 2000)

For the FS interfaces it could be related to the 1.x Core version while the problem for the HS interfaces could be HS interface driver. tests/usbus_cdc_ecm works for all MCUs (for the HS interface PR #19358 is required).

The problem was already given before the cpu/stm32/periph/usbdev_otg.c was moved as modified version to drivers/usbdev_synopsys_dwc2 (see branch 2022.07).

Steps to reproduce the issue

  1. Checkout PR sys/usbus/cdc/ecm: fix High-Speed mode #19358
  2. Use any of the following commands
     USEMODULE=stdio_cdc_acm BOARD=stm32f429i-disc1 make -j8 -C tests/usbus_cdc_ecm flash
     USEMODULE=stdio_cdc_acm BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm flash
     USEMODULE='periph_usbdev_hs_ulpi stdio_cdc_acm' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm/ flash
     USEMODULE='periph_usbdev_hs_utmi stdio_cdc_acm' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
    

Expected results

Actual results

Versions

@dylad
Copy link
Member

dylad commented Mar 7, 2023

I don't own any of these boards but I'll have a look at #19358 tonight as it seems pretty straightforward.

@gschorcht
Copy link
Contributor Author

I found the problem for

  • STM32F429ZI FS interface (CID 1100)
  • STM32F439ZI FS interface (CID 1200)

The FS core of these MCUs has only 4 IN endpoints and 4 OUT endpoints including the control endpoint EP0. However, the combination of CDC ACM and CDC ECM requires 5 IN and 4 OUT endpoints including the control endpoint EP0. Therefore, the IN endpoint used for CDC ECM data is NULL when determined via the usbdev_new_ep driver function here.

From my point of view, if the number of endpoints is not sufficient, it should not be silently ignored and cause a non-working application. Rather, should cause an assertion as it is a configuration issue.

@gschorcht
Copy link
Contributor Author

Hm, assert is a bit difficult if stdio_cdc_acm is used as STDIO. There should be at least an error message.

@bergzand
Copy link
Member

bergzand commented Mar 7, 2023

I agree that this should output something, either on the usbdev or preferably on the usbus side. This is imho a more generic issue as this doesn't only occur with the combination of functions mentioned here, but with any combination exceeding the hardware limit.

@gschorcht
Copy link
Contributor Author

I also found the reason for these MCUs:

  • STM32F723IE HS interface (CID 3100)
  • STM32F746NG HS interface (CID 2100)

If the usb_reset_board module is used, it works for these MCUs. The problem is that the host sends a SET LINE CODING request to the CDC ACM interface, but this is not supported if usb_reset_board is not enabled. In this case, the control handler of the CDC ACM interface simply returns -1 here, which should result in a STALL, but the enumeration just stops on the host side. Unfortunately, I don't have a logic analyzer that can sample 480 Mbps USB high-speed signals.

But when I use USB FS interface, for example a nucleo-f767zi board, the enumeration for the CDC ECM continues only after a 5 seconds timeout if usb_board_reset isn't enabled, but continues immediately within milliseconds if usb_board_reset is enabled. On the bus the USB core just NAKs the OUT data transfers continuously for the SET LINE CODING request until this 5 seconds timeout.

@gschorcht
Copy link
Contributor Author

On the bus the USB core just NAKs the OUT data transfers continuously for the SET LINE CODING request until this 5 seconds timeout.

Hm, STALL is generate only for IN data transfers here but SET LINE CODING causes an OUT data transfer. IMHO, we have to set the STALL for either the IN or the OUT endpoint here dependent on the direction of the SETUP.

bors bot added a commit that referenced this issue Mar 10, 2023
19362: sys/usbus: handle exceeding number of endpoints r=dylad a=gschorcht

### Contribution description

This PR fixes issue #19359 for STM32 USB OTG cores partially:
1. It must not be silently ignored if the number of endpoints is not sufficient for an application. Instead of producing a non-working application, the application stops now with `kernel_panic` if the number of EPs is exhausted. This fixes the problem described in issue #19359 for USB cores with CID version 1.x, e.g. for STM32F439ZI FS interface (CID 1200) since they only have 4 IN and 4 OUT endpoints including the control endpoint EP0.
2. [Update: this part was fixed by PR #17086] ~If a feature is not supported, the device has to signal a STALL on the endpoint that should be used for the data phase in a control transaction. This means that for control read transactions the IN endpoint must signal a STALL and for control write transactions the OUT endpoint must signal a STALL. In former implementation, only the IN endpoint signaled a STALL independent on whether it was a control read or control write transaction. The change also fixes the problem that the enumeration stopped for about 5 seconds if module `usb_reset_board` isn't used. The reason is that the host sends a `SET LINE CODING` request to the CDC ACM interface and the device must signal a STALL on the OUT endpoint if it is not supported.~

### Testing procedure

1. Use a STM32 board with USB OTG version 1.x, for example a `nucleo-f439zi`:
   ```
   USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm flash
   ```
   Without this PR, the application seems to run but the CDC ECM interface is not working. The `ping` command can't be executed. With this PR, the application stops with `kernel_panic`. Because `stdio_cdc_acm` is used which doesn't work in this case, the `kernel_panic` has to be observed in debugger.
   ```
   USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm debug
   ```
2. [Update: this part was fixed by PR #17086] ~Use a STM32 board with USB OTG version 2.x and USB FS connector, for example a `nucleo-f767zi`:
   ```
   USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm flash
   ```
   Without this PR a delay of 5 seconds in enumeration of the CDC ACM interface can be observed before the CDC ECM interface is enumerated. With this PR there is no delay anymore.~

### Issues/PRs references

Fixes issue #19359 patially.

Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
bors bot added a commit that referenced this issue Mar 10, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=dylad 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.

Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
bors bot added a commit that referenced this issue Mar 10, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=dylad 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.

Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
bors bot added a commit that referenced this issue Mar 10, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=benpicco 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.

19374: makefiles/boards/stm32: fix DFU_USB_ID handling r=benpicco a=gschorcht

### Contribution description

This PR fixes the still existing problem that an application can't be flashed to a STM32 board if it uses `riotboot_dfu` with default  VID/PID (1209:7d02).

In PR #18964 item 1, the problem was already described that an application can't be flashed on a board that is using `riotboot_dfu`. Using for example
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util all riotboot/flash-slot0
```
always leads to error
```python
/home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/makefiles/boards/stm32.inc.mk:28: *** DFU_USB_ID is not set.  Stop.
/home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/makefiles/boot/riotboot.mk:87: recipe for target 'riotboot/bootloader/binfile' failed
```
even if `DFU_USB_ID` variable is set as described in documentation.
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util DFU_USB_ID=1209:7d02 all riotboot/flash-slot0
```
The reason is that the variable `DFU_USB_ID` isn't exported and the check https://github.com/RIOT-OS/RIOT/blob/8dc8bf35678493ecc8ef110e2f0359a67c03894c/makefiles/boards/stm32.inc.mk#L27-L29 sees an empty `DFU_USB_ID` variable here. It prevents to use `dfu-util` event though the following `dfu-util.mk` will generate a default value for this variable from the `USB_VID` and `USB_PID` variables if necessary.

Commit 6a76b94 of PR #18964 tried to fix this problem but wasn't merged for any reason.

To fix this problem, the check is completely removed. If a board such as `weact-f4x1cx` uses a DFU boorloader and requires a certain VID/PID combination, board's makefile is responsible to set `DFU_USB_ID` variable.

### Testing procedure

It is not necessary to use a real boad, checking the compilation process is sufficient.

1. Using default VID/PID as described in documentation:
   ```python
   FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
   PROGRAMMER=dfu-util all riotboot/flash-slot0
   ```
   can't be compiled without this PR but calls `dfu-util` correctly with this PR using the default VID/PID:
   ```python
   dfu-util --device 1209:7d02 --alt 0 --download examples/saul/bin/nucleo-f767zi/riotboot_files/slot0.1678440536.bin
   ```
2. Using a VID/PID as described in documentation:
   ```python
   FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
   DFU_USB_ID=1209:affe PROGRAMMER=dfu-util all riotboot/flash-slot0
   ```
   can't be compiled without this PR but calls `dfu-util` correctly with this PR using the default VID/PID:
   ```python
   dfu-util --device 1209:affe --alt 0 --download examples/saul/bin/nucleo-f767zi/riotboot_files/slot0.1678440536.bin
   ```
3. Compiling a board with DFU bootloader
   ```python
   make -C examples/saul flash BOARD=weact-f411ce
   ```
   should still call dfu-util with correct VID/PID:
   ```python
   dfu-util --device 0483:df11 --alt 0 --download /home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/examples/saul/bin/weact-f411ce/saul_example.bin  --dfuse-address 0x8000000:leave
   ```
### Issues/PRs references



19375: tools/renode: add support for target reset r=benpicco a=aabadie



19376: boards/stm32f4discovery: use default port to access stdio via cdc acm r=benpicco a=aabadie



19377: pkg/tinyusb: fix default VID/PID configuration r=benpicco a=gschorcht

### Contribution description

This PR fixes the default VID/PID configuration if tinyUSB board reset feature is used.

While reviewing PR #19086 I was wondering why `esp32s2-wemos-mini` requires to set `USB_VID`/`USB_PID` explicitly to  `USB_VID_TESTING`/`USB_PID_TESTING`. The reason was that tinyUSB board reset feature wasn't declared as RIOT internal.

### Testing procedure

Flashing `esp32s2-wemos-mini` should still work.
```
BOARD=esp32s2-wemos-mini make -C tests/shell flash
```
The VID/PID should be `1209:7d00` and not `1209:7d01`.

### Issues/PRs references



Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
bors bot added a commit that referenced this issue Mar 10, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=benpicco 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.

19374: makefiles/boards/stm32: fix DFU_USB_ID handling r=benpicco a=gschorcht

### Contribution description

This PR fixes the still existing problem that an application can't be flashed to a STM32 board if it uses `riotboot_dfu` with default  VID/PID (1209:7d02).

In PR #18964 item 1, the problem was already described that an application can't be flashed on a board that is using `riotboot_dfu`. Using for example
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util all riotboot/flash-slot0
```
always leads to error
```python
/home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/makefiles/boards/stm32.inc.mk:28: *** DFU_USB_ID is not set.  Stop.
/home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/makefiles/boot/riotboot.mk:87: recipe for target 'riotboot/bootloader/binfile' failed
```
even if `DFU_USB_ID` variable is set as described in documentation.
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util DFU_USB_ID=1209:7d02 all riotboot/flash-slot0
```
The reason is that the variable `DFU_USB_ID` isn't exported and the check https://github.com/RIOT-OS/RIOT/blob/8dc8bf35678493ecc8ef110e2f0359a67c03894c/makefiles/boards/stm32.inc.mk#L27-L29 sees an empty `DFU_USB_ID` variable here. It prevents to use `dfu-util` event though the following `dfu-util.mk` will generate a default value for this variable from the `USB_VID` and `USB_PID` variables if necessary.

Commit 6a76b94 of PR #18964 tried to fix this problem but wasn't merged for any reason.

To fix this problem, the check is completely removed. If a board such as `weact-f4x1cx` uses a DFU boorloader and requires a certain VID/PID combination, board's makefile is responsible to set `DFU_USB_ID` variable.

### Testing procedure

It is not necessary to use a real boad, checking the compilation process is sufficient.

1. Using default VID/PID as described in documentation:
   ```python
   FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
   PROGRAMMER=dfu-util all riotboot/flash-slot0
   ```
   can't be compiled without this PR but calls `dfu-util` correctly with this PR using the default VID/PID:
   ```python
   dfu-util --device 1209:7d02 --alt 0 --download examples/saul/bin/nucleo-f767zi/riotboot_files/slot0.1678440536.bin
   ```
2. Using a VID/PID as described in documentation:
   ```python
   FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
   DFU_USB_ID=1209:affe PROGRAMMER=dfu-util all riotboot/flash-slot0
   ```
   can't be compiled without this PR but calls `dfu-util` correctly with this PR using the default VID/PID:
   ```python
   dfu-util --device 1209:affe --alt 0 --download examples/saul/bin/nucleo-f767zi/riotboot_files/slot0.1678440536.bin
   ```
3. Compiling a board with DFU bootloader
   ```python
   make -C examples/saul flash BOARD=weact-f411ce
   ```
   should still call dfu-util with correct VID/PID:
   ```python
   dfu-util --device 0483:df11 --alt 0 --download /home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/examples/saul/bin/weact-f411ce/saul_example.bin  --dfuse-address 0x8000000:leave
   ```
### Issues/PRs references



Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
bors bot added a commit that referenced this issue Mar 10, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=benpicco 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.

Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
@gschorcht
Copy link
Contributor Author

On the bus the USB core just NAKs the OUT data transfers continuously for the SET LINE CODING request until this 5 seconds timeout.

Hm, STALL is generate only for IN data transfers here but SET LINE CODING causes an OUT data transfer. IMHO, we have to set the STALL for either the IN or the OUT endpoint here dependent on the direction of the SETUP.

This problem has been fixed with PR #17086.

@gschorcht
Copy link
Contributor Author

gschorcht commented Mar 11, 2023

  • STM32F723IE HS interface (CID 3100)
  • STM32F746NG HS interface (CID 2100)

The problem for these boards is more complex, see #17085 (comment). For now the only solution seems to be to revert PR #17085.

@gschorcht
Copy link
Contributor Author

The problem is fixed for stm32f429i-disc* by PR #19380.

bors bot added a commit that referenced this issue Mar 11, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=dylad 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.

Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
bors bot added a commit that referenced this issue 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 <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
bors bot added a commit that referenced this issue 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 <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
bors bot added a commit that referenced this issue 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 <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
bors bot added a commit that referenced this issue Mar 15, 2023
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=dylad 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=benpicco a=benpicco



Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
@bors bors bot closed this as completed in 50cd32f Mar 24, 2023
@MrKevinWeiss MrKevinWeiss added this to the Release 2023.04 milestone Apr 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants