Possible problem with p_csw->status in mscd_xfer_cb

[zardam]

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

bool mscd_xfer_cb(uint8_t rhport, uint8_t ep_addr, xfer_result_t event, uint32_t xferred_bytes)

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.

[hathach]

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.

[zardam]

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.

[hathach]

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.

[zardam]

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.

[hathach]

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

[zardam]

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.

[hathach]

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

[hathach]

closed, may re-open if needed.