Possible problem with p_csw->status in mscd_xfer_cb about tinyusb HOT 8 CLOSED

Hi @zardam thank you for openning bug report. Can you tell me more about your set up

OS: [e.g. Ubuntu 18.04]
Board: [e.g pca10056]
Firmware Code: [e.g examples/device/cdc_msc_hid]

and how to reproduce it.

from tinyusb.

Hi,

The host side is a calculator (TI 83 Premium CE https://education.ti.com/fr/products/calculators/graphing-calculators/ti-83-premium-ce).
The board is an arduino zero clone running latest CircuitPython (https://github.com/adafruit/circuitpython)

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.

from tinyusb.

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.

from tinyusb.

Here is the interesting part of the USB capture :

OUT ADDR 10 EP 4
DATA1 [ 55 53 42 43 90 F6 88 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
ACK
IN ADDR 10 EP 3
DATA0 [ 55 53 42 53 90 F6 88 00 00 00 00 00 00 ]
ACK
OUT ADDR 10 EP 4
DATA0 [ 55 53 42 43 99 9A 89 00 08 00 00 00 80 00 06 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
ACK
IN ADDR 10 EP 3
DATA1 [ 00 00 00 80 00 00 02 00 ]
ACK
IN ADDR 10 EP 3
DATA0 [ 55 53 42 53 99 9A 89 00 00 00 00 00 00 ]
ACK
OUT ADDR 10 EP 4
DATA1 [ 55 53 42 43 99 85 8A 00 00 02 00 00 80 00 0A 28 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ]
ACK
...
IN ADDR 10 EP 3
DATA1 [ 55 53 42 53 99 85 8A 00 00 00 00 00 00 ]
ACK
OUT ADDR 10 EP 4
DATA0 [ 55 53 42 43 A1 A0 8B 00 00 02 00 00 80 00 0A 28 00 00 00 00 01 00 00 01 00 00 00 00 00 00 00 ]
ACK
...
IN ADDR 10 EP 3
DATA0 [ 55 53 42 53 A1 A0 8B 00 00 00 00 00 00 ]
ACK
OUT ADDR 10 EP 4
DATA1 [ 55 53 42 43 59 8D 8C 00 00 00 00 00 00 05 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
ACK
IN ADDR 10 EP 3
DATA1 [ 55 53 42 53 59 8D 8C 00 00 00 00 00 01 ]
ACK
OUT ADDR 10 EP 4
DATA0 [ 55 53 42 43 71 AA 8D 00 00 02 00 00 80 00 0A 28 00 00 00 00 03 00 00 01 00 00 00 00 00 00 00 ]
ACK
...
IN ADDR 10 EP 3
DATA0 [ 55 53 42 53 71 AA 8D 00 00 00 00 00 01 ]
ACK

The last READ (10) command is in error, just after a TEST UNIT READY on LUN 5.

tud_msc_scsi_cb is implemented here in CircuitPython : https://github.com/adafruit/circuitpython/blob/master/supervisor/shared/usb/usb_msc_flash.c#L64 and retruns -1 in case of this LUN number.

from tinyusb.

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

from tinyusb.

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
tinyusb.zip (renamed from .sr to .zip for github). The problem occurs after SOF 719.

I tried to trigger the problem from a computer with a small bit of code using libusb, but it is not working for now.

from tinyusb.

would you mind trying this again. There has been lots of improvement for msc driver for the last year.

from tinyusb.

closed, may re-open if needed.

from tinyusb.