I think the use of Software SPI for the LIS3DH in the AssetTracker library is a bug. Except since the AssetTracker doesn’t really use the LIS3DH accelerometer, no one ever noticed it. I noticed that when I did wake on move with the asset tracker and meant to fix it, but then completely forgot about it until you just mentioned it.
1 Like
@rickkas7, I’ve been using SdFat on an Electron (SPI) very successfully (thanks!). However, my code is designed to store files on the SD and then go to sleep using System.sleep(uint16_t wakeUpPin, uint16_t edgeTriggerMode, long seconds,SLEEP_NETWORK_STANDBY);
Since this uses an STM32 STOP, the code continues from where it left off after the call and RAM should be maintained. However, the SD does not work. Note that I do turn off power to the SD (via FET) before sleeping and then back on (with delay to allow it to start up). However, not sure that shouldn’t affect anything.
My question is, what’s the best approach for maintaining SD functionality through the sleep?
1 Like
Huh. I never tried that. I’ll give it a try and see, but my guess is that you’ll have to do all of the SPI setup again after waking up from a stop mode sleep.
@rickkas7, is that not done by begin()? I tried that and it did not work. To be fair, I didn’t exactly do any deep debugging yet.
I should have assumed that you already tried calling SPI.begin() again 
1 Like
@rickkas7, I’ll have to look at the constructors to see if any hardware stuff is going on there. I’m also going to try and NOT power off the SD to see if there’s an issue there.
The SD must be reinitialized if you remove power. You must close all files before removing power.
The SD has a 32-bit micro-controller and lots of RAM buffer so you can’t just power it off.
In many applications Just allowing the SD to sleep with power is better. Most microSD cards sleep at about 100 micro-amps. Cards quickly go through several levels of sleep.
@whg, understood. I do close all files before powering off. However, I find that the microSDs I’ve tried seem to sleep at 7ma or so and I don’t know why it isn’t going lower. In my Photon version, I deep sleep and power off the SD but on wake it does a full reset so I have no issues. However, not doing a full reset is the issue here. I’ll do my tests without powering off the SD and see what happens. I’m also going to measure the SD current just to be sure.
I ran the TryMeFirst example with a 32GB Samsung EVO card.
At first it looked like it was sleeping at 0.44 ma. I then pulled the card and the current was still 0.33 ma.
The problem was a 10K pull-up resistor on SCK. SCK is pulled low when SPI is idle.
0.33 ma is 3.3V/10,000 ohms.
The socket module was a cheap, $0.95, ebay module. You don’t need a pull-up on SCK.
With a bare socket the SD sleeps at 102 micro-amps. A pull-up on chip select might be OK.
2 Likes
@whg, I don’t have a pull-up on SCK but I also don’t have a pulldown on CS so that is something I’ll try and may explain why it’s not going to sleep possibly.
Is this SdFat library what you are using with the SD card on the LED Display Breakout that I just received?
Don’t use a pull-down on CS, nothing or a pull-up on CS
The card won’t sleep unless it is initialized. You must call sd.begin().
I just run the TryMeFirst example and then read the current value while the example runs in loop() {}.
1 Like
Ok, I tested the code you suggest here and it does work. It is twice as fast as the software SPI, so an improvement. DId you have any progress in trying to get DMA to work with SPI1 on the Electron?
There is a fix for hardware SPI1 on the Electron. It will be in a system firmware version after 0.5.3-rc.2 and 0.6.0-rc.1. I tested the fix and it solves the problem with sdfat.
Awesome. Can you point me to the issue or pull request on Github which solves this problem? I am curious what the issue was.
EDIT:
Nevermind, I found it myself, issue 1080
so does the try me first example work with spi config 0? I am getting the same error messages and cannot get my Electron to write to the sd card. I used the same card and shield connected to a mega and it works fine so it is not the hardware. Any help is appreciated.
Thanks
I am trying to run the trymefirst example on a photon. I have changed the spi configuration to spi 1, but am getting an error on the sdfat call. What am I doing worng?
@MichaelRensing, I just loaded the trymefirstexample and made the changes to SPI_CONFIGURATION and chipSelect as you did. Everything compiles fine. Did you make sure to select a Photon as the target? Did you also make sure to select version 0.5.3 or later?
1 Like
Thanks. I just tried again and selected a photon device to verify against. This time it worked.
1 Like