What causes an SD Card to hang?

Philldapill

I'm writting some code to grab an accelerometer sample, write it to an SD Card, and display the sample info on the screen using Parallax Serial Terminal and a slightly modified FullDuplex Serial.

My problem, is that as the program runs, it eventually hangs up until cnt rolls back around. Essentially, sometimes my repeat loop takes waaaay longer than it should, which causes my calculated waitcnt() time to be before the cnt time once the code hits the waitcnt() command. So, because of this, the program has to wait until the counter rolls all the way back around to my calculated time, then it proceeds as normal - until the glitch happens again.

I've narrowed my code down to the root cause. It's something in the SD code that hangs up for longer than expected, around 1/10th of a second. I can post code if needed, but this seems like more of a general question.

So, why would the SD Card hang and take longer than expected to write?

Mike Green

An SD card has its own controller inside that manages buffering and what's known as "wear levelling". This sometimes involves moving data from one block of the card to another, particularly when portions of the card are frequently modified. A write operation normally takes anywhere up to 10ms to complete. If you have a card with limited buffering and some blocks have to be moved around, I can imagine a write being delayed several times that 10ms period. It wouldn't happen often and I wouldn't expect the delay to be 100ms, but that's why SD cards sometimes take longer than expected to write data.

heater

Recently I read somewhere that there is no upper bound specified for how long write operations may take on Compact Flash cards (and perhaps read as well).

Is this also true for SD cards?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Philldapill

Ok, just a little more info... I've found that the SD Card hangs everytime after the 512th character. WHY? Does the driver write to a buffer, THEN to the SD Card itself?

EDIT: Yes, it does hang after the 512th byte. It takes around 15,884,784(give or take due to spin) clock cycles to write that to the card. That's just shy of·200ms...·Is this just a crappy, slow card?

Post Edited (Philldapill) : 5/26/2009 6:03:26 PM GMT

Mike Green

Yes. Sectors on an SD card are 512 bytes. The driver has two buffers, one for data, and one for "metadata". If the FAT16 file structure doesn't have any more space allocated for the current file and a new block has to be written to the end of the file, the FAT (File Allocation Table) has to be searched and the directory and FAT have to be updated to reflect the added blocks. The extra ("metadata") buffer is used for this process. You can avoid these additional delays by preallocating your data file using your PC. Just write data to the file until it's as large as you will need it.

With this additional file system overhead, I guess it could easily take 100-200ms to do a write if a new file extent has to be allocated.

rokicki

Hmm, 200ms does sound *somewhat* long, and that should also be quite unusual. Most buffer writes should only delay about 1ms.

Are you using sdspiqasm? Are you using fsrw?

It's worth digging into this and figuring out what's up.

Philldapill

Hmmm, You say preallocate using the PC, but I could also preallocate using the Propeller at startup, right? I'm thinking in my SD Card Initialization, I could have a loop that just writes something like 1MB of data, saves the file, then sets the write cursor back to the start of the file? Then, once the file is closed, it could simply erase all the data AFTER the last position of the cursor?

rokicki

BTW, I'm designing a new fsrw that uses "DMA" to help deal with this issue and to speed things up in general.

-tom

Philldapill

rokicki, I'm using fsrwFemto.spin.

Is there a faster version out there?

Philldapill

I could always devote an entire cog to buffering the data to the SD Card, correct? I mean, that's one less cog, but my program won't be able to run as it is...

What I'm thinking, is to write to a buffer in another cog, and the buffer cog is just devoted to writing everything in the buffer. This way, if there is a long hang-up, the buffer cog can wait until SD is finished doing it's business. Or is there a better way?

rokicki

I'll have to look at fsrwFemto.spin. I presume this is in the object exchange? If not, would you point me to the URL you got it from?

To implement your own buffering will be a bit painful, I'm afraid. The same cog that opens the file needs to be the one that writes
the data, so you'll need to use another cog that interacts with fsrw entirely, and get some sort of interface into that. Simplest
would probably be a shared buffer (maybe 1024 bytes is enough) and a pair of pointers (usual producer/consumer setup).
At what rate are the samples coming in?

-tom

rokicki

Okay, the fsrw femto should be plenty fast.

Would you be willing to:

1. Stub out your code so you don't need the accelerometer (just make it return a random number, say)

2. Make sure it's got the tick timing in there that reports 15M or something

3. Post the resulting archive.zip with all needed files?

I can test it out on my card set and figure out what's up.

-tom