With my LED cyr wheel I kept getting random errors in reading data from my SD card with Ardunio code. Sometimes init would fail, even at half speed. Most often I would get corrupted data, or not be able to read the filenames. Worse, it would start to read and then fail. Searching around, I found it could be one of the following problems:
* Bad SD card (I tried a few of them)
* Improperly formatted SD Card (I used the official SD Card Formatter from SD: https://www.sdcard.org/downloads/formatter_4/ and it still failed)
* Floating CS (Chip Select / Slave Select) pin. I made sure I had the Chip Select pin was correct, and it was. This can be set to anything you want as long as it is wired properly and passed to the initializers.
* Incorrect voltage for the SD Card; it needs 3.3v. Now…long story short: this was the problem, but I thought it wasn’t because the SD Card Adapter from PJRC has an onboard voltage regulator.
I poked through the SdFat library quite a bit adding in debug logs and couldn’t figure it out.
Finally, I poked at the voltage that the SD Card Adapter was reading; it had a 5v input and the regulator was outputting about about 3.0something volts. I thought this was okay…but later I came back to it, and wired the 3.3v directly from the teensy output to it. Then stuff started working!
So: be warned. The PJRC Teensy SD Card Adapter needs a separate 3.3v input (and solder together the 3v joint). The onboard regulator doesn’t work well enough!
UPDATE: I’m not 100% confident this was the problem. Dealing with the SD card has been a nightmare due to read errors and inconsistency. I could reproduce the corrupt data problem on my breadboard and with my physical hardware, which is why I felt like the voltage was the problem. However, in my LED wheel I still had issues, and it seemed to be due to wire length and size. I’m now using 22 gauge wires with shielding, and slightly shorter. It seems to work so far.
UPDATE 2: Maybe I am just an idiot; after re-wiring a bunch, I realized what CS pin I thought I was using may not have been right! That may have been my problem all along..
// make sure that the default chip select pin is set to
// output, even if you don’t use it:
pinMode(10, OUTPUT);
thanks Josh — but that doesn’t make any sense. Why would you have to do that? Nothing should be utilizing the default CS pin (10).
if you were using the standard Arduino SD library, then the hardware SS pin must be kept as an output or the SD library functions will not work.
Not sure if that’s the case for the SD library you are using.
Also: why not just use the standard SD library?
That is strange, but I see they document it:
http://arduino.cc/en/Reference/SDbegin
I’ll have to look at why in their code. I use the same SD library from AdaFruit; I forked it:
https://github.com/corbinstreehouse/SD
I mainly fixed their library to work with Teensy; I should look back at the original SD from Arduino and see how it goes.
Thanks for the tip!!!
Yup; did some research. The standard SD card library in Arduino:
https://github.com/arduino/Arduino/blob/1.0.6/libraries/SD/utility/Sd2Card.cpp
And the latest official release (recently in github now!):
https://github.com/greiman/SdFat/blob/master/SdFat/Sd2Card.cpp
The Arduino version is years and years out of date.
I should say, SD is built on top of SdFat, and includes an ancient version of SdFat.
The need for the SS pin to be configured as an output is a function of the ATMega328P (the Arduino Uno’s micro controller). Not a function of the SD library. If that pin is not configured as an output, then the ATMega328 will not ignore its value.
In other words: unless you are using the Arduino’s hardware SS pin w/ your SD Card communication, you will need to set it as an Output so that the arduino knows to ignore its value (because you are using another pin as the SS).
Nick Gammon talks about this,
so you could google him + SPI
Ah…ATMega… The Teensy uses an ARM chip, so it probably doesn’t apply there. Still, good info to know, and I might as well use the default SS pin. Thanks