Before posting, I checked against the STM32F7Cube v17.2 and this is still the same.
In my application I'm using an F7 with a SDcard in 4bit mode, clocked at 50MHz.
From the PC, I can read and write data. By de-layering the ST provided code and adding a read cache I have boosted read speed to ~7M/sec. Writes remain really slow. (The "pretty" HAL code with lots of function calls is really inefficient, even on a 200MHz processor, stripping out code made a improvement. The read cache was the biggest change.)
The root cause of the slow write speed is single-sector writes to the SDcard and busy waiting until they are completed.
The FATfs docs show this useful graphic that illustrates the problem.
However, the PC asks to write in larger blocks. The USB code in HAL supports multi-packet requests, but the usbd_msc code does not use that ability. The bulk only transport (BOT) buffer is defined as a single packet, and when the PC asks to send more data, the code ignores it and only handles a single sector.
i.e.
#define MSC_MEDIA_PACKET 512
...
uint8_t bot_data[MSC_MEDIA_PACKET];
...
len = MIN(len, MSC_MEDIA_PACKET);
/* Prepare EP to receive first data packet */
hmsc->bot_state = USBD_BOT_DATA_OUT;
(void)USBD_LL_PrepareReceive(pdev, MSCOutEpAdd, hmsc->bot_data, len);
However, in the endpoint structure, there are these two elements:
uint32_t xfer_len; /*!< Current transfer length */
uint32_t xfer_count; /*!< Partial transfer length in case of multi packet transfer */
Are there any plans to make the MSC code use the existing underlying support for transfers of more than one packet? This would drastically improve write speed.
James
PS. Sorry about the formatting at the end, after a number of minutes trying, I gave up trying to make it look normal. EDIT: Used HTML mode to make it a bit better.
