Unimplemented USBX storage SCSI causes stall

[DZimm.9]

Good day,

We are using a composite USBX device class combining CDC and MSC over USB Full Speed, built on X_CUBE_AZRTOS-H7 version 3.3.0 (USBX 6.4). During testing we discovered that a certain Windows PC sends a MODE SELECT(10) command (opcode 0x55) and causes an endpoint stall.

After a rather long debugging session, it was found that the USBX source _ux_device_class_storage_mode_select() is explicitly not implemented — it stalls the OUT endpoint, UX_FUNCTION_NOT_SUPPORTED (which is not checked in the thread) and never recovers:

The MODE SELECT(6) SCSI command is not even implemented and the storage thread falls through to the default case, also triggering a endpoint stall. 

So:
- Are there any plans to implement these MODE SELECT(6/10) commands properly in a future USBX release?
- Does anyone already have a workaround for this?
- Wouldn't it be cleaner to reply with an ILLEGAL REQUEST instead of stalling the endpoint?

System details:
- MCU: STM32H7
- USBX version: 6.4 (X_CUBE_AZRTOS-H7 3.3.0)
- USB class: Composite CDC + MSC, Full Speed
- Failing host OS: Windows 11

Thanks in advance for your support.

Best regards,
Daniel

[FBL]

Hi @DZimm.9 

To further narrow down and reproduce the issue on my side, I’d like to ask you to share your minimum project setup. This should include the full project (all source files, configuration files, and middleware), and any custom changes you have made to the USB, MSC, or SCSI handling if applicable.

Having the full project will allow to replicate your environment and more efficiently identify the root cause of the problem.

Internal ticket is submitted to dedicated team CDM0060954

[simonkoo]

Seems we got same question ,

when I using MSC with U575, all things is ok with operation with U disk.

after several minites, 575 recieves SCSI command "0x15" or “0x85” from host,which will not implement MODE_SELACT . then PC can not recognize U disk right. 

I tried to add 6 10 mode select definition just now,seems U disk can work well: 

                            case UX_SLAVE_CLASS_STORAGE_SCSI_MODE_SELECT:

                            case UX_SLAVE_CLASS_STORAGE_SCSI_MODE_SELECT_6:

                            case UX_SLAVE_CLASS_STORAGE_SCSI_MODE_SELECT_10:

                                _ux_device_class_storage_mode_select(storage, lun, endpoint_in, endpoint_out, cbw_cb);

                                break;

 

BUT，when MX regenerate code， wiil clear the line added.

[DZimm.9]

Hi

I already created once a sample project for the NUCLEO-H753ZI. With this project, the issue cna be reproduced and the code is available on github: https://github.com/NoyzZimmi/STM32H7_MSC_CDC

 

The above project is directly based on the sample project: 
https://github.com/STMicroelectronics/x-cube-azrtos-h7/tree/main/Projects/STM32H735G-DK/Applications/USBX/Ux_Device_MSC

I don't have this development kit, but since the problem seems to be with USBX implementation, it probably can be reproduced directly with that sample project.

To reproduce the issue you can follow the steps below. If you are working on Linux, it is even simpler:
Optional step on Windows: open Power shell with Admin rights:

1. Install usbipd
2. usbipd list -> identify the bus ID
3. usbipd bind --busid 6-7 --force -> this binds the port
4. usbipd attach --wsl --busid 6-7 -> will attach usb port to WSL and start a server

On Linux / WSL (i choose ubuntu):

1. lsusb -> identify you device
2. dmesg | tail -20 -> also helps to find the device, for me it is /dev/sg4:
   
3. time sudo sg_turs -v /dev/sg4 -> will send a test message and should repport that a SD card is present
4. time sudo sg_raw -v /dev/sg4 1a 00 00 00 ff 00 -> this will break the MSC and the device is not responding anymore

The second request with SCSI command 0x1A will never complete and the endpoint stalled and does not recover.

Best regards

Daniel

[FBL]

Hi @DZimm.9 

Thank you for your feedback 

According to the USB Mass Storage Class – Bulk‑Only Transport (BOT) specification and the SCSI primary/block command standards that USB MSC is built on, implementing MODE SENSE(6) and MODE SENSE(10)  is mandatory for a USB MSC device. At least, the device must handle unsupported SCSI commands in a SCSI and BOT compliant way. 

I found also in UM0424, EP0 is only used to clear the bulk EP status (clear STALL status) and to issue the two class-specific requests: Mass Storage reset and Get Max LUN. Also, as stated in section 6.3.2, these commands must be implemented and must return the defined data arrays. 

So, for me your input is valid. 

Thanks again and I will try to reproduce on my end.

Yeah, that endpoint stall behavior definitely feels like a limitation in USBX returning an ILLEGAL REQUEST with proper sense data would be a much cleaner approach for host handling, especially on Windows 11; I haven’t seen an official fix yet, but hopefully ST improves this in future updates, and while looking into similar issues I’ve even come across helpful community threads via Cookie Run Kingdom Codes that point to shared workarounds and discussions.