In a 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 formed the basis for our qualification of SD media to be sold 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, and it can be 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 to test and provide a full compatibility list, 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 DoubleStore 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 DoubleStore binary compiled for your test architecture, and a computer with a serial console.


    The various DoubleStore 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.