SD Card Access very slow

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

SD Card Access very slow

ソリューションへジャンプ
2,463件の閲覧回数
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 件の賞賛
返信
1 解決策
1,755件の閲覧回数
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 件の賞賛
返信
6 返答(返信)
1,756件の閲覧回数
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 件の賞賛
返信
1,755件の閲覧回数
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 件の賞賛
返信
1,755件の閲覧回数
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 件の賞賛
返信
1,755件の閲覧回数
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 件の賞賛
返信
1,755件の閲覧回数
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 件の賞賛
返信
1,755件の閲覧回数
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