AVR Freaks

AVR forum - SD/MMC write block time so long?

dtlinker - Jul 27, 2006 - 12:59 AM
Post subject: SD/MMC write block time so long?
I am building a low-power battery operated application with a mega168 which will use a transflash(microSD) or MMCmicro card for long-term storage. The biggest power consumption on the entire board is writing to the card. I measure average write current at 11.5 mA for the MMC micro and 17 mA for the transflash.

Reading the specifications, it should "typically" take 0.5 ms to write a block, with a worst case of 240 ms. What I find is a rather steady 100 ms. If I can't reduce this, it would burn a lot of power and require a re-design for bigger batteries.

Is there something I should do to get a block-write closer to the "typical" value?

Thanks in advance!
Kartman - Jul 27, 2006 - 02:41 AM
Post subject: RE: SD/MMC write block time so long?
I think you might find different brands of cards may do things differently. The specs you speak of are probably the Sandisk specs - so try a Sandisk card and see if there is any difference.

Is the time you're measuring the write time AFTER you've transferred the data?

Another thing came to mind - are you writing one block at a time? If so, there may be a wakeup time that is causing your delay. If you write a number of blocks sequentially, does the time change?
dtlinker - Jul 27, 2006 - 09:35 PM
Post subject: RE: SD/MMC write block time so long?
Thank you for your reply.

I am using the SanDisk part, and I am writing one block at a time. What I am measuring is the actual current drawn and the time it is drawn during writing, since I am trying to minimize power consumption. i have done some additional tests and found that the write time is actually 50 ms, with the other 50 ms taken by my block read routine. I had no idea that block reading could draw so much current and last so long as well!

I have tried erasing the sectors in advance, but this does not seem to reduce the time or current consumption.

Any reduction in average time would have a huge impact on my power consumption, so ideas are welcome!
Nuno - Jul 27, 2006 - 11:14 PM
Post subject: RE: SD/MMC write block time so long?
What TWI/SPI speed are you using?
In my project, I measure 5-6ms on a Canon 16MB MMC card, with "simple" block write (no erase ahead).
dtlinker - Jul 28, 2006 - 02:39 AM
Post subject: RE: SD/MMC write block time so long?
I am using the max possible with a 1MHz system clock. I forget what this is, but I doubt that it has an effect, since I am looking at the time that it draws extra current for programming, and the card itself operates asynchronously at 20 or 25 MHz, as I recall. I am not including the block transfer time. Also, I did some experimentation, increasing the clock to 4MHz, and saw no difference in the write time.
Nuno - Jul 29, 2006 - 02:45 PM
Post subject: RE: SD/MMC write block time so long?
How about the Vcc to the card? What voltage are you using?
I think that if it's too low (let's say, out of spec) it will take more time (you have a decoupl cap for the card?).
dtlinker - Jul 30, 2006 - 05:07 AM
Post subject: RE: SD/MMC write block time so long?
You may be on to something there. I had thought that the voltage range was 2.7-5V, and for a complicated reason I have been using 4.5V. I have re-read the specs, and it is up to 3.6V. The set-up is at work, so I do not have access right now. I will report back the results with a lower voltage, but still in the range.
Nuno - Jul 30, 2006 - 01:36 PM
Post subject: RE: SD/MMC write block time so long?
After you fix the Vcc issue, you may want to try with a new card.
dtlinker - Aug 01, 2006 - 07:16 AM
Post subject: RE: SD/MMC write block time so long?
I tried with the correct voltage, and the result is unchanged.

I have ordedred a bunch of other/new cards, so that I can see if a "new" card will do the same thing, and also see if "premium" cards do better. I will report back after they have arrived and I have had a chance to test them.
dtlinker - Sep 08, 2006 - 08:24 PM
Post subject: RE: SD/MMC write block time so long?
I finally had a chance to try a fresh card, being careful to keep it within the specified voltage range. The results were the same. The time that the higher current is drawn during a block write is 50 ms, which is 100x what is listed as "typical".

Any idea why this is, or if there is anything I can do to reduce it?
ScottKroeger - Sep 08, 2006 - 10:09 PM
Post subject:
I believe the slow writing is caused by not erasing the blocks first. If you don't explicitly erase the blocks before writing them, the chip must erase them individually. Erasing takes considerably more time than programming, but it can also be done on multiple blocks within an erase group, or the entire group.

My applications have not needed great writing speed, so I haven't bothered with the complexity of pre-erase. Nevertheless, I believe it will help.

If you've ever timed file writes from your PC to a memory card, you know they can go much faster than you are experiencing. But the driver software is also quite a bit more complicated than you'll want in your little AVR.
dtlinker - Sep 08, 2006 - 11:42 PM
Post subject:
Thank you for your reply.

I have tried erasing the blocks in advance, and also multi-block write, but the write time current increase is still 50 ms.
ScottKroeger - Sep 09, 2006 - 02:03 AM
Post subject:
Well then this is a curiosity. My PC card reader can write well over 1MByte/sec to a typical SD card. That corresponds to about 0.5msec per block. So we know it can be done. Somehow I'll guess your SD card is not aware that the block you are writing has already been erased. You'd think that the card's internal controller would keep track of erased blocks in some hidden bit of flash. But if that is not true, then it may be that you must perform the erase/write in just the right sequence in order for the controller to understand that erase is not necessary.

Sorry I can't be more helpful.
bobgardner - Sep 09, 2006 - 03:57 AM
Post subject:
Any interrupts happening? Do both the avr and the sd card run from 3.3v? Maybe there is a voltage level prob and its always timing out because the done isnt hi enough? (just brainstorming. I was going to say something about fuses, but it looks to me like you are using internal 1Mz on purpose?. Scott: are you running at 16MHz to get .5ms write time?)
ScottKroeger - Sep 09, 2006 - 04:27 AM
Post subject:
The 0.5ms write times happen on my PC, which has a driver that I presume knows a lot more about SD/MMC cards than mine does. My AVR based SD designs run about as fast as dtlinker's. I have also run SD cards on my Blackfin designs (750MHz) and they're just as slow there. I believe it is a matter of us not understanding how to get the card to remember that it need not erase the blocks we are writing.

If you watch the write transaction on the SPI lines, you see that the write command is issued, the data is transferred quickly and that the part then goes "busy" for 50ms or so. I presume that the bulk of that time is spent erasing the block.
dtlinker - Sep 09, 2006 - 04:42 AM
Post subject:
Thank you for your reply.

Interrupts are disabled, and you are correct that I am using the default 1 MHz, but my understanding is that the SD card runs asynchronously at 20 MHz internally for writing.

For my test setup, the AVR (mega88) is running at 3.8V, and the SD card is run off of two outputs on the AVR, so that I can power it up and down under software control. The theoretically highest current draw is higher than the current output of a single output pin, so I use two in parallel. This means that the voltage on the microSD card is 0.7 V below the AVR, or 3.1 V. This matches the voltage that will appear at the output pins of the SPI interface, so I don't think that it is causing a problem.

I don't think it is timing out, because I get a "done" signal, and the timeout time would be 250 ms.

To be clear, I am measuring the time that the flash memory draws a higher current during writing a block, not the time to transfer to block to the flash.
dtlinker - Sep 11, 2006 - 06:37 PM
Post subject:
I got the following reply from one of the microSD vendors:
Quote:
Our write time performance is limited by flash:

Samsung SLC flash write time is 0.2 ms/page.
and 1 block = 64pages.
so in SD mode ( 4 bit) 1 block write time is 12.8ms/block.
so in SPI mode ( 1 bit) is 12.8*4= 51.2 ms/block.


Does this make sense to anyone else? I thought that the internal clock and buffers were independent of the internal clock and mode.

If it is right, it would mean that the maximum write speed in SPI would be about 10kB/s and in SD mode would be 40 kB/s, both of which seem much slower than the specifications.
ScottKroeger - Sep 11, 2006 - 07:04 PM
Post subject:
Write time is quite independent of transfer time. At 0.2ms per page, you have about 2.5MBytes/sec of write speed, which is consistent with a standard speed SD card. High speed cards can go perhaps four times faster than that.

I still believe the slow performance we are seeing is caused by a block erase being performed on every page write.

You know that 10 and 40KBytes/sec are not correct as you've undoubtedly witnessed the same card write much, much faster in your PC. Prove it to yourself by copying a multi-megabyte file onto it. My standard Sandisk 512M SD cards write at speeds above 1MByte/sec and a good bit of that slowness is in WinXP, not the card.

Later in the year, if I have time, I may put my logic analyzer on my PC SD card reader and watch what's happening.
dtlinker - Sep 14, 2006 - 01:34 AM
Post subject: Strange solution - SD write block time so long
Well, I have found a solution, but it seems to contradict the documentation.

The original problem was that when I measured the duration of increased current draw when writing a block to the SD card, it was very long, about 50 ms, rather than ~1 ms as expected from the documentation.

Th solution I found was speeding up the clock on the AVR! As I understand the documentation of the SD/MMC standard, the card has an internal oscillator that runs independent of the external clock, at about 20MHz, and that would govern the write speed. The external clock should just govern the rate at which data is transferred to the card, and stored in the buffer before programming the flash.

My original tests were with an AVR clock of 1MHz, with SPI at fosc/2, or 0.5 MHz for the SPI clock.

Just to exhaust the possibilities, I raised the AVR clock to 8MHz, for an SPI clock of 4 MHz. The time of increase in current due to block programming dropped to < 7 ms, or exactly proportional to the increase in clock rate!

As I said, this is not what I would expect, since I thought that the internal programming speed was independent of the SPI clock, but apparently it is not! In any case, this is a relatively easy solution for me.

I thought that others might be interested in this result.
ScottKroeger - Sep 14, 2006 - 06:51 AM
Post subject: RE: Strange solution - SD write block time so long
This is curious. My Blackfin design clocks the SPI at 20MHz, and doesn't write any faster than my AVR design. You wouldn't think the card's internal state machines need clocking from the outside. What happens if your code just goes away for a minute and then comes back and polls for completion?
Nuno - Sep 14, 2006 - 10:09 PM
Post subject: Re: Strange solution - SD write block time so long
dtlinker wrote:
As I understand the documentation of the SD/MMC standard, the card has an internal oscillator that runs independent of the external clock, at about 20MHz, and that would govern the write speed.


As far as I *remember*, the mentioned 20MHz was in a sentence like "SPI can be driven from 0 to 20MHz", which doesn't says anything about the speed at which it runs internally.
dtlinker - Sep 16, 2006 - 06:06 AM
Post subject: RE: Re: Strange solution - SD write block time so long
With some help from tech support at one of the card companies, I think that I now understand what is happening. What follows is a summary.

Apparently there IS a separate internal clock on the SD card. What happens is that between the command to write a block, transferring the data, and writing the data, the card does not go into idle mode, and continues to draw a significant amount of current. This means that if the transfer takes a long time, it will continue to draw current for a long time. The transfer time is directly proportional to the SPI clock rate, so this will affect the duration of increased current.

For my application, I will increase the RC oscillator frequency when writing to the SD card in order to decrease the total power used.
ScottKroeger - Sep 16, 2006 - 01:42 PM
Post subject: RE: Re: Strange solution - SD write block time so long
In your original post, you were seeing 100ms of current draw. I presumed your transfer time was far less than that, and you were seeing excessive current draw for more than the 0.5ms one might expect after the transfer completes and the write starts.

That's what I see in my design. My write transfer takes 225us, but the SD card does not return "ready" status for 25-50ms. I was expecting a total write time of under 1 milliscond. I found that Sandisk Ultra II and III cards go ready faster than standard SD, and that is consistent with decreased block programming time.

I'm glad your problem is solved, and curious why mine remains.
dtlinker - Sep 16, 2006 - 08:59 PM
Post subject: RE: Re: Strange solution - SD write block time so long
First, I have to correct my error. In my original post, I should have said that the increased current draw was for 50 ms, or 100 x what I expected.

I do not know what the long wait for ready status comes from. I have counted how many times in the wait-for-ready loop it takes, and it is about 70-80 interations at 8 MHz. I assume that this is <40 clock cycles per iteration, so this would be about 0.4 ms.

I have tried at clock rates up to about 13 MHz, which means an SPI of 6.5MHz, and at that rate the increased current draw is for about 4-5 ms.

How are you checking for ready status? I am sending 0xFF, and getting 0x00 back until the card is ready.
ScottKroeger - Sep 17, 2006 - 01:25 AM
Post subject: RE: Re: Strange solution - SD write block time so long
I check for ready exactly the same way.
All times are GMT + 1 Hour
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits