My apologies if this has been covered, I found similar threads:
However in my case I have wired Vcc of the SD card (adapter board) via a MOSFET so I could completely power off that part of the circuit (plus other things, like the RTC) in the hope of reducing power consumption to a few microamps (like: 5 µA).
I see a couple of problems, though. There is a SDfat::begin() function but not an end() function. Does this matter?
I also see references to a bug in SDfat where you cannot make multiple calls to begin().
I can see one possible solution, would this be OK?
boolean logSomething ()
// power on device here ...
// initialize library
if (!sd.begin (SD_CHIP_SELECT, SPI_HALF_SPEED))
return false; // failed to start
// write to file here ...
// close file ...
// power off device here ...
return true; // OK return
} // end of logSomething
So the SdFat object goes out of scope when the function ends, and thus it (should) be able to be called again later? Or not?
Also is there a function for flushing outstanding data? I don't want to yank the power away from the card if it is still writing something.
You don't want to power the card off and on.
I do, that's the problem. :)
I believe the sync function is what you are looking for also looking from the documentation:
The sync() call causes all modified data and directory fields to be written to the storage device.
Also close() does appear to also finish writing any data that is buffered from the documentation:
Close a file and force cached data and directory information to be written to the storage device.
As for shutting off the sd card I don't know if that will work but for now here is how you finish writting any data.
Just as an update, so far so good with the approach I outlined. I added the sync() call (thanks for the suggestion) and the board, in idle state, appears to use around 7 µA. A bit more than I hoped for but still not too bad. It is well under the self-discharge rate of AA alkaline batteries.
The file appears to be written correctly so far. I'll do a lengthier test, over time. :)
SD.h has a bug that prevents reinitializing an SD. SdFat allows reinitialization or changing an SD after power is cut/restored.
You can cut power to an SD if you close all files first.
When you restore power you must call sd.begin() and reopen all files. You can save and restore file positions by using curPosition() and seekSet().
There is no sd.end() call since SdFat can not properly close all files.
Please Nick, could you show us your wiring? I would also like to get your same results (7uA) by power cutting SD's Vcc via MOSFET.
It's all here:
Sorry I know the post is pretty old but it's what got me this far. I'm using sdfat also to shut off my sd, works great but after letting it sit over night the sd card will not reinitialize. I was just curious if anyone else ran into similar issues and hopefully found a solution.
I'm powering it with 4 AA's and this regulator:
Here's my code:
(broke the character limit, sorry)
I'm powering it with 4 AA's and this regulator:
Maybe the batteries are discharging to the point they can't power the SDcard?
The regulator needs 7 volts to work properly. Even 4 new AA batteries will be short of this.
Wide input voltage range up to 7V to 17V
Hmm good point, I missed that. Well I guess another few batteries would just make run longer anyway. I'll give that a try.
Might want to try a bigger set too. Maybe C or D cells? Do a Google search for "AA battery capacity". Lipo battery out of the question? That is the type I prefer. Rechargeable and all. :)
Powering off an SD with hardware is almost never worth doing. A properly installed SD idles at about 70 µA. AA batteries deliver about 2000 mah so that would power the SD for about three years.
Initializing the SD when you power it up may take 20 ma for a second or two so that can eat into the savings, same as 5 - 10 minutes idling.
Here (http://forum.dev.arduino.cc/index.php?topic=269004.msg1907901#msg1907901) is a post about a data logger that runs for a year on AA batteries without powering the SD down. The SD has the proper pullups to idle at low current.
Better to look elsewhere for power savings.
Hmm all good things to consider, thanks guys. Not sure what happened now but after running the batteries dead it will not initialize the sd card period. When I popped it in the pc it had to be formatted. Dunno what's going on at all now.
From the PC world - a power off during directory changes can wipe a disk.
Suspect that is possible in directory changes - even file adds/deletes as sections are rewritten.
Have tested this in real life and you see it rarely now as disks write data before power drops. SD writes/reads are possibly susceptible in low power conditions.
solution would be to monitor power and shutdown early.
Sure I get that. The thing is now though, it will not read an sd at all no matter what I do. It's got good solid power from the pc with a freshly made card, I know all that is good but still no luck. Is it possible for undervoltage to have damaged the reader? I don't see how but I won't pretend to know much. This is the reader I'm using:
I don't get it, all worked just fine before and all the other functions of the arduino work just fine. I checked the voltage to the sd and that all looks good.
If the supply voltage slowly tapered off to nothing, it could have damaged either or both of the two ICs on the board. U1 is the logic level converter and U is the voltage regulator. The voltage regulator should be an easy check. Insure 3.3 volts out.
Other people have had problems with that SD module. Some versions have a SPI level shifter bug that causes problems sharing the SPI bus with other SPI devices.
I have used it alone on the SPI bus without problems.
Is it possible for undervoltage to have damaged the reader?
I don't think low voltage will damage the level shifter or regulator.
Have you connected the module directly to 5V from the Arduino?
Well I checked everything suggested as far as I know. I bypassed the power switching pin, putting 5v straight to the vcc pin on the reader. I checked the regulator, solid 3.3 out. I tried various sd cards. I'm out of ideas. The only spi device is the sd reader so that shouldnt be the problem. I noticed at one point the atmel chip was pretty hot, not hot enough to burn me but still hot. That problem went away and I still don't know what caused it. I have a few of these pro-minis so I guess I'll try swapping it out. Wish I hadn't already hot glued it into its enclosure. If that doesn't fix it got any ideas? What sd reader would you suggest in place of the one I have?
Well on second thought I just connected the sd reader to the new pro mini and it works so I guess some how I toasted the first one. Still runs though code though. Fun fun
I've been looking into this for a little bit and thank you for the posts so far as they have defiantly been useful. In my project I have two cards on the SPI bus, one card which is the local memory and I have another which is a transport. The idea being that someone walks up with a transport key plugs it in, the arduino detects the key and starts an upload. Once the upload is complete then the user can unplug the transport SD.
My issue comes that the copy process would only work the first time and then the files would fail to write to the transport on the second insertion. If I rebooted the arduino it would work fine.
The way that I have found to get round this feels wrong however it works without any hitch so far. It is that the SDFat library uses the arduinos SPI.h library so by including it before include SD FAT
#error You must set USE_MULTIPLE_CARDS nonzero in SdFatConfig.h
then later I use SPI.end() to kill all SPI communications once all files are synced and closed on both cards, this allows me to reinitialise the SD cards when I want and they so far happily carry on from then as if nothing has happened. So my question is can anyone think of a specific reason why this would be unstable or thing that I should be particularly aware of.