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

 

[David George]

Thanks @DrPi  - This works but MX will always add the original source file back to the Build, so you have to remember to do the Resource configurations / Exclude from build...

I have just been doing this when MX changes it.

git restore ux_device_class_storage.c

David

[DrPi]

Hmmm, I don't have this behavior. 

Maybe this depends on the targetted STM32 and/or the STM32CubeIDE/STM32CubeMX version...

[David George]

I tried your suggestion again, an it worked this time.
So thank you - that will prevent fiddling around with files around after an MX generate.
A very useful tip to know.