USB (next) DFU transfer size on STM32F4

[vulporuza]

Describe the bug

Hi,

I am working on STM32F411 and using the USB DFU feature with the new USB Next stack.
During my tests, I encountered an issue with the packet size, which caused the device to stall in the DNLOAD state, and require a reset to unlock it.

My device does not support USB High Speed, but I would like to use the default configuration CONFIG_USBD_DFU_TRANSFER_SIZE=512 which relates to the wTransferSize field. As I understand it, the transfer size is not directly linked to the device's capabilities, from the class point of view. The class is ready to received 512B of data, and theoretically the host should send 64B packets (according to device capabilities) until 512B are reached, then wait for an ACK, and so on.
However, despite of my configuration (and the buffer allocation of 512B at driver level), I only receive the first 64B in the buffer and the update stalls.

I tried changing CONFIG_USBD_DFU_TRANSFER_SIZE=64 or forcing the transfer size to 64 using --transfer-size 64 argument in dfu-util. In both cases this seems to solve the problem, but I do not understand why a transfer size of 512 does not work. As far as I understand, the transfer size and the packet size are dissociated.

I am disappointed because I recently worked on a WebUSB class, and it worked in that case. With a transaction of 2kB for example, the payload is well split in 64B packets, which are transparent to the class layer.

Thanks in advance for any help !

Regression

• This is a regression.

Steps to reproduce

No response

Relevant log output

[00:00:03.732,000] <dbg> usbd_dfu: dfu_set_next_state: bRequest GETSTATUS, state DFU_IDLE, next DFU_IDLE, error 0
[00:00:03.735,000] <dbg> udc: udc_ep_enqueue: Queue ep 0x80 0x2001e850 len 6
[00:00:03.737,000] <dbg> udc_stm32: udc_stm32_tx: TX ep 0x80 len 6
[00:00:03.739,000] <dbg> udc: udc_ep_buf_alloc: Allocate net_buf 0x2001e82c, ep 0x00, size 0
[00:00:03.741,000] <dbg> udc_stm32: handle_msg_data_in: DataIn ep 0x80
[00:00:03.743,000] <dbg> udc: udc_ctrl_update_stage: s-in->(status)
[00:00:03.744,000] <dbg> udc: udc_buf_destroy: destroy 0x2001e850
[00:00:03.746,000] <dbg> udc_stm32: handle_msg_data_out: DataOut ep 0x00
[00:00:03.748,000] <dbg> udc: udc_ctrl_update_stage: s-in-status
[00:00:03.750,000] <inf> usbd_ch9: Handle control 0x2001e82c ep 0x00, len 0, s:0 d:0 s:1
[00:00:03.752,000] <inf> usbd_ch9: s-in-status finished
[00:00:03.754,000] <dbg> udc: udc_buf_destroy: destroy 0x2001e82c
[00:00:03.755,000] <dbg> udc: udc_ep_buf_alloc: Allocate net_buf 0x2001e82c, ep 0x00, size 8
[00:00:03.758,000] <dbg> udc: udc_ctrl_update_stage: s->(out)
[00:00:03.759,000] <dbg> udc: udc_ep_buf_alloc: Allocate net_buf 0x2001e850, ep 0x00, size 512
[00:00:03.762,000] <dbg> udc_stm32: handle_msg_data_out: DataOut ep 0x00
[00:00:03.764,000] <dbg> udc: udc_ep_buf_alloc: Allocate net_buf 0x2001e808, ep 0x80, size 0
[00:00:03.766,000] <inf> usbd_ch9: Handle control 0x2001e82c ep 0x00, len 8, s:1 d:0 s:0
[00:00:03.768,000] <dbg> udc: udc_buf_destroy: destroy 0x2001e82c
[00:00:03.770,000] <dbg> usbd_dfu: dfu_set_next_state: bRequest DNLOAD, state DFU_IDLE, next DNLOAD_SYNC, error 0
[00:00:04.023,000] <dbg> dfu_flash: dfu_flash_write: downloaded 64 (0) block 0 size 64
[00:00:04.025,000] <inf> usbd_ch9: spool 0x2001e850
[00:00:04.027,000] <dbg> udc: udc_buf_destroy: destroy 0x2001e850
[00:00:04.028,000] <dbg> udc: udc_ep_enqueue: Queue ep 0x80 0x2001e808 len 0
[00:00:04.030,000] <dbg> udc_stm32: udc_stm32_tx: TX ep 0x80 len 0
uart:~$

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

• STM32F411
• Zephyr RTOS main (169cf86)

Additional Context

No response

[jfischer-no]

I think it is STM32 UDC shim/HAL drivers issue. Shim driver passes 512 to the HAL driver but it handle only a single transaction.

zephyr/drivers/usb/udc/udc_stm32.c

Line 291 in cb77257

HAL_PCD_EP_Receive(&priv->pcd, cfg->addr, buf->data, buf->size);

Perhaps there is already a fix available and @mathieuchopstm is aware about it.