SD Card Access very slow

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SD Card Access very slow

Jump to solution
1,400 Views
harish_k
Contributor I

Hi Everyone,

 

I am trying to get some profiling numbers for our upcoming project. I have connected a Class 6 SD Card to K60 eval board. The low level read access is very slow. Current rate for reading just a sector (512 bytes) is about 800 KB/s.

 

I changed the baud rate clock and this does NOT seem to affect read access. I get approximately same number for 4000000 and 25000000.

 

The low level read function _esdhc_read reads 4 bytes and then waits to check some status. This does not seem to be the most efficient way. How can I improve the performance?  

 

Thanks,

Harish 

0 Kudos
1 Solution
692 Views
PetrM
Senior Contributor I

Hello,

 

this code was written in a generic way to handle any number of bytes transferred. And the data need to be read sequentially from HW buffer after status bit signals that it's not empty. And there were some issues with the ESDHC status bits themselves...

So these are the reasons. If you have some specific scenario, you can write optimized read function of your own.

Anyway, changing baudrate doesn't help much because of the delays on all stack levels.

The only thing I see to improve the throughput is to use CMD18 (read multiple blocks with one command) instead of CMD17.

 

Regards,

PetrM

 

View solution in original post

0 Kudos
6 Replies
693 Views
PetrM
Senior Contributor I

Hello,

 

this code was written in a generic way to handle any number of bytes transferred. And the data need to be read sequentially from HW buffer after status bit signals that it's not empty. And there were some issues with the ESDHC status bits themselves...

So these are the reasons. If you have some specific scenario, you can write optimized read function of your own.

Anyway, changing baudrate doesn't help much because of the delays on all stack levels.

The only thing I see to improve the throughput is to use CMD18 (read multiple blocks with one command) instead of CMD17.

 

Regards,

PetrM

 

0 Kudos
692 Views
harish_k
Contributor I

Thanks Petr for the reply. 

 

Can you give some suggestion on how this can be optimized? We do not want to do any custom optimizations. Our requirement is to use with MQS File system.

 

The performance I am getting will not suffice for the next project. Also the number I am getting are nowhere near the numbers posted on K60 reference manual. The manual says transfer rate of 200 Mbps using 4 data lines. The SD Card class 6 specs are at 6 MB/s

 

Thanks

 

 

0 Kudos
692 Views
PetrM
Senior Contributor I

Well, you know, that value from manual is just about the bus capability. But it's definitely not about the HW ability and the real throughput when it comes to some communication protocol.

I'm sorry to say that, but it may be slightly improved only with different read function (use of DMA for example) and with the use of continuous read as I mentioned before (CMD18).

 

Regards,

PetrM

 

0 Kudos
692 Views
harish_k
Contributor I

With some profiling I noticed that there is a huge delay after CMD17 (read block command) and the first set of bytes to appear in the buffer. So as per your suggestion before I think performance can be improved by using multi-block read.

I tried to use CMD18. I could read the first block properly and then it gets stuck in the while loop

 while (0 == (esdhc_ptr->PRSSTAT & SDHC_PRSSTAT_BREN_MASK)){}; in the function _esdhc_read.

 

Do you have any sample code that you can share which uses CMD18 and CMD12? It will be helpful.

 

Thanks,

 

0 Kudos
692 Views
krenaud
Contributor I

Hello,

 

We are looking at using the K60 for our next project and one of the key points is being able to use SD High Speed 4-bit mode instead of SPI Default speed.

 

Harish, you are getting worse performance than a proper default speed SPI implementation so I wonder if you have been able to improve this since you posted your message?

0 Kudos
692 Views
DavidS
NXP Employee
NXP Employee

Hi Krenaud,

Our MQX development team is working to improve the driver performance and an update is expected in our MQX3.8 release mid next month.

Regards,

David