0
\$\begingroup\$

We are trying to debug a host SD card interface (4bit SDIO) and am having trouble finding a logic analyser that can do a full stack decode.

So my 'dream' device would be a logic analyser that can emulate any brand of SD memory card in FAT32 or exfat format, with a full trace playback of all data reads and writes, and how that effected the file system.

The issue we are having, is the file systems FAT table is corrupted after several hours of writing to an SD card.

There are solutions like this http://www.digikey.com/products/en?mpart=FRONTLINE%20SD&v=1133 (at $8k mind you). but it seems that only decodes the data layer, but doesn't give you the context of how the FAT and data files on the card would be effected.

Does anyone know of a solution?

\$\endgroup\$
6
  • \$\begingroup\$ This site is really centered on EE design, so unless your question is about designing your dream device, it seem off-topic. \$\endgroup\$ Commented Mar 13, 2017 at 10:17
  • \$\begingroup\$ Analysing is one thing, emulating is another. As the SD card is just an array of data blocks, figuring out the effect of a write operation would require the analyser to have already read your whole SD card and stored it in its memory for analysis. \$\endgroup\$
    – Finbarr
    Commented Mar 13, 2017 at 10:25
  • \$\begingroup\$ No matter what analyzer will you buy, you won't get the answer why the data is corrupted. It can be just bad SD card. \$\endgroup\$ Commented Mar 13, 2017 at 10:33
  • \$\begingroup\$ what @Finbarr said, but with the restrictions that you can never know what's stored inside an SD card, because the external block device interface is only linked through firmware to the internal memory blocks (which typically are of a different size, and are being exchanged on the fly – keyword wear levelling, copy on write). So whilst your SD card "emulator" might detect a bug in your OS, it might not detect a bug in your SD card's memory controller firmware or a flash defect. \$\endgroup\$ Commented Mar 13, 2017 at 10:33
  • \$\begingroup\$ As an aside, are you sure it's only the FAT table that's being corrupted? Is any of the information being written to files being corrupted too or have you not checked? \$\endgroup\$
    – Finbarr
    Commented Mar 13, 2017 at 10:55

1 Answer 1

3
\$\begingroup\$

There's several low-cost projects that emulate SDIO devices – in fact, SDIO is a standard you can use to implement your own device classes, so this is not surprising.

A recent effort is scanlime's on-the-fly FAT file generation SD card emulator (video here).

You can never know what's stored inside an SD card, because the external block device interface is only linked through firmware to the internal memory blocks (which typically are of a different size, and are being exchanged on the fly – keyword wear levelling, copy on write). So whilst your SD card "emulator" might detect a bug in your OS, it might not detect a bug in your SD card's memory controller firmware or a flash defect.

From a personal point of view, this looks like you want some PC-attached logic analyzer (e.g. sigrok + fx2lafw + FX2 evalboard) that captures (possibly hardware-slowed down) SD transactions, and interprets them in software on the PC, modifying an in-RAM file system image that should be consistent with what happens on the SD card. That way, you could take "snapshots" at any time, and with sufficient knowledge of the (luckily, very simple) FAT filesystem, analyze where the errors happen.

I'd argue that's only slightly better than directly debugging the file system driver of whatever's writing to the SD card, and software debugging is much, much easier. If you can be halfway sure the file system driver is bugfree (e.g. you use Linux' fat implementation, or VXworks, or windows embedded), you'd try to rule out bugs in the SDIO driver part of the OS, and if that shows no bugs, then, well, you've got broken hardware.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ I agree with Marcus that it is better to debug software. First step I would take is to analyze corruption (if you are knowledgeable in programming/FS you can easily figure out what is wrong with FS analyzing dumps). Next I would add debug to the driver/software, and then analyze logs. Here're only two devices involved - host and SD-card, and you can easily replace SD-card to see if corruption still an issue. If it is, problem is in driver/host. \$\endgroup\$
    – Anonymous
    Commented Mar 13, 2017 at 16:28
  • \$\begingroup\$ Hi Marcus. Your second last paragraph is essentially what I wanted, but it doesn't seem any mature tools for this exist. Thus we will concentrate file system driver debugging for now. I will give this another day then mark you as answered if no other better responses come in. THanks. \$\endgroup\$
    – labnet
    Commented Mar 13, 2017 at 23:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.