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.

[David George]

I had this exact same issue, an STM32U5G9J-DK2 with a USBX / LevelX / NOR Flash file system. (Mounted with FileX when USB is disconnected).

The USB 'drive' would connect to my DELL pc fine, I could read/write files normally.  Then after ~5 to 10 minutes the HAL_PCD_ResetCallback would fire and put the USBX into continuous UX_DEVICE_REMOVED, UX_DEVICE_ATTACHED loop that could only be fixed by a hard reset.

It was the 'Unknown or Unsupported SCSI Command' hitting the switch's fall-through and stalling the USBX.
The unhandled SCSI Command received was 0x85

SCSI command 0x85 corresponds to the ATA PASS-THROUGH (16) command.

I can fix it by adding a patch in the ux_device_class_storage_thread.c file, but MX will always reset this file when re-Generating code.

So a more permanent solution from STM would really be appreciated.

[DZimm.9]

Hi @FBL

Were you able to reproduce this problem? Is there an open ticket we can follow to track whether this issue has been resolved?

In the meantime, we have fully disabled MSC support and are looking forward to a fix.

Thanks and best regards,
Daniel

[FBL]

Hi @DZimm.9 @David George 

Thank you again for your valuable help in escalating the issue.

The ticket has been handed over to the development team, and there are no updates at the moment. We will keep you informed as soon as we receive any feedback.

[David George · Accepted solution]

PS. Below is what I added to file ux_device_class_storage.c at line 321 to handle the 0x85 SCSI Command.
I am sending back a SENSE_KEY_ILLEGAL_REQUEST for the next Window's REQUEST SENSE.
Now my 'USB Drive' stays connected in Windows Explorer.
The 0x85 command are still sent, but they don't stall the USBX connection any more.

/* Workaround:
   Windows/Dell host sends SCSI ATA PASS-THROUGH(16), opcode 0x85.
   USB MSC device does not support ATA pass-through.
   Return ILLEGAL REQUEST / INVALID COMMAND instead of leaving command unhandled.
 */
#ifndef UX_DEVICE_CLASS_STORAGE_SENSE_KEY_ILLEGAL_REQUEST
	#define UX_DEVICE_CLASS_STORAGE_SENSE_KEY_ILLEGAL_REQUEST  0x05
#endif
case 0x85:   /* ATA PASS-THROUGH(16) */
case 0xA1:   /* ATA PASS-THROUGH(12) */
	storage -> ux_slave_class_storage_csw_status = UX_SLAVE_CLASS_STORAGE_CSW_FAILED;
	storage -> ux_slave_class_storage_lun[lun].ux_slave_class_storage_request_sense_status =
			UX_DEVICE_CLASS_STORAGE_SENSE_STATUS(
					UX_DEVICE_CLASS_STORAGE_SENSE_KEY_ILLEGAL_REQUEST,
					0x20,
					0x00);
    break;

And at line 316,

case UX_SLAVE_CLASS_STORAGE_SCSI_MODE_SELECT:
case 0x15:	 /* ATA MODE SELECT (6) */
    _ux_device_class_storage_mode_select(storage, lun, endpoint_in, endpoint_out, cbw_cb);
    break;

[DrPi]

There's a workaround to keep your modifications when STM32CubeMX generates code.

Create a new folder called src_modified or whatever in Middlewares/ST/usbx/common/usbx_device_classes/

• Copy the file ux_device_class_storage_thread.c from Middlewares/ST/usbx/common/usbx_device_classes/src to Middlewares/ST/usbx/common/usbx_device_classes/src_modified.
• Exclude Middlewares/ST/usbx/common/usbx_device_classes/src/ux_device_class_storage_thread.c from build : Right-click on the file / Resource configurations / Exclude from build... / check Release and Debug
• Do your modifications in Middlewares/ST/usbx/common/usbx_device_classes/src_modified/ux_device_class_storage_thread.c

Sometimes, you do not need to create a new folder. You can copy the file in the same folder with a new name. But with USBX, unknown files are deleted by STM32CubeMX when generating sources.