AVR Freaks

Mojo-chan,

thanks for the quick response. Ok, a simple parallell protocol sounds nice. Do you know if there are any C code examples online to look at?

Also, unsure what SAM refers to here?

It would be nice to avoid doing our own block management.

Ok, sounds promising. We don't use any file-system. We basically treat the SD-card as a big ring buffer today. We write sensor data in 16 byte chunks to the buffer, and periodically we will read from the same buffer. That's it. So we really don't need anything fancy. Stable and predictable is what we're looking for.

Wow, thanks for the extensive feedback. 

First, some more details on the application as requested above: The sensor cards are in quite harsh environments. From -30 to +70 degrees (outside, so slow temperature changes), quite a lot of vibrations. It's encapsulated in a container which is filled with silicon (not sure about the technical term for the material, another guy handles that, but the container is completely filled with the material so that's is a solid mass). It collects data at around 8 KB/sek. The data use written and read via 512 byte buffers to be able to write and read full blocks to the SD-card today. We are not using a filesystem but have implemented our own storage driver that handles this. All problems with corrupt cards are assumed to be handled by the SD-card (on error, we just move on with the write/read). It's not fatal if some data is corrupted, as long as it's a very small part of the total data collected. Each second or so of data collected is it's own entity, so a corrupt block will typically only destroy a very small portion of the overall sample set.

As said earlier, we have used SD-cards in production for quite a few years, with many sensors installed in several countries and different environments. We typically go for the more expensive cards with good specs from SanDisk. We also use a pretty solid push-push-holder for the cards. Overall this solution has worked fairly well, although with volume, the problems we occasionally have has become more annoying and costly. We have also seen an increase in the amount of problems with the cards since we started filling up the containers with the silicon-material for water protection.

The actual problems we are having are hard to analyze, since the cards are deployed in the ground in a solid mass of silicon, and not connected to a network most of the time. It is however intermittent and only occurs now and then. Some cards seems to have more problems than other. As stated above, we have seen an increase since we started to fill the containers with silicon, so we suspect some sort of physical cause. Maybe some material gets into the holder and expand/contract with temperature. Maybe the material changes some electrical characteristic in a very minor way, but enough to change the performance/behavior of the card.

So, to eliminate the possible physical issues, we would like to move to a chip-based solution and can be soldered to the card in production as all our other components, rather than inserting a SD-card post production. Soldering the SD-cards to the sensor board does not seem like a good solution in production as pointed out above.

So, from your comments, it looks like we have the following options:

• Raw NAND/NOR chip, and handle problems with corrupt data in the MCU. Maybe this isn't such a bad solution considering the simplicity and atomicity of the data we store. We can pretty much just ignore corrupt data and move on. This would probably be a very minor update to our software as we could still use SPI on the Xmega.
• An eMMC chip with SPI support as pointed out by mojo-chan (e.g. IS21ES04G). So 1-bit-mode is identical to the SPI protocol? A problem would be that very few eMMC chips seems to support SPI, so we would risk having to redesign the storage again if the component goes out of production as SPI support seems to be very rare in eMMC chips. I still haven't wrapped my head around the regular eMMC protocol. Maybe it would be easy to implement a bit-bang-driver for it and the Xmega. Has anyone tried this?