USB device MSC is too slow to access an SD in FAT32 (it works fine with FAT)

[ABatt.1]

Hi to all,

I use the Device MSC provided by CubeMX.

I wrote my own diskio.c file and every works fine with an SD of 2Gb formatted in FAT.

When I use n SD of 8Gb formatted in FAT32, WIndows take about 2 minutes to access the root directory. After this time, the Mass storage works fine.

What is the delay in enumerating files in FAT32?

Attached my usbd_storage_if.c

P.S.: FATFS works great with the same user_diskio.c and user_spi_diskio.c (attached)

Thanks to all.

[Tesla DeLorean]

Well USB-FS isn't exactly particularly fast, FAT 32 and EX structures are quite large, and these can be particularly slow on SD Cards if you've just random formatted them, and ignored the erase block sizes, and alignment issues.

MSC will get bogged down if you only allow for a single sector access, this has a massive overhead for SD Cards. Ideally you want to be doing 32KB or entire clusters at a time.

Check there's a MSC_PACKET_SIZE type variable, and it doesn't want to be ONE

[Tesla DeLorean]

usbd_conf.h

/* MSC Class Config */

#define MSC_MEDIA_PACKET           (8 * 1024)

[ABatt.1]

Hi TD,

I try

#define MSC_MEDIA_PACKET   (8 * 1024)

but still remain the issue. The strange thing is that after 2/minutes, the access on SD works fine, it is only the first phase that is very slow.

looking for some other parameter, Ifind this two in usbd_msc.h:

#define MSC_MAX_FS_PACKET      0x40U

#define MSC_MAX_HS_PACKET      0x200U

what are the difference between this parameter ?

Can I increase FS_PACKET to 0x200 ?

[ABatt.1]

MSC_MAX_FS_PACKET is inside an uint8_t array. So increase it is not a solution for my problem

__ALIGN_BEGIN uint8_t USBD_MSC_DeviceQualifierDesc[USB_LEN_DEV_QUALIFIER_DESC] __ALIGN_END =
{
 USB_LEN_DEV_QUALIFIER_DESC,
 USB_DESC_TYPE_DEVICE_QUALIFIER,
 0x00,
 0x02,
 0x00,
 0x00,
 0x00,
 MSC_MAX_FS_PACKET,
 0x01,
 0x00,
};

[ABatt.1]

I made some other test.

once the Mass storage is opened in Windows, reading is pretty good, but writing is very difficult.

I think that I have to change low level routine to obtain a good USB troughput.

I try to adapt the example.

I'll let you know how it goes

[Tesla DeLorean]

SPI isn't exactly the fastest way. Most use the SDIO/SDMMC peripheral to get tens of MBps rather than the few hundred KBps you're likely working with.

Benchmark the underlying IO routines, this will give you a better understanding of the bandwidth you've got to play with, and whether the USB side is terribly impactful on the whole speed issue, or not.

[ABatt.1]

Hi, I come back to the subject after several tests.

I have achieved decent speed with SPI and DMA (although only transcend brand SD cards support DMA), but the slowness remains.

Through wireshark I captured the USB enumeration both with the STM32 and with a USB-SD converter (using the same SD): the difference lies in the wMaxPacketSize parameter which in the STM32 is 64, while in the converter it is 512 ( attached photo).

How to configure the size of the data packet in the USB device (it seems to have been done: here)

I tried to change the fields

#define USB_FS_MAX_PACKET_SIZE 64U

#define USB_MAX_EP0_SIZE 64U

but different values ​​cause incorrect enumeration on the PC.

The MSC_MAX_FS_PACKET field appears not to be used (by changing the name, compilation occurs without errors).

Can you give me indications on the increase of the data package?

Thank you.

[Tesla DeLorean]

Bus packets on the USB are separate from those on the SD card interface, single sector interactions on the SD card have very large overheads, which diminish significantly when large blocks, perhaps whole clusters, can be read in a single interaction.

[ABatt.1]

The theory is chira, I needed some clarification on how to increase the packet size.

Changing the parameter MSC_MAX_FS_PACKET has no effect.

[ABatt.1]

Thanks. I'll move in this direction.

[MNema.1]

Hello, ABatt.1, Have you managed to solve the problem? I have the same symptoms with 8 Gb MMC - it takes too long for Windows to recognize.

[BOh.1]

Hello, I've received a lot of help from your uploaded source code and now I'm facing the same problem, too. I wonder if you have found some solutions. Thank you.

[Tesla DeLorean]

Two years later it might be healthier to describe your specific situation and expectations.

[BOh.1]

What a surprise few minute answer for years old question. Well, it is nothing different from the original problem. Windows took too much time to recognize when it is plugged in. It would be better if I could use HS device as you mentions, but my device is stm32f1 and only supports FS.

[Tesla DeLorean]

Well the STM32F1/SPI implementation isn't going to be particularly fast, and the FAT32 / EXFAT tables can get colossal.

Does the F1 part you've chosen support SDIO ?

The transfer size can also make a big difference to how efficiently the OS and the card interact with each other.

Outputting telemetry will give you some insight to the type and scope of interaction that is occurring.