typical SD card power consumption?

[lpcware]

Content originally posted in LPCWare by fierz on Tue Feb 05 14:48:19 MST 2013
Aloha!

we are using a micro SD card for data storage in our battery operated device. I am using red suite 4.0, and building on the efsl lib. While testing the power consumption of our device under various circumstances, I noticed that it is using about 110mW (30mA at 3.7V) more when the SD card is inserted - that's 15% of the total device power consumption and this seems a bit excessive to me. I am writing about 1KB / minute to the card.

I have two questions:
1) does this power consumption only seem excessive to me, or is that just what an SD card needs
2) if the answer is no to the first question, what are typical ways of reducing SD card power consumption? Is efsl not optimized? Should I lower the SSP clock? Is it a hardware bug by my electronics engineer??

cheers
  Martin

[lpcware]

Content originally posted in LPCWare by stepe on Mon Jun 02 05:42:16 MST 2014
Test and use the two files on your own risk! Currently in use over here!
I simply renamed the files HERE to fight confusion with your original ones on your drive.
Rename and drop them into original library src path to make use of them.

sd_SDHC_.c
sd_SDHC_.h

New "Build" is then needed for RDB1768cmsis_efsl_lib

Good luck,
stepe

[lpcware]

Content originally posted in LPCWare by stepe on Mon Jun 02 05:29:24 MST 2014

---

Quote:

... but it seems some cards want even more cycles to power down...

---

This is exactly what I observed after having grabbed a number of different branded cards.
Regards, stepe

[lpcware]

Content originally posted in LPCWare by Rob65 on Fri May 23 11:09:11 MST 2014

---

Quote: wmues

Quality control is mostly non-existant in software, especially in board support packages.

---

Well known facts indeed, one of the reasons why I mostly do not trust the 'drivers' that come with LPCXpresso or other stuff like LPCOpen  :~
I did some (a lot of) testing with different filesystems for SD card and EFSL seems the one that worked best for me.
I do know about the extra clock cycles, I have access to the full SD card spec and have read and understood it, but it seems some cards want even more cycles to power down...

[lpcware]

Content originally posted in LPCWare by wmues on Fri May 23 00:45:39 MST 2014
It is well known that a SD card in SPI mode needs 8 clocks after the last command.
It's a requirement in the SD card specification.

Quality control is mostly non-existant in software, especially in board support packages.

Regards
Wolfgang

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu May 22 22:55:59 MST 2014

---

Quote: stepe
Hi all,
should you ever come across this discussion, consider it solved!
It took us several approaches to get there  :)

---

This is great news.
I have been struggling with this for some time and discovered that some cards indeed give much lower power use than other cards but never investigated exactly why (I ran out of time to finish the project so we just took the 'golden' card).

I know there is some information in the SD card specs about adding extra clock cycles but never bothered to look if efsl is actually following the spec - good to know that some are still watching over us ;)

P.s; any information on SDHC is highly appreciated.

Regards,

Rob

[lpcware]

Content originally posted in LPCWare by stepe on Fri May 16 14:05:02 MST 2014
Hi all,
should you ever come across this discussion, consider it solved!
It took us several approaches to get there  :)
The solution:

( using RDB1768cmsis_efsl_lib )

it is NOT sending the card into "Idle" state!! As Martin said above, you may not want to close the file and void all pointers only to reenter them a few seconds later again.

> In some datasheets you can find the statement that the SD card goes to power saving mode when it receives no command within 5ms - and should only
> consume 250uA at most there. This doesn't seem to happen though!?
Yes it does: we found a couple of cards that do exactly this without any assistance from firmware! But only a few of them (with the used library).
My experiences from other busses told me, that you can solve a buslock sometimes simply by asserting a few additional "empty" busclocks!
And with that single line...

nonsense=if_spiSend(&efs,0xFF);

... in our code (next line after a typical buffer flush) we solved this. The internal state machine of the (micro) SD-Card gets the needed clocks with
empty data or command arguments to switch to its sleep state, from which it can wake up very fast, drawing less than 1mW of power in between!
This is a huge saving, compared to cards that consume up to 250mW all the time even not writing anything most of the time. The hardware engineers did
their job, now it is up to you programmers to make use of this feature to save the planet.

=> All cards tested so far where doing it perfectly after this patch!

One final note: this is not depending on the speed class of SD-Cards nor their size. Some 8GB cards did it themselves, others not. It's the flash controller
inside that makes the difference. Also for the power consumtion. I won't tell the brand names thogh ...

Last note: since you made it up to here, you get another hint. With only a few additional lines the RDB1768cmsis_efsl_lib can be enhanced to be ready
for SDHC (high capacity) support! Drop a comment below it you need more on this.

Regards
Stepe.

[lpcware]

Content originally posted in LPCWare by fierz on Wed Feb 06 13:56:20 MST 2013

---

Quote: wrighflyer
As I said above you could modify the driver to send CMD0 to the card before you enter a 20-30 second period of inactivity. "Idle" state is how the card powers up and CMD0 tells it to go back to idle. It's power consumption *may* be severely reduced in this state. To get it back from idle it's just like card insertion or power up. You send ACMD41/CMD1 to tell it to leave idle state but this can take 100ms+ so you don't want to be doing this all the time. The card software (assuming it reads the card present signal) will likely re-initialize whenever it thinks it sees a !CP to CP transition so while you may need to add code to send the CMD0 to force to idle, getting it back could be as easy as faking a card present transition.

Obviously don't do any of this stuff with a file open, so close files first. You may even need to unmount and later remount depending on how the software stack is designed (I'm only really familiar with Chan's FatFs).

---

Hmm, I would rather not muck around in the efsl driver if I don't absolutely have to. Does anyone know whether the FatFS driver is better power-consumption-wise?
What I could do is to just close the file and call fs_umount() to unmount the card, that also saves a lot of power, and whenever I need to write, mount the card again and reopen the file. It just seems like a stupid programming excercise, violating KISS, bringing lots of potential for problems with it (in a few % of all startups of my device, the SD driver doesn't recognize the card properly - and I can't have that happen if I want to write to files). I just don't quite understand why the SD card itself doesn't enter power saving mode after not receiving a command for 5ms?

cheers
  Martin

[lpcware]

Content originally posted in LPCWare by wrighflyer on Wed Feb 06 11:19:57 MST 2013
As I said above you could modify the driver to send CMD0 to the card before you enter a 20-30 second period of inactivity. "Idle" state is how the card powers up and CMD0 tells it to go back to idle. It's power consumption *may* be severely reduced in this state. To get it back from idle it's just like card insertion or power up. You send ACMD41/CMD1 to tell it to leave idle state but this can take 100ms+ so you don't want to be doing this all the time. The card software (assuming it reads the card present signal) will likely re-initialize whenever it thinks it sees a !CP to CP transition so while you may need to add code to send the CMD0 to force to idle, getting it back could be as easy as faking a card present transition.

Obviously don't do any of this stuff with a file open, so close files first. You may even need to unmount and later remount depending on how the software stack is designed (I'm only really familiar with Chan's FatFs).

[lpcware]

Content originally posted in LPCWare by frame on Wed Feb 06 11:11:30 MST 2013
You might ask the SD card vendor -  not sure what the "block/card management"
by the card controller involves. But if you write about twice a minute, it would be
surely worth the effort to put it into power save mode.

I had not yet to design a battery-powered device using Flash in this way.
Instead, I investigated devices that saved data to Flash after power-off,
while living from a capacitor charge. A one-shot issue, so to say.

[lpcware]

Content originally posted in LPCWare by fierz on Wed Feb 06 09:49:58 MST 2013

---

Quote: frame
Your current consumption is quite normal.
Flash, either NAND od NOR, requires a voltage of 9...12V for erasing and programming.
This voltage is usually created internally by switched-capacitor boosters. As this is not
tremendously efficient, and erase usually happens blockwise (much cells to erase),
Flash pulls a lot of current during program and erase.

Not that this will help you much, but to serve as an explanation[IMG]http://knowledgebase.nxp.com/images/icons/icon9.gif[/IMG]
Maybe you can reduce the amount of data, or increase the battery capacity...

---

But that's exactly the point - I am writing a single 512 byte block about once every 20-30 seconds, and doing nothing in between - I fully realize that writing data should cost energy, but why is doing nothing costing me 100mW??

[lpcware]

Content originally posted in LPCWare by fierz on Wed Feb 06 09:48:35 MST 2013

---

Quote: ppx
The Sandisk manual posted here used a FET to turn off the drive when not in used. Did you do that? Also, even with wear-leveling and error-correction, writing every second continously will wear out the flash after a certain time. Read the manual carefully

---

I don't really write every second - the efsl library will only write a full sector of 512 bytes, so it will only write once about every 30seconds.

I did some more testing: changing the SPI clock has no influence on power consumption, whereas exchanging my 2GB micro SD card from Transcend for one of Kingston dropped the power consumption by 15mA (or 50%). So I am thinking that it is an issue of the SD card controller itself. Reading the SD card specs of SANdisk, I found the statement that the SD card goes to power saving mode when it receives no command within 5ms - and should only consume 250uA at most there. This doesn't seem to happen though!?

cheers
  Martin

[lpcware]

Content originally posted in LPCWare by frame on Wed Feb 06 04:13:22 MST 2013

---

Quote: fierz
Maybe I should add some info on my application: My devices logs measurement data once per second.
It just runs for hours logging data. It writes about 25 bytes per second. As far as I understand efsl,
efsl will buffer data by itself with a buffer size of 512 bytes (one write every 20 seconds).
I tried doing a larger buffer myself, with 1 or more KB, but it makes absolutely no difference on power consumption.
Also, closing the file with fclose() has no influence on power consumption. The only thing
that makes a real difference is when I call fs_umount(), which saves about 80-90mW power,
removing the SD card saves the remaining 20-30mW.
=> buffering and batching the writes doesn't seem to be the problem;
efsl is doing something to waste power even when nothing is being written :-(

---

Your current consumption is quite normal.
Flash, either NAND od NOR, requires a voltage of 9...12V for erasing and programming.
This voltage is usually created internally by switched-capacitor boosters. As this is not
tremendously efficient, and erase usually happens blockwise (much cells to erase),
Flash pulls a lot of current during program and erase.

Not that this will help you much, but to serve as an explanation[IMG]http://knowledgebase.nxp.com/images/icons/icon9.gif[/IMG]
Maybe you can reduce the amount of data, or increase the battery capacity...

[lpcware]

Content originally posted in LPCWare by ppx on Wed Feb 06 03:47:39 MST 2013
The Sandisk manual posted here used a FET to turn off the drive when not in used. Did you do that? Also, even with wear-leveling and error-correction, writing every second continously will wear out the flash after a certain time. Read the manual carefully

[lpcware]

Content originally posted in LPCWare by wrighflyer on Wed Feb 06 02:28:05 MST 2013
Your 30mA sounds pretty typical to me. As noted above some cards are spec'd to be up to 100mA. Perhaps you can explore card deselection when inactive?

[lpcware]

Content originally posted in LPCWare by fierz on Tue Feb 05 23:25:36 MST 2013

---

Quote: cmcquaid
You could take a look at some typical datasheets.

http://media.digikey.com/pdf/Data%20Sheets/M-Systems%20Inc%20PDFs/SD%20Card%20Prod%20Family%20OEM%20...

This SanDisk family is specced at a maximum of 100mA for writes.

Consider turning it off when you're not using it, buffering and batching your writes, etc.

---

Maybe I should add some info on my application: My devices logs measurement data once per second. It just runs for hours logging data. It writes about 25 bytes per second. As far as I understand efsl, efsl will buffer data by itself with a buffer size of 512 bytes (one write every 20 seconds). I tried doing a larger buffer myself, with 1 or more KB, but it makes absolutely no difference on power consumption. Also, closing the file with fclose() has no influence on power consumption. The only thing that makes a real difference is when I call fs_umount(), which saves about 80-90mW power, removing the SD card saves the remaining 20-30mW.
=> buffering and batching the writes doesn't seem to be the problem; efsl is doing something to waste power even when nothing is being written :-(

[lpcware]

Content originally posted in LPCWare by cmcquaid on Tue Feb 05 19:22:23 MST 2013
You could take a look at some typical datasheets.

http://media.digikey.com/pdf/Data%20Sheets/M-Systems%20Inc%20PDFs/SD%20Card%20Prod%20Family%20OEM%20...

This SanDisk family is specced at a maximum of 100mA for writes.

Consider turning it off when you're not using it, buffering and batching your writes, etc.