things about unexpected behaviour in MSC transfer flow

[ghost]

during the process of transfering daplink to a currently not supported usb device, I encountered an assert in usbd_msc.c, although I managed to fix it, I do not know if it is a real issue.
When MSC flow triggers "MSC_BS_DATA_IN_LAST_STALL", it first stall the in-endpoint, and then send a CSW to exact same in-endpoint. Then when host decides to clear the stall endpoint by "clear feature", the behaviour in device is to clear the stalled in-endpoint first and the re-sent previous CSW(in "USBD_ReqClrFeature_MSC").
The problem of this process is that there are two exact same CSW stored in USB TX FIFO which will eventually be flused out with an in-token thereafter, which actually cause some misbehaviours and assert on my device. But I also think that this duplicated CSW packets should cause problems on all devices.
I do not know why it is designed like this, hope someone who know better about msc.c can shed a light.

[ghost]

Add another necessary changes about MSC, on my computer, driver from host actually send a CBW command of ‘SCSI_ATA_COMMAND_PASS_THROUGH16’ which is not currently supported. It will cause the host driver to reset the device from time to time.
It seems that the standard error handling procedure does not work for this ata pass through cmd, it has to be handed specifically like what did with 'SCSI_ATA_COMMAND_PASS_THROUGH12'.
Put this info here in case someone in future may encounter same problem.