In previous article (SD Card Testing), we discussed a test performed by embeddedTS where we took roughly 40 SanDisk SD cards and ran them through a stress test that eventually gave us a reasonable level of confidence and expectation about the lifespan of the tested media.
That test forms the basis for our qualification of SD media for sale with our products.
This qualification step is needed because media manufacturers are not very forthcoming with their internal state machine behaviors and specifications. Most of the time, the manufacturers of SD media do not publish their internal implementations. Unfortunately this has led us to discover it's relatively impossible to work perfectly with all media brands. Variations on interpretation of the SD specification have led to some media working exceptionally well, but while most media works without any particular surprises, some media work exceptionally poorly. This means while we can be compatible with the specification, it is not always possible to be fully compatible with individual implementations of the specification. It is very difficult to discover exactly why our controller works well with one manufacturer and occasionally fails catastrophically when attempting to use a different media manufacturer. Since embeddedTS cannot purchase and test every media implementation from every manufacturer, we have opted instead to release a testing process that our customers can use to qualify their own choice of media.
This testing process largely mirrors (on a smaller scale) the test performed in the previous article, and revolves around the doublestor application's media test capabilities.
To start you will need one or more embeddedTS single board computers, a collection of test SD or micro SD cards, the aforementioned doublestor binary compiled for your test architecture, and a computer with a serial console.
There are several architectures supported by Doublestor: Eabi, oabi, armhf, and x86. It is best to use the version compatible with your target architecture. The various doublestor binaries are found here:
https://files.embeddedts.com/apps/dblstorctl/
The commands to enter are fairly simple. The first sets up a running output so the test is visible while it runs:
./dblstorctl-eabi --primary /dev/tssdcarda --dmesg-follow &
Replace "/dev/tssdcarda" with the device node path to the SD media to be tested. *NOTE* This test is destructive. The SD media will likely be useless after this test has finished running.
Next, start the test itself:
./dblstorctl-eabi --primary /dev/tssdcarda --stresstest
At this point, the test will need to run for quite some time, potentially months for a full failure test. Normally at embeddedTS our qualification process stops at 2 weeks if no failures have been discovered. The output will show pertinent read/write cyclic data and any errors that the test may come across. The tests will eventually fail, the question is how long can it run without failing. This invaluable information provides for a reasonable expectation of failure rates in the field based on the quantity of data written, it also serves as a reasonable compatibility test for previously untested SD media manufacturers.