Open hvbon2010 opened 1 year ago
Suggestion patch to fix this issue:
diff --git a/subsys/usb/device/class/msc.c b/subsys/usb/device/class/msc.c
index d01dadb35e..fbc3f012ea 100644
--- a/subsys/usb/device/class/msc.c
+++ b/subsys/usb/device/class/msc.c
@@ -349,6 +349,13 @@ static bool modeSense6(void)
return write(sense6, sizeof(sense6));
}
+static bool modeSense10(void)
+{
+ uint8_t sense10[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
+
+ return write(sense10, sizeof(sense10));
+}
+
static bool readFormatCapacity(void)
{
uint8_t capacity[] = { 0x00, 0x00, 0x00, 0x08,
@@ -556,6 +563,12 @@ static void CBWDecode(uint8_t *buf, uint16_t size)
modeSense6();
}
break;
+ case MODE_SENSE10:
+ LOG_DBG(">> MODE_SENSE10");
+ if (check_cbw_data_length()) {
+ modeSense10();
+ }
+ break;
case READ_FORMAT_CAPACITIES:
LOG_DBG(">> READ_FORMAT_CAPACITY");
if (check_cbw_data_length()) {
I found the issue was from
MODE_SENSE10
command do not support by zephyr msc.[00:38:18.966,625] <wrn> usb_msc: >> default CB[0] 5a [00:38:18.966,643] <err> usb_dc_mcux: Failed to fill ep 0x81 buffer [00:38:18.966,649] <err> usb_msc: usb write failure
Maybe, but the issue is in the driver, IP3511 again. @mmahadevan108 please take a look.
uint8_t sense10[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
If implement hard-coded response (like the rest in the old stack), please at least make it standard compliant.
uint8_t sense10[] = {0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
is valid MODE SENSE(10) response for disk with no block descriptors.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
I'm still having the same issue, I'm on nrf52480 with a SDMMC card backend using Fat32. Basically it makes the USB MSC nearly useless, as manually moving the SD card to a card reader and back is faster than using the zephyr MSC to transfer data.
I'm still having the same issue, I'm on nrf52480 with a SDMMC card backend using Fat32. Basically it makes the USB MSC nearly useless, as manually moving the SD card to a card reader and back is faster than using the zephyr MSC to transfer data.
Are you sure this is really the same issue? Note that nRF52840 has Full-Speed only USB (12 Mbps) so depending on the size of data you want to transfer the card reader might be faster.
For a standard compliant USB Mass Storage class implementation, check out the new experimental USB device stack. The old stack MSC implementation is very questionable and can lead to multiple silly handling loops (e.g. because it does not respond with proper error values). This is all fixed in the new experimental stack which has completely new implementation.
Are you sure this is really the same issue? Note that nRF52840 has Full-Speed only USB (12 Mbps) so depending on the size of data you want to transfer the card reader might be faster.
For a standard compliant USB Mass Storage class implementation, check out the new experimental USB device stack. The old stack MSC implementation is very questionable and can lead to multiple silly handling loops (e.g. because it does not respond with proper error values). This is all fixed in the new experimental stack which has completely new implementation.
The problem arises only when mounting. Copying files, for instance, has quite acceptable speeds. I tried the new USB device stack and it has the exact same issues for me.
The problem arises only when mounting. Copying files, for instance, has quite acceptable speeds. I tried the new USB device stack and it has the exact same issues for me.
Can you provide USB packet captures (with the new USB device stack)? Wireshark (usbmon) should be good enough to be able to roughly identify what is going on.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
Can you run USB3CV MSC Tests? NRF52840, nRF5340 and nRF54H20 do pass the MSC Tests flawlessly with the new USB stack.
The MSC tests did reveal quite few issues in nRF54H20 driver during driver development so they are quite good in revealing various issues (the real root cause can be not clearly visible, but at least the test will fail somewhere if the driver is bad).
The problem arises only when mounting. Copying files, for instance, has quite acceptable speeds. I tried the new USB device stack and it has the exact same issues for me.
Can you provide USB packet captures (with the new USB device stack)? Wireshark (usbmon) should be good enough to be able to roughly identify what is going on.
@tmon-nordic I made a pcap file to show what is going on when connecting the device: https://we.tl/t-coywZdJyqp
It seems like a lot of SCSI data is sent over USB including a lot of zeroes (e.g. at 8 seconds) and only after ~24s it is ready transferring. I confirmed in my device that it is done reading from my SD card after those 24 seconds.
But 24s is a long time for it to show up correctly in my file explorer.
@jfischer-no can I assign this to you since it is being reported across multiple SOCs?
@jfischer-no can I assign this to you since it is being reported across multiple SOCs?
Why? I see it is only reported for mimxrt595_evk_cm33.
@jfischer-no can I assign this to you since it is being reported across multiple SOCs?
Why? I see it is only reported for mimxrt595_evk_cm33.
@bmulder-innoseis is suggesting a similar problem on a nRF52840 but it seems the discussion thread may not have come to agreement with this.
@bmulder-innoseis is suggesting a similar problem on a nRF52840 but it seems the discussion thread may not have come to agreement with this.
It looks different to me, I think it is more about throughput, nRF52840DK has a full-speed device controller and SD card is connected via SPI, the throughput is very low, the disk (SD card), based on the data from pcap file has no partitions and is formatted FAT32,
Filesystem type: FAT32
OEM name: MSDOS5.0
Total sectors: 7744512
Total data clusters: 966144
Data size: 3957325824 (3.68555G)
Disk size: 3965190144 (3.69287G)
Bytes per sector: 512
Sectors per cluster: 8
Bytes per cluster: 4096
Reserved sectors: 1288
Sectors per FAT: 7548
Fat size: 3864576 (3.68555M)
FAT1 start address: 00000000000a1000
FAT2 start address: 0000000000450800
Data start address: 0000000000800000
Root directory cluster: 2
Disk label: NO NAME
During the mount, the host filesystem driver will read a lot of clusters, to get information about the filesystem, BPBs, FATs, RD... And because throughput is very low (about 127 kB/s, reading 1000 clusters) it will take some time (16s for me using disk with the same geometry). One will see the same low throughput coping files from the disk. The same SD card in a modern card reader, but forced to full-speed, has a throughput of about 789 kB/s. On nRF52840, the throughput for the bulk transfers is about 460 kB/s. Emulating the disk geometry above with #62286, I see throughput of about 386 kB/s (577 kB/s on FRDM K64F, there is also some MSC communication overhead and based on sector number emulation overhead). The limiting factor is the SD card connected via SPI interface and there is nothing we can do to improve it.
@jfischer-no from what do you get the throughput of 127 kb/s for the SD card via SPI? from the pcap or from known limitations? The SPI maximum throughput should be 24 mbit (3 MB). Now it will not actually hit those speeds, but 127 kB seems a bit on the low side to me. Or is there another part that bottlenecks it?
@tmon-nordic I made a pcap file to show what is going on when connecting the device: https://we.tl/t-coywZdJyqp
It seems like a lot of SCSI data is sent over USB including a lot of zeroes (e.g. at 8 seconds) and only after ~24s it is ready transferring. I confirmed in my device that it is done reading from my SD card after those 24 seconds.
But 24s is a long time for it to show up correctly in my file explorer.
Transfer expired. So unless you put it up again, I won't be able to take a look at it.
@jfischer-no from what do you get the throughput of 127 kb/s for the SD card via SPI? from the pcap or from known limitations? The SPI maximum throughput should be 24 mbit (3 MB). Now it will not actually hit those speeds, but 127 kB seems a bit on the low side to me. Or is there another part that bottlenecks it?
127 kB/s on the host side, dd first 1000 clusters. The SPI clock can be 24MHz, but the data throughput will be much lower than 24Mbit.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
Describe the bug Built and ran the usb mass storage demo with zephyr v3.2.0 on mimxrt595_evk_cm33, wait for 30 seconds to usb msc can mount to PC.
To Reproduce Steps to reproduce the behavior: build:
west build -b mimxrt595_evk_cm33 zephyr/samples/subsys/usb/mass --pristine
connect usb port to PC.Expected behavior
Logs and console output
Environment (please complete the following information): OS: Linux (Ubuntu 22.04.1 LTS). Toolchain: Zephyr SDK 0.15.2
Additional context I found the issue was from
MODE_SENSE10
command do not support by zephyr msc.