example usb/cdc_acm coredump on board STMicroelectronics nucleo_h563zi when use "usbd_next_prj.conf"

[MY201314MY]

Describe the bug when I enable the CONFIG_USB_DEVICE_STACK=y, the usb/cdc_acm can work well. But when I enable CONFIG_USB_DEVICE_STACK_NEXT=y, the system will coredump.

To Reproduce Steps to reproduce the behavior:

1. check zephyr version

   commit 099209b7d563886b23ddcbb1d59f06fdd9e66ab1 (HEAD -> mini-h562-usb-1.1.0, origin/main, origin/HEAD, main)
   Author: Johan Hedberg <johan.hedberg@silabs.com>
   Date:   Mon Jul 22 12:43:46 2024 +0300
   
   doc: release-notes-3.7: Add more details for Bluetooth HCI drivers
   
   Make sure all added (and removed) HCI drivers are mentioned, and also
   provide a reference to the new HCI driver API.
   
   Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>

2.build

west build samples/subsys/usb/cdc_acm -b nucleo_h563zi -p -- -DCONF_FILE:STRING="usbd_next_prj.conf"

3.west flash and inset the usb cable to PC

4. See error the third parameter buf is NULL , which caused the system to crash. I don't know how to fix it.

Expected behavior usb cdc_acm can run normal when CONFIG_USB_DEVICE_STACK_NEXT=y is enabled.

Impact

Logs and console output

*** Booting Zephyr OS build v3.7.0-rc3-102-g099209b7d563 ***
[00:00:00.000,000] <inf> cdc_acm_echo: USB device support enabled
[00:00:00.000,000] <inf> cdc_acm_echo: Wait for DTR
[00:00:00.003,000] <inf> cdc_acm_echo: USBD message: Device suspended
[00:00:04.955,000] <inf> cdc_acm_echo: USBD message: Device resumed
[00:00:04.958,000] <inf> cdc_acm_echo: USBD message: Device suspended
[00:00:05.099,000] <inf> cdc_acm_echo: USBD message: Device resumed
[00:00:05.156,000] <inf> cdc_acm_echo: USBD message: Bus reset
[00:00:05.284,000] <inf> cdc_acm_echo: USBD message: Bus reset
[00:00:05.383,000] <err> os: ***** BUS FAULT *****
[00:00:05.383,000] <err> os:   Precise data bus error
[00:00:05.383,000] <err> os:   BFAR Address: 0x0
[00:00:05.383,000] <err> os: r0/a1:  0x20000544  r1/a2:  0x00000000  r2/a3:  0x0800e4d8
[00:00:05.383,000] <err> os: r3/a4:  0x200000e8 r12/ip:  0x20002484 r14/lr:  0x080033b9
[00:00:05.383,000] <err> os:  xpsr:  0x61000000
[00:00:05.383,000] <err> os: Faulting instruction address (r15/pc): 0x080046b0
[00:00:05.383,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:05.383,000] <err> os: Current thread: 0x20000aa0 (unknown)

[FRASTM]

Also seen with stm32h573 disco kit, when plugging the USB cable. The function usbd_cdc_acm_ctd of the ./subsys/usb/device_next/class/usbd_cdc_acm causing a crash at memcpy because next_buf->data is 0 after usbd_ch9: Buffer for data|status is missing

[00:00:02.428,000] <err> os: ***** BUS FAULT *****
[00:00:02.428,000] <err> os:   Precise data bus error
[00:00:02.428,000] <err> os:   BFAR Address: 0x0
[00:00:02.428,000] <err> os: r0/a1:  0x20000508  r1/a2:  0x00000000  r2/a3:  0x0800e10c
[00:00:02.428,000] <err> os: r3/a4:  0x200000c4 r12/ip:  0x200023c4 r14/lr:  0x08003141
[00:00:02.428,000] <err> os:  xpsr:  0x61000000
[00:00:02.428,000] <err> os: Faulting instruction address (r15/pc): 0x08004438
[00:00:02.428,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0                                          
[00:00:02.428,000] <err> os: Current thread: 0x20000a68 (unknown)                                                       
[00:00:02.522,000] <err> os: Halting system       

Log before crashing reports

[00:00:00.584,000] <inf> usbd_ch9: Handle control 0x20004f48 ep 0x00, len 8, s:1 d:0 s:0
[00:00:00.585,000] <inf> usbd_ch9: Handle control 0x20004f6c ep 0x00, len 8, s:1 d:0 s:0                                
[00:00:00.585,000] <inf> usbd_ch9: Handle control 0x20004f90 ep 0x00, len 8, s:1 d:0 s:0                                
[00:00:00.585,000] <inf> usbd_ch9: Handle control 0x20004fb4 ep 0x00, len 8, s:1 d:0 s:0                                
[00:00:00.498,000] <inf> usbd_core: Actual device speed 1                                                               
[00:00:00.593,000] <inf> usbd_ch9: Handle control 0x20004fd8 ep 0x00, len 8, s:1 d:0 s:0                                
[00:00:00.593,000] <inf> usbd_ch9: Set Configuration Request value 1                                                    
[00:00:00.593,000] <inf> usbd_iface: Modify interface 0 ep 0x81 by op 1 ep_bm 20000                                     
[00:00:00.593,000] <inf> usbd_iface: Modify interface 1 ep 0x82 by op 1 ep_bm 60000                                     
[00:00:00.593,000] <inf> usbd_iface: Modify interface 1 ep 0x01 by op 1 ep_bm 60002                                     
[00:00:00.593,000] <inf> usbd_ch9: Handle control 0x20004ffc ep 0x80, len 0, s:0 d:0 s:1                                
[00:00:00.593,000] <inf> usbd_ch9: s-(out)-status finished                                                              
[00:00:00.593,000] <inf> usbd_ch9: Handle control 0x20004ffc ep 0x00, len 8, s:1 d:0 s:0  

[FRASTM]

@loicpoulain or @jfischer-no please, could you help investigation shows that usbd_handle_ctrl_xfer is being given a wrong next_buf by net_buf_frag_del : for buf addr 0x20003f9c ep 0x80, buf->len = 0 buf->data =0

During the udc_stm32 ep_enable, the HAL_PCDEx_PMAConfig is called for EP 0x0, 0x80,0x81, 0x82, 0x1 but never called for EP 0x2