Bug on STM32F2 USB Low Layer HAL

[RamiroOliveira]

Describe the bug
When creating a composite device using #12682 on a STM32 Nucleo F207ZG board, the kernel panics.
According to addr2line the faulty error occurs in ext/hal/st/stm32cube/stm32f2xx/drivers/src/stm32f2xx_ll_usb.c on line 573 because ep->maxpacket is 0 when a division operation occurs.

Using other boards (stm32f072b-disco) this issue doesn't occur which might point to an error on the F2 USB LL HAL.

Seems related with #7364.

@erwango @finikorg @ydamigos @loicpoulain

To Reproduce
Steps to reproduce the behavior:

1. Pull PR USB Multi-instance support #12682
2. Navigate to samples/subsys/usb/cdc_acm_composite/
   3 mkdir build; cd build
3. cmake -DBOARD=nucleo_f207zg ..
4. make flash
5. Open console on ttyACM*
   minicom --device /dev/ttyACM0
   minicom --device /dev/ttyACM1
   minicom --device /dev/ttyACM2
6. See error

Expected behavior
The sample should run without error and data sent from ACM1 should appear on ACM2 and vice-versa.

Impact
Kernel crashes

Screenshots or console output

Wait for DTR
DTR set, start test
Baudrate detected: 57600
Baudrate detected: 57600
***** USAGE FAULT *****
Division by zero
***** Hardware exception *****
Current thread ID = 0x20000a2c
Faulting instruction address = 0x8001ae8
Fatal fault in essential thread! Spinning...

Environment (please complete the following information):

• Linux
• Zephyr SDK
• PR USB Multi-instance support #12682

[ydamigos]

@RamiroOliveira Following the steps above, I tested cdc_acm_composite sample on olimexino_stm32 and stm32f3_disco. It works fine. But on my 96b_carbon kernel I get the same error.
A first observation is that the issue affects devices with OTGFS controller.

[loicpoulain]

@RamiroOliveira, @finikorg, @ydamigos , correct me if I'm wrong but AFAIU, CDC ACM requires 3 endpoints per instance whereas stm32f4 (and f2) usb otgfs offers only four bidirectional endpoints, which makes impossible to run the acm composite sample. I, however, agree that we should gracefully fail at build or runtime in such situation.

Note: It also explains why it works with stm32f3_disco (8 bidir endpoints)

[jfischer-no]

The stack should not start with this configuration, usb_validate_ep_cfg_data (and usb_dc_ep_check_cap in the driver) would fail. @RamiroOliveira can you please set USB_DRIVER_LOG_LEVEL to debug and post the console output?

[finikorg]

@RamiroOliveira, @finikorg, @ydamigos , correct me if I'm wrong but AFAIU, CDC ACM requires 3 endpoints per instance whereas stm32f4 (and f2) usb otgfs offers only four bidirectional endpoints, which makes impossible to run the acm composite sample. I, however, agree that we should gracefully fail at build or runtime in such situation.

Note: It also explains why it works with stm32f3_disco (8 bidir endpoints)

Do you mean DT_USB_NUM_BIDIR_ENDPOINTS. It has 4 endpoint in each direction, so should be just fine.

[ydamigos]

@jfischer-phytec-iot The console output on my 96b_carbon:
96b_carbon-cdc_acm_composite-error-log.txt

For some reason HAL_PCD_EP_Open() in not called for ep 0x84. Later we try to write to ep 0x84 which is not opened (and, as a result, its maxpacket size is not configured, so it is zero) and stm32cube HAL function USB_EPStartXfer() fails because it contains a division with ep 0x84 maxpacker size.

Edit:
I tweaked the usb_dc_ep_enable() to print ep->state and it was NULL for ep 0x84.

...
[00:00:00.467,949] <dbg> usb_dc_stm32.usb_dc_ep_enable: ep 0x84 state was NULL
...

[ydamigos]

As @loicpoulain mentioned (96b_carbon) stm32f4 offers 4 bidirectional endpoints (including EP0) so it can't run acm composite sample. DT_USB_NUM_BIDIR_ENDPOINTS includes EP0 so we need to take it into account when we check endpoint capabilities (usb_dc_ep_check_cap).