cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4discovery + SDIO + DMA + FatFS = low write speed

addr4reg
Associate II
Posted on December 25, 2015 at 15:17

Hello everyone.

I'm trying to accomplish write speed above 6 Mbyte/sec on a Micro SD card using the STM32F4discovery. However, now I have only ~5.5 Mbyte/sec that is not enough for my purpose.

My configuration is:

MCU: STM32F407VG;

CPU frequency: 168 MHz;

SD Card: ''Smartbuy'', SDHC, 8 Gb, 10 class (the write speed in Windows explorer is ~10 Mbyte/sec);

Card FS: FAT32, 64 kb cluster size, formatted by Windows.

Mode: SDIO 4-bit, DMA, SDIO_CK = 24 MHz;

Wiring:

https://www.dropbox.com/s/15eykljz9jqa2bp/wiring.jpg?dl=0

;

Basic project:

http://stm32f4-discovery.com/2015/08/hal-library-20-fatfs-for-stm32fxxx/

;

Source code:

https://www.dropbox.com/s/pe1oolzgvr2jcjn/Firmware.zip?dl=0

.

What can be done to reach the higher speed?

Thanks in advance.

#sdio #stm32f4discovery #microsd
7 REPLIES 7
Posted on December 25, 2015 at 16:05

What can be done to reach the higher speed?

Increase the SDIO clock via the PLL's Q tap.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
addr4reg
Associate II
Posted on December 25, 2015 at 21:54

Thanks for your answer, clive1. I tried to increase SDIO_CK from 24 to 42 MHz but got unproportional growth of the speed. It variates from 5.5 to 6.25 Mbytes/sec.This is not enough, because my data stream has the speed 6 Mbyte/sec, so I need at least 7 Mbytes/sec for reliability. As I read on this forum, people get 10 Mbytes/sec and more.

Anyway, I don't understand why 24 MHz clock gives such low speed? Theoretically the speed should be about 12 Mbyte/sec with such a clock.

Posted on December 25, 2015 at 23:20

Write speeds of different SD cards are highly variable, even ones claiming to be in the same class. I would look seriously at SanDisk Ultra cards, UHS-1 rather than Class 10.

The predominant drivers of write speed are the card, the size of  the ''block'' of data being written, and  it's alignment against the intrinsic erase size of the of media. I would always try to write at least 32KB, the erase block is probably 128KB but check the reported characteristics.

Writing is always significantly slower than Reading. The controller on the media ''hides'' the underlying behaviour of the media, where a write of your new data typically goes to a freshly erased block, along with the existing data on the old block outside the area you are changing.

FatFs can work quite efficiently if you write smartly. If you write lots of small bits of data it will be slow. Some time invested in your buffering in the application will help significantly. Failing that the diskio.c layer needs to implement some caching, people generally avoid this because their systems are resource constrained. Better to fix on the app side.

A PC can given some feeling of a cards upper rates, but trying to compare the bandwidth and memory depth of a 3 GHz PC against an STM32 has some pretty obvious flaws.

Reading 32KB blocks should post numbers that correlate well against the SDIO clock, and the maximum you see there. The SDIO peripheral clock is specified to top out at 75 MHz (37.5 MHz on the wire). There's an errata with BYPASS mode, so DIV2 is the quickest setting available.

I wire-wrapped microSD sockets so I could evaluate different cards when I first added functionality to the STM32F4-DISCO, though I have custom boards, and other eval boards now with micro and full-size sockets. As I recall the microSD should support 50MHz clocks, but up there wire length, impedance and cross-talk are issues.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
addr4reg
Associate II
Posted on December 28, 2015 at 14:01

Thanks for the explanation, clive1. I'll try to carry out some experiments with different memory cards and clock rates, to reach a maximum speed. If this doesn't help, I'll try to use another platform.

addr4reg
Associate II
Posted on March 17, 2016 at 19:49

Well, it seems I reached write speed as high as 8 Mbyte/sec by increasing SDIO clock. However, this speed is only reachable when I continuously write large blocks of data. For instance, when I have 32 kbyte buffer and write it many times without stopping, I can reach 8 Mbyte/sec. But as soon as I make a pause between write transactions (to wait until I get a new piece of data) the speed falls to ~2 Mbytes/sec. So I think using the STM32 is not a good idea for high speed writing on an SD-card  because it has low memory for data buffering. As a result I solved my problem using FPGA+ARM SoC.

Posted on March 17, 2016 at 21:13

..to wait until I get a new piece of data..

Doesn't sound like the SDIO is that bandwidth limiting then? Perhaps you needed to separate the data collection into another thread, so the IO doesn't block.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
addr4reg
Associate II
Posted on March 18, 2016 at 01:07

>

Doesn't sound like the SDIO is that bandwidth limiting then?

I don't think that the SDIO bandwidth is the problem. It is rather an SD-card controller issue. Take a look at this 

http://goughlui.com/2014/01/16/testing-sd-card-performance-round-up/

. There is a 

http://cdn1.goughlui.com/wp-content/uploads/2014/01/SD-Card-Test-Results.png

 that clearly shows disadvantage of small block writing. Thus, even 512k blocks are not enough. Only continuous sequent write allows to reach the declared speed. So to deal with a real data stream a few megabyte buffer is required.

>Perhaps you needed to separate the data collection into another thread

My data collecting was being done entirely by the DMA, so I don't think it was slowing SDIO functionality.