Why is my microSD card misbehaving? (Micromod Teensy)

ninja2

ninja2

Well-known member
I'm using a Sparkfun Micromod Teeny Processor on their Micromod Main Double board, that includes a microSD slot.

The Teensy interfaces with the microSD over SPI #2

The sketch below simply opens a file on the SD, writes a couple of lines, then closes the file. It runs fine but only once. If I restart the program (by the reset button, or sketch re-upload) it always fails at initialisation
Code: 
sd.begin(SD_CONFIG)
The card will then malfunction until either the SD Card is removed & replaced, or it is power cycled on/off.

How can I stop this happening??

Code: 
#include <Streaming.h>

#include "SdFat.h"
#define error(s) sd.errorHalt(&Serial, F(s))

const uint8_t SD_CS_PIN = 44;
#define SPI_CLOCK SD_SCK_MHZ(50)            // maximum. Reduce if errors ...
#define SD_CONFIG SdSpiConfig(SD_CS_PIN, DEDICATED_SPI, SPI_CLOCK)

//SdExFat sd;       // SD_FAT_TYPE 2 = exFAT
SdFs sd;            // SD_FAT_TYPE 3 = FAT16/32/exFAT
FsFile logfile;

char logName[]= "SDtest.csv";

bool SD_OK = false;

void setup() {
  //Serial.begin(115200);                                             // not needed teensy
  while (!Serial && millis() < 1000);
  delay(1000);
  Serial << "\n\n=== Micromod_SdFat.b ===\n";
  Serial << "* Init SD: ";
  if (sd.begin(SD_CONFIG)) {
    Serial << "(OK)\n"; SD_OK = true;
  }
  else                     {
    Serial << "FAIL **HALT**\n";
    while(1);
  }
  // remove any prior file
  if (sd.exists(logName)) {
      Serial << "* delete file : " << logName << " ";
      sd.remove(logName);
      Serial << "(OK)\n";
  }
  Serial << "* open logfle : " << logName << " ";
  if (logfile.open(logName, O_RDWR | O_CREAT)) {
        Serial << "(OK)\n";}
  else {
    error("** ERROR ** logName failed to open. *HALT*\n");
    while(1);
  }

  if (logfile) {
    logfile << "A,BB,CCC,DDDD\n";
    logfile << "2,1234,56,7\n";
    }
  Serial << "* close logfle: " << logName << " ";
  if (logfile.close())  Serial << "(OK)\n";
  else                  Serial << "FAILED to close\n";
  Serial << "---- setup() done ---\n";
}

void loop() {}
 
Last edited:
Cancel :)
I just saw the comment "maximum. Reduce if errors" against
Code: 
#define SPI_CLOCK SD_SCK_MHZ(50)
"

So I reduced it to 20MHz and the problem no longer happens (doh!)
 
Yikes, those examples really should not be recommending 50 MHz SPI clock.

According to the SD card spec, 25 MHz is the maximum for SPI mode. Anything over 25 MHz is considered overclocking!
 
I have two identical Micromod assemblies (#1) and (#2). I tested on (#2) using the sketch above at 20MHz and it worked reliably (hence my "Cancel" above). But not so fast ...

I did not get same reliability on assembly (#1). It will start and run properly once, but if I restart using RESET button it fails as described in my first post. And I have to power cycle or remove / replace the microSD to get it to work again.

?? Suggestions appreciated ...
 
ninja2 said:
I have two identical Micromod assemblies (#1) and (#2). I tested on (#2) using the sketch above at 20MHz and it worked reliably (hence my "Cancel" above). But not so fast ...

I did not get same reliability on assembly (#1). It will start and run properly once, but if I restart using RESET button it fails as described in my first post. And I have to power cycle or remove / replace the microSD to get it to work again.

?? Suggestions appreciated ...
Click to expand...
Did you then try it at 10MHz? Or 5MHz? Maybe 20MHz is just too close to the point where it doesn't work and some hardware just barely sneaks by and other hardware has a harder time doing so.
 
I even took it down to 8MHz and still doesn't behave. Is there an ideal SPI frequency ?

It behaves as if logfile.close(); doesn't completely close the file, leaving the SD in an undefined hardware state, so when next I hit reset it doesn't initialise at boot 2nd time around and onwards
 
Last edited:
Perhaps swap the T_MM between the two. It may follow if one is having an issue, it may stay with the baseboard showing it has an issue, or it may disappear suggesting the one T_MM was not well seated.

Supposing alternate SD cards were swapped, or the same one was used on both showing the trouble stayed with unit #1?
 
Can you tell me more detail about the specific hardware used? Is it only Sparkfun products connected in their intended way? Or is some other non-Sparkfun hardware specifically designed for MicroMod involved?

I can tell you we've heard many reports of problems when using generic (or "no name") SD adapters meant for Arduino. The 2 common problems are: 1) slow buffer chip or even resistors meant to convert from 5 volt to 3.3 volt signals and 2) voltage regulator meant to get 5V power from Arduino and provide 3.3V power to the SD card which ends up with much less than 3.3V on the SD card if its input power by 3.3V rather than the intended 5V. No idea if this is relevant, since I can't see a clear picture of which hardware you're really using and how it's connected. But maybe mentioning these 2 very common problems at least gives you something to double check.
 
I'm using all standard MM Main Double board + Teensy + ZED-F9P + ESP32 wiFi.

Fortunately I have two identical setups, and I will swap things around (soon) as suggested by defragster to eliminate any hardware faults, although I'm distracted on another project for now.

I will also try a better SD card (cheap 1GB cards at the mo). I did reformat the SD cars using the SD_Formatter as recommend in bill griemann's notes, but I may have to do that again (running at those high SPI frequencies defintiely put some corrupt data to the SD).

It would help to know the ideal /default SPI frequency to use? I don't need high data rate as I am only recording sensor data to CSV at 1 or 2 Hz,

MM2.jpg
 
ninja2 said:
It would help to know the ideal /default SPI frequency to use?
Click to expand...

There is no single one size fits all answer. For a simple direct connection of MOSI / MISO / SCK to 1 card with wires under a few inches, 25 MHz should be fine. For a larger board like this were the wires (probably) go to several locations, you might slow to between 8 - 16 MHz. But faster may also be ok.

Special software that simulates and analyzes exactly how high speed signals will behave does exist, but it's incredibly complicated. That sort of analysis also depends on precise models of all the wires and surrounding material. Rarely is that sort of information published for these kinds of circuit boards. I'm pretty sure Sparkfun never does this sort of thing. So even if you had that analysis software and knew how to use it (no small feat just learning how to use it) without models for all the PCBs and chips, it wouldn't give any useful results.

Best answer is to try a conservative slow setting like only 8 MHz. Get everything working well first. Then attempt higher speeds only after you're sure things work at slower speed.

FWIW, I committed a change to Teensy's fork of SdFat to recommend only up to 25 MHz in all the SdFat examples. At least with future releases of the Teensy software we can have the examples the recommend only safe speeds. Hopefully it'll prevent anyone else from suffering these problems with 50 MHz SPI overclock.
 
FWIW after all the hassle the solution was simply to upgrade the microSD cards to better quality / name products.
 
You must log in or register to reply here.
Back
Top