-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Possible problem with p_csw->status in mscd_xfer_cb #60
Comments
Hi @zardam thank you for openning bug report. Can you tell me more about your set up OS: [e.g. Ubuntu 18.04] and how to reproduce it. |
Hi, The host side is a calculator (TI 83 Premium CE https://education.ti.com/fr/products/calculators/graphing-calculators/ti-83-premium-ce). I did not have the problem with CircuitPython 3, which was using another USB protocol implementation. It is easily reproductible if you have the calculator... I have some captures of the USB frames between the calculator and the board, but I cannot provide them now (I'm away from home for the whole week), sorry. |
Unfortunately I dont have the calculator. Maybe you could try to debug the firmware, place breakpoint when issue occurs and print out the msc device data, I will help to analyze which went wrong. An usb bus capture will also help alot to narrow down the issue as well. |
Here is the interesting part of the USB capture :
The last READ (10) command is in error, just after a TEST UNIT READY on LUN 5.
|
hmm, the cpy only implement 1 LUN as far as I know. What causes the host to issue command to LUN 5. btw can you upload the capture file, it is hard to examine raw byte, it is better to analyze it with software viewer |
The CircuitPython provided with the genuine module is customized (and the source code is not available). There is a "protocol" implemented over USB MSC. TEST UNIT READY on LUN greater than 1 are used to trigger several LED flashing mode on the module. (There are also some INQUIRY commands used to validate the firmware of the module). Here is the capture file from pulseview I tried to trigger the problem from a computer with a small bit of code using libusb, but it is not working for now. |
would you mind trying this again. There has been lots of improvement for msc driver for the last year. |
closed, may re-open if needed. |
I'm suspecting a wrong state of p_csw->status in some cases in this function :
tinyusb/src/class/msc/msc_device.c
Line 317 in e4be6dd
This occurs when reading a sector after an another (unknown for now) msc query returns p_csw->status = MSC_CSW_STATUS_FAILED
Setting p_csw->status = MSC_CSW_STATUS_PASSED at the top of the function solved my issue.
I do not have to much time to do a proper PR nor tests for now, so I provide only the raw information. Maybe in a week or two.
The text was updated successfully, but these errors were encountered: