Very Slow SD Card Access

[weblar]

Hi,

I have an existing project running on my Kinetis K60 which uses the FatFS file system with the USB stack running as an MSD device. I'm using the ESDHC peripheral connected to a class 4 SD card as the storage device for the FatFS and MSD.

If I attempt to copy a file onto the USB MSD from within Windows, I get a transfer rate of about 60 kilobits/s which I would consider dreadfully slow.

Has anyone had any success with getting the ESDHC peripheral to run quickly? I'm thinking that there must be something wrong in my initialization routine (code taken from Freescale examples) such as in the SYSCTL register where I set the ESDHC clock divisor and prescalar however changing the values to make the clock faster makes little difference.

I purposefully haven't posted any code as there is a lot of it but I can where necessary.

Thanks in advance,

K

[mjbcswitzerland]

Hi Kevin

If you are loading data from the PC to an SD card via USB-MSD FatFS will not be involved (since the PC does the file system work), although sector read/write routines may be taken from it. The transfer involves USB (driver and MSD class) as well as the SD card interface (and low level routine) - plus some overhead from any OS or other SW coordinating things.

As a reference I get about 210kBytes/s write speed with K60 when saving data to a class 2 SD card using the uTasker project (built with CW10.5) and around 630kBytes/s reading from the SD card. The SD card writes make the speed to the SD card rather slower and a comparison between the read and write speed should help you determine whether the SD card intertface is really the bottleneck in your case or whether maybe the USB communication is reducing performance generally. I never found the SD card speed class to make much difference since it doesn't look to be possible to get much more throughput with this class of processor (I get similar results from similar devices with SDIO like LPC23xx, STM32 and maybe 30% less in SPI mode). Building with IAR achieves about 20% better throughput (as example of compiler influence).

Since there are various factors that are involved you may first need to analyse the SW modules used to see whether they are designed to work together in the manner that they are used in since it may not be down to the SDHC interface itself.

Regards

Mark

[weblar]

Hi Mark,

Thanks for your reply.

You are correct, the only common code between the FatFS and the USB MSD are the sector read and write routines. These routines however, are where I believe the bottle neck is although I'm yet to benchmark the speed of this. As a very crude example, I have written a screen capture routine which dumps the entire contents of an off-screen buffer (38,400 bytes) into a bitmap file on the SD card - this takes roughly 4 or 5 seconds or so to complete to produce a 308kb file (crude stopwatch timing, bitmap is 32bpp).

I'm wondering whether I am initializing the SDHC correctly or whether I have the clock speed set too high, so that the chip defaults to a much slower speed. Either way, I still think that there is much more performance to be had.

Another possible clue could be when the USB MSD enumerates. If I pause the debugger during enumeration, more often than not the line of code that the debugger stops on is a loop polling an SDHC register. Enumeration without the debugger attached can take up to 10 seconds - which I would consider excessive. This still leads me to believe that it is the SDHC not functioning as fast as it should be.

I think I need to do more investigating.

Apologies if most of that is waffle. I have the flu and I can't really think straight or see properly at the moment...

Regards,

Kevin

[mjbcswitzerland]

Kevin

Emumeration should generally be completed within about 70ms of the USB being connected - the host will then mount the SD card and read in the complete FAT so that it has a copy locally, which (depending on the SD card size) can take a few hundred milliseconds or even a second or so). 10s sound very long but it also may be that the host is slow to "show" that the drive is ready and recording the actual data transfer with a USB analyser is the best way to know exactly.

What I have seen from USB recording analysis is that SD card sector writes are quire slow - say 1.5..2ms to save 512 bytes. During this time there is not a lot that the embedded system can do apart from wait for the card to confirm that it is ready again - even if more USB data is received (which needs to be buffered because it can't be written yet) it doesn't improve overall write throughput since the transfer is only really completed when the last received sector is finally saved.

Monitoring HS USB activity between an SD card reader and a PC host doesn't show such long delays. Also the fact that it is using faster HW USB rather than the K60's FS USB doesn't make much difference since save/write speed is the predominent factor. This tells me that it may be necessary to use different write methods (rather than sector writes) to achieve best write performance. A 2ms write time would limit write speed to around 256kBytes/s even if the USB transfer were infinitely fast and no addition processor overhead was involved.

The industrial projects that I have been involved with have been biased to reliability rather than ultimate performance and so the write speeds of around 210kBytes/s for USB-MSD (where the host is performing the FAT) and about 100kByte/s for web based (FTP, HTTP - where the K60 is performing TCP/IP and also FAT) haven't been a major issue. However I suspect that the SD card readers (even the $5 ones) must be making use of some low level SD card interface features to break the sector write speed limit since they do achieve MUCH higher write speeds. I don't know what this is at the moment but I could imaging that there may be some methods of queueing writes internally or using larger block writes rather than sector writes, or something similar. I may connect up a logic analyser one day to the interface to see whether it shows "advanced" commands or some other tricks being used which could be used instead of the 'simple' sector read/write technique....

Regards

Mark

[mjbcswitzerland]

Hi Kevin

I did some experiments with multiple block sector writes and have achieved 860kBytes/s (7Mb/s) file data write speed with 25MHz SDHC clock speed when transfering files via USB-MSD (full speed) with K60 at 100MHz.

It was found that if the standard single sector write could be avoided during the data transfer the write speed was about 27x faster at the SD card level (the use of pre-delete CMD23 didn't improve things with the standard speed SanDisk card that I used but may help with certain types according to the SD card physical layer specification).

Maybe 50MHz SDHC clock would improve slightly but the full speed USB driver and MSD class layers are probably capping the max. speed in this test configuration.

There is another recent SD card speed thread that is also discussing this so I'll post the result there too.

Regards

Mark

P.S. With the SanDisk card that I was testing with I found that it was limited to about 240kByte/s write speed using single sector writing, showing that it was this speed that was limiting the original USB-MSD write performance (around 220kBytes/s).
Using multiple block writes I could get a raw write speed of around 6MBytes/s, showing that the USB speed and the USB-MSD protocol overhead has become predominant.

[perlam_i_au]

Here I share an example project to use the ESDHC, please review it.

Please remember to configure the SD_CLK to 50Mhz or 52Mhz. it would be difficult to get it from dividing system clock, you could use SDHC_CLKIN (select “external bypass clock” Mode in SIM_SOPT2. SDHCSRC) to input SD_CLK to get the required frequency.

[abdullahansari]

Hi Perla,

COuld you share the complete project for codewarrior as I am learning about SDHC and would like to have a project with initialization routines and all read write routines to observe how it works. I am using codewarrior 10.5 on my twrk60N512.

PS. I looked into above project of yours and it doesnt have any thing in the sources for k60

Regards

Abdullah

[perlam_i_au]

After download the folder please go to C:\(your download path)\ESDHc\build\cw\esdhc and select between K40 and K60 example project :smileygrin:

[abdullahansari]

Hi perla,

Thanks for the reply. I got that from readme file as i was selecting wrong workspace. The ESDHC project is running and helping me. But i dont see any project linked with k60hello world. Can you share that ? It would give me an idea of reading and writting constants

[perlam_i_au]

You mean in path C:\(your download path)\ESDHc\build\cw\hello_world\k60_hello_world? What is the problem? These project has almost the same structure than the ESDHc, what is different with hello world code?

[abdullahansari]

Hi perla,

What I meant is, though i have source file in the project for EsDHC but for k60 helloworld project, it doesnt show any source (.c or .h) files. The folder shows an exclamation mark in codewarrior environment only for hello world project. I dont see either the source files for hello world project in (My download file)/src. It contains only esdhc.c, esdhc.h, isr.c and isr.h..

What I predict is hello word project would write some strings onto the sectors of memory card.

[weblar]

Thank you for your example project. I will have a look and compare the differences between our code.

Kind regards,

Kevin