SD Library stops working for 47 hours, then starts up again.

Created Tue, 03 Jul 2012 16:36:45 +0000 by Verdris

Verdris

Tue, 03 Jul 2012 16:36:45 +0000

Hi all,

I had the opportunity to let some of my ChipKit-based instrumentation log data from an incredibly energetic wildfire event - the perfect test! Unfortunately, when I got my SD card back, I found that I was missing 47 hours of information. Not just at the end of the datalogging, but right in the middle.

I have each reading timestamped in the log file with millis(), which I later translate into UTC when I do data processing. I found that my instrument logged successfully for about twenty minutes, stopped recording for 47 hours, then picked back up and recorded for another twenty minutes.

Here's the loop, really simple stuff:

void loop()
{
  if(count == 0)
  {
    Calibrate();
  }
  else
  {
    unsigned long T = millis();
    long L = ad.SampleChannel(2,samples);
    pot.setPosition(pArray[TestG()]);
    long S = ad.SampleChannel(1,samples);

    fout = SD.open(datafile, FILE_WRITE);
    fout.print(T);
    fout.print(" ");
    fout.print(L);
    fout.print(" ");
    fout.print(S);
    fout.print(" ");
    fout.println(G);
    fout.close();
    count--;
    delay(1000);
  }
}

The last event before it stopped was a normal datalogging event, and when it started up again the first event was a normal datalogging event, i.e., Calibrate() wasn't called. There's nothing in Calibrate() that would throw off the sequence, anyway.

I know it wasn't a power outage, because the files get headers when setup() is executed; the files would have the header printed between lines of data.

The calibration file that gets written to shows the same pathology, 47ish hours of missing data.

Thoughts?

rasmadrak

Wed, 04 Jul 2012 06:27:30 +0000

Which version of the library are you using? Timing issue with the SD card board that cause out of sync after 47 hours? Could it be a timer running over and resetting itself?

Verdris

Thu, 05 Jul 2012 17:56:25 +0000

Which version of the library are you using? Timing issue with the SD card board that cause out of sync after 47 hours? Could it be a timer running over and resetting itself?

The newest version that came with the latest test build. It's not an issue of the timer running over, because the millis() timer has a lifecycle of something like 50 days, and I saw errors twenty minutes after boot until 47 hours in. It didn't fail after 47 hours. It failed after twenty minutes, and restarted after 47 hours.

Besides, it's not like it's tied to millis(). The worst that would happen is that two months from now it reverts to 0 and starts over.

rasmadrak

Fri, 06 Jul 2012 18:24:10 +0000

A long shot - what was the temperature during the wildfire (as in - actual fire...?) scenario? It may be that the Chipkit simply shutdown or refused to process anything when the temperature went above a certain degree and started processing once the temperature lowered?

There might even be an onboard temperature sensor that stops the MCU from processing above a certain level (the same way throttling in PC CPU's handle things). I have not read the spec's of the PIC32 MCU, but it could be plausible.

If I recall correctly the time/date crystal is separate from the rest of the processing and runs independently - which could explain why it worked.

OR

It could just be bad luck, weird library issues, broken SD-card, etc. :/

KurtE

Fri, 06 Jul 2012 20:36:13 +0000

Probably another long shot... I assume there is more actual code associated with the variable Count or the program probably would not work at all, as I don't see it defined anywhere and if the value is 0, I don't see anything to make it non-zero.

edit: else if it were me, I would probably add more instrumentation code that maybe does several millis call during each loop and record those times as well. Like maybe a millis after your SD open call... Maybe one of these commands is hanging and you might be able to localize it down. The real question is, Is this repeatable?

Kurt