-
Notifications
You must be signed in to change notification settings - Fork 968
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
things about unexpected behaviour in MSC transfer flow #1013
Comments
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. |
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.
The text was updated successfully, but these errors were encountered: