Robust storage

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

we're designing a new prototype of our sensor card and are looking at a better storage solution than the SD-cards we use today. We've used SD-cards for many years, and they have worked reasonably well, but we see some occasional problems with corrupt sectors as well as what we suspect are mechanical problems (SD-card loosing, or getting intermittent, connection to the card holder connectors) due to vibrations. Since the SD-cards are inserted to the sensor board in production, and then never removed, we don't really need the option of removing/replacing cards.

Ideally we would like to use a chip-based solution. That is, an IC that can be soldered to the board in production. We need roughly 2 GB of storage, temperature range from -30C to +70C and reasonable quick writes (not neccessarily many kb/s, but rather fast and deterministic write times for a few hundred bytes per burst write).

After som research, eMMC looks like a good solution. It fills our requirements and seems rather wide spread. However, since a while back, the eMMC chips don't support SPI anymore, and we're not familiar with the new protocol used. 

Has anyone used a eMMC with an Xmega successfully? Experiences? Suggestions?

Best regards,
zetter

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have a similar issue right now. The eMMC interface is a simple parallel one, it's not hard to work with. Some of the SAM parts have a dedicated peripheral for them.

 

You could also talk to a flash chip directly, and do your own bad block management.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nothing springs to mind by try googling "emmc 4-bit mode". The interface is basically the same as the SPI one on the protocol level, you just send/receive 4 bits at a time instead of 1.

 

SAM = Atmel's ARM chips. It stands for "Smart ArM" or something stupid like that.

 

What filesystem do you use? Maybe it already has bad block management. Ultimately, even with eMMC, the only way you can be sure to avoid corruption is to read everything back after it is written anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We need roughly 2 GB of storage

Wow, that is a lot of 16 byte chunks of data!

 

Can you switch to the micro SD card?

Obviously much smaller, and much less mass, and therefore perhaps will tolerate vibration better?

Also lots of sockets out there that are designed for cell phone PCB's, etc., again a rather physically rough environment, (although not - 30'C).

 

With only two GB of data needed, can you simply write the data to the card in 3 or 5 duplicate buffers.

On read back, read back all 3 or 5 and vote for the good data.

Three buffers will obviously handle one bad sector at a time.

Five identical buffers can easily handle two bad sectors at a time, without using any super sophisticated software.

 

That solution could, perhaps, even be implemented on your current hardware, with "just" a software update to handle the multiple simultaneous buffers.

 

I assume you are using an SD card, and parts, rated for the temperature span you mentioned?

 

JC 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you tried simply soldering the SD card pads onto the SD_card_socket's tabs, or to the MOSI,MISO,SCK,SS,CD pads on the PCB?  If the SD card is never going to be removed from the socket in normal use, then it should be soldered onto the PCB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eMMC is basically an SD card in chip form... I'm surprised they don't support SPI mode but maybe they are doing cost reduction.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
Have you tried simply soldering the SD card pads

That may work for a hobby one-off - but not in production.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We had problems with SD cards not staying in sockets too. Initially were using a dab of hot melt glue to keep them in place. Some sockets are better than others too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but we see some occasional problems with corrupt sectors

Gotta ask:

 

I assume the Brown Out Detector is enabled.

 

I guess the underlying question is WHY is there corrupt data?

 

Was it a mechanical / contact with the socket problem?

 

Did the device lose power, either intentionally, (User switched the device Off), or unintentionally, (Power supply glitch, power failure, etc.), during a write, or while data was in a buffer, but not yet written to the card?

 

I guess the point is this, it is helpful to know what the underlying problem truly is, otherwise one's solution might not actually fix the problem.

 

Is the power supply designed such that the SD card can complete a write when the power supply loses power?

 

JC 

Last Edited: Sat. Jun 24, 2017 - 01:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A real file system manages wear leveling, bad sectors (there are some, even from the factory, I am told), and such. You loose all of that by just writing to raw sectors. You take your chances with your "cheapness"!

 

My suggestion is to use a memory device that is large enough for a file system, and go with that. Elm Chan's FatFS works well with most AVRs.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
A real file system manages ...
Spansion (now Cypress) Flash File System (FFS) does wear leveling and power failure recovery.

Don't know if Cypress FFS does bad block mapping; it has a block driver so bad block handling might be in that driver.

Cypress NAND flash has an interface that would use two ports of an XMEGA (8-bit data, port for control signals) and the max size meets the size requirement.

Cypress NOR flash (SPI, QSPI) does not meet the size requirement.

 

http://www.cypress.com/documentation/software-and-drivers/brochure-spansion-flash-file-system-nor-spi-and-nand-flash

http://www.cypress.com/software-and-drivers-cypress-flash-memory

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I THINK that I have been told that the bad sector and wear leveling happens inside an SD card when you use the higher level access commands. I doubt that they come into play for raw sector writes. So, to a degree, I miss-wrote above. If my understanding is correct, FatFS does not, itself, do those things. but it triggers their application when the device is accessed in the way that a file system is expected to (and FatFS does).

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Is the power supply designed such that the SD card can complete a write when the power supply loses power?
Conversely, is the SD card designed for power failures?

Likely each of us has experienced a glitch on inexpensive SD cards.

 

Swissbit

microSD Memory Cards

https://swissbit.com/products/nand-flash-products/cards/micro-sd-memory-cards/

...

 

Key features:

...

  • Power Fail protection & Read Disturb Management

...

Mouser Electronics

Swissbit Industrial SD Memory Cards

http://www.mouser.com/new/Swissbit/swissbit-industrial-SD-memory/

(select S-450u tab)

  • Patented power-off reliability technology 
  • Optimized FW algorithms especially for high read access and long data retention applications

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SD cards are cheap rubbish. Most people prefer that. You can get industrial ones, but they are expensive.

If you just want a circular buffer, writing blocks sequentially and handling bad blocks is fine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have looked extensively for a competing solution to microSD and have not switched at this stage.  I have a push-push socket microSD card running from 0 degrees C to 70 degrees C with vibrations in excess of 150G at frequencies from 300 to 670 Hz.  There is a power supply monitor (interrupt triggered ADC voltage measurement of supply) and sufficient capacitance to unmount the card on brown out in order to complete any pending writes.  This is running from an xmega and logging ADC samples at high speeds (about 200 kSps or 400 kB/s running through elm Chan fatfs).  If anyone knows of a faster storage solution for an xmega please let me know!!!!! :)   The biggest issue with microSD is that sometime write delays in excess of 100ms occur which causes the sample buffer to overflow (I speculate that this occurs on block erases or when a remapped block is encountered).  Pre-erasing helps, but a new SD card is the best.  Use a good microSD I have found SanDisk high speed cards work okay, but since it is running SPI more expensive cards aren't necessarily faster although may be more reliable.  The point is you are already using a storage solution which has a micro interfaced to flash and a good SD card should remap blocks if you allow it to.  Most SD cards struggle with writing small amounts of data and you are likely wearing it out.  If you write 16 bytes of data I believe the SD card receives that copies all data from the current block then adds you 16 bytes and writes it back.  I have terrible write performance with buffers smaller than 512 bytes, so I suspect you may be repeatedly bashing each block by using small writes.  Can you store this data in another type of memory then write to SD card when the larger buffer contains a full page?  When you encounter corrupt data have you verified that it is a particular block? since you are writing such small chunks why not verify everything that is written and keep your own bad block file.  If it is just data corruption then that can occur with any storage.  I have had microSD cards writing data at up to 1MB/s with no corruption, but I need to use a 4kB page to achieve these speeds over SPI running at 32 MHz.  I have only avoided other storage solutions because they all seem to be slower than a cheap microSD when interfaced from an xmega and they take up more pins.  Writing your own basic wear leveling to use a standard flash chip shouldn't take more than a couple of days for good engineer to write and test.  This is also for a battery powered device which is assume is trying to use minimal power, so write times and power consumption are also probably higher or similar with other external flash solutions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've had good results using a small FRAM memory to cache data before it is written. That allows me to verify the write, and gives me atomic updates, and means that any delays when writing to SD card (block erase, bad block retries etc.) are not a problem.

I was going type cache the filesystem metadata in there too, but it proved unnecessary. And of course, being non-volatile the FRAM is fine with brownouts and unexpected power loss.

That said, really crappy SD card controllers might still corrupt themselves, so I'm thinking that raw flash memory might be a better option as then at least I'm in control. No need to do bad block mapping, I'll just map large chunks (say 64MB) as bad because who cares when your memory is multiple gigabytes?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cypress NAND flash has an interface that would use two ports of an XMEGA (8-bit data, port for control signals) and the max size meets the size requirement.

Another way is to add an external NAND flash controller to the XMEGA.

The following would be by XMEGA EBI SRAM LPC :

ONFI Compliant NAND Flash Controller

Reference & Specs.

Rev. 17

by Alexey Lyashko

23.06.2016

http://opencores.org/websvn,filedetails?repname=nand_controller&path=%2Fnand_controller%2Ftrunk%2FDoc%2FONFI+NAND+Controller+Avalon+MM.pdf

via http://opencores.org/websvn,listing?repname=nand_controller&path=%2Fnand_controller%2Ftrunk%2FDoc%2F#path_nand_controller_trunk_Doc_

This moves implementation of the NAND flash interface from AVR code to VHDL.

 

There are 8051 with internal NAND flash controllers :

On Hacking MicroSD Cards « bunnie's blog

http://www.bunniestudios.com/blog/?p=3554

...

The embedded microcontroller is typically a heavily modified 8051 or ARM CPU. In modern implementations, the microcontroller will approach 100 MHz performance levels, and also have several hardware accelerators on-die. Amazingly, the cost of adding these controllers to the device is probably on the order of $0.15-$0.30, particularly for companies that can fab both the flash memory and the controllers within the same business unit. It’s probably cheaper to add these microcontrollers than to thoroughly test and characterize each flash memory chip, which explains why managed flash devices can be cheaper per bit than raw flash chips, despite the inclusion of a microcontroller.

...

 

December 29th, 2013

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wouldn't bother with a controller, it's just another thing to go wrong. Get a nice 16Gb SPI NAND flash and all the problems with corruption and unpredictable timing go away.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:
Get a nice 16Gb SPI NAND flash ...
Where?

Likely most NAND flash is Open NAND Flash Interface (ONFi); ONFi is bit parallel :

MemCon 2008

ONFi: Achieving Breakthrough NAND Performance

by Amber Huffman
Principal Engineer
Intel Corporation

http://www.onfi.org/~/media/onfi/pdfs/memcon_2008_final.pdf?la=en

(page 13)

Enabling a Seamless Transition

(from bit parallel asynchronous to bit parallel synchronous)

at http://www.onfi.org/presentations

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do corruption problems go away with NAND? Did you mean NOR? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Meant NAND.

Corruption can occur for NAND and NOR (power failure, kernel panic, Windows BSOD, ...)

The MCU driving the flash controller can be resistant to such.

Another way is by corruption tolerant file systems; ReFS is an example of one (of several?)

 

Microsoft

TechNet

Windows Server

Resilient File System Overview

https://technet.microsoft.com/en-us/library/hh831724.aspx

...

This topic describes Resilient File System (ReFS), a new file system in Windows Server 2012, ...

...

 

Feature Description

https://technet.microsoft.com/en-us/library/hh831724.aspx#Anchor_0

...

... and guarantees data integrity by means of resiliency to corruption (regardless of software or hardware failures).

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm talking about gate oxidization. That's why NAND solutions have error detection and bad block avoidance

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who is making 16Gb serial nand? All I could find in a quick Google was 2Gb.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You could use two of these: https://www.micron.com/parts/nan...

 

They make you register for the datasheet, try micron1234@mailinator.com and "bugmenot!".

 

My mistake, 4Gb seems to be the largest available outside of eMMC.

 

By the way, IS21ES04G is eMMC and supports SPI. The datasheet says it supports 1 bit bus mode, which you can connect to an XMEGA SPI port. They do up to 64GB. I imagine other eMMC device support 1 bit mode as well, but I have not looked recently.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

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?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zetter, 1 bit mode for eMMC is slightly different to SPI, but only at the transport layer. All the commands are the same, and you can use the SPI peripheral plus a few other control lines. Actually, for performance you might want to consider using a USART in SPI master mode, as it tends to be a little faster due to having a FIFO.

 

In your application a raw NAND seems like it would work well, as you could just checksum every block. Note though that most of the gigabit range ones uses 4k or even 8k blocks, not 512b. In fact it's very likely that your SD cards / eMMC do as well, they just hide it behind a 512b/block compatibility interface. How they handle it will depend on the controller - hopefully they can do partial block writes, as you probably could with 4k blocks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the interim, could evaluate the following :

zetter wrote:
We also use a pretty solid push-push-holder for the cards.
Am uncertain that memory card connector has sufficient mechanical specifications whereas some latched hinge memory card connectors do have vibration and shock specifications.

Molex

http://www.molex.com/molex/products/listview.jsp?query=&offset=0&filter=&fs=&npp=20&sType=a&autoNav=&path=+inmeta%3Apromotable%253Dyes+inmeta%3ACollectionName%253DImpulse+inmeta%3Acategory%253DMemory%252520Card%252520Sockets+inmeta%3Astyle%253DHinge%2526partialfields%3D%28productname%3AmicroSD*%252520Card%29&channel=products

http://www.molex.com/pdm_docs/ps/PS-47219-001-001.pdf  (Molex, Product Specification, pages 2 and 3)

zetter wrote:
Maybe the material [silicon (sic)] changes some electrical characteristic in a very minor way, but enough to change the performance/behavior of the card.
Silicone is reactive; "might" alleviate by gold contacts in the memory card connector and on the memory card's edge contacts.

If possible, use epoxy as the product's encapsulate; its increased density might be a problem but epoxy can be tapped for mechanical fasteners and/or shock absorbers.

If not possible then evaluate a tent over the memory card connector; akin to some RF modules requiring an air gap around the module.

logo

MG Chemicals

Potting Compounds

http://www.mgchemicals.com/products/potting-compounds/

RF Digital

Documentation

RFDP8 RF Modules Datasheet

http://www.rfdigital.com/wp-content/uploads/2014/03/RFDP8.RF_.Modules.Manual.pdf

(page 53)

Potting, Encapsulation and Conformal Coating

...

If your application requires 100% sealing of the module, there is a way to do this very successfully without impacting the module performance. Simply place the module on your PCB. Place a plastic cover over the module (like a hat), make the cover large enough to cover the whole module. Apply glue around the bottom perimeter of the cover where it sits on the PCB. This allows the module to function in free airspace while there is a complete seal around it.

...

 

"Dare to be naïve." - Buckminster Fuller