From: Vladimir Vassilevsky on


Tim Wescott wrote:

> On Wed, 20 Jan 2010 09:00:26 -0600, Vladimir Vassilevsky wrote:
>
>
>>D Yuniskis wrote:
>>
>>>Hi,
>>>
>>>I don't like using sockets in products. They add to cost, decrease
>>>reliability, tempt customers to "play" with the device(s) in those
>>>socket(s), etc.
>>
>>Very true.
>>
>>
>>>I'm now thinking about putting "consumer" flash memory devices in a
>>>design in lieu of equivalent components soldered onto the PCB. E.g.,
>>>mount an SD socket and use an SD *module* (or other media choices).
>>>
>>>The point is, this is done AS IF it was a permanently attached device.
>>>I.e., imagine fab'ing the board, slipping an SD card into the socket,
>>>and then encasing the entire assembly in a sealed box (so the SD card
>>>is socketed yet never removed).
>>
>>>Anyone with any experience in this regard?
>>
>>Once we did exactly that for an industrial device. Even if you secure
>>the card and socket with additional straps, the socket + card assy
>>remains one of the least reliable places. It is also prone to
>>manufacturing problems, such as loose soldering. So, in the next
>>revisions of the project we changed to the bare NAND flash soldered
>>directly on the board, and that was heck of a lot better.
>>
>
> Several years ago I was working on a product that looked like it was
> going to need a NAND. We didn't go down that path, but I looked into
> things long enough to know that there didn't seem to be any commercial
> solutions to using NAND in all it's glory, and worse there weren't even
> white papers (in English, at least) that detailed any manufacturer's
> recommendations on using the redundant bits for error checking and
> correction.
>
> Has that changed? Did you use the redundant bits for FEC or did you
> ignore them ore use them for other things? Did you roll your own
> solution, or did you find something off the shelf?

You can get some documentation and appnotes at Samung, Sandisk, Micron,
etc, however AFAIK you won't find the detailed NAND flash datasheets
without signing an NDA.

The NAND flash that I used had eMMC interface, so the very low level
stuff like ECC is been handled transparently and independently from the
host. The eMMC also solves compatibility problems between the ICs of the
different vendors.

The POSIX compliant filesystem over FLASH was developed at home. I
looked into so-called "free opensource" as well as into some paid
solutions; found them rather inconvenient and unsatisfactory.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
From: D Yuniskis on
Hi Vladimir,

Vladimir Vassilevsky wrote:
> D Yuniskis wrote:
>> I don't like using sockets in products. They add to
>> cost, decrease reliability, tempt customers to "play"
>> with the device(s) in those socket(s), etc.
>
> Very true.

Though there *are* times when this is necessary -- sometimes
even required! (products I've designed that ended up in
third world countries where "support" was little more than
mailing replacement parts -- or, smuggling them through
customs -- which could replace socketed components :< )

OTOH, when you get a board back from someone with bits of
*toothpick* wedged in/under a socketed PLCC you *really*
have to wonder if there are (un?)trained gorillas working
on repairing these things... :<

>> I'm now thinking about putting "consumer" flash memory
>> devices in a design in lieu of equivalent components
>> soldered onto the PCB. E.g., mount an SD socket and
>> use an SD *module* (or other media choices).
>>
>> The point is, this is done AS IF it was a permanently
>> attached device. I.e., imagine fab'ing the board,
>> slipping an SD card into the socket, and then encasing
>> the entire assembly in a sealed box (so the SD card is
>> socketed yet never removed).
>
>> Anyone with any experience in this regard?
>
> Once we did exactly that for an industrial device. Even if you secure

Which technology did you use? I.e., I would expect SD and SM
to have different issues as a consequence of their physical
characteristics.

How was the "media card" used by the application? I.e.,
*booting* off it but otherwise executing out of RAM places
infrequent demands on it. OTOH, using it in a datalogger
would place *continuous* demands on it.

Did you use any special selection criteria when picking the
socket? Or, just some run-of-the-mill part for consumer
devices?

> the card and socket with additional straps, the socket + card assy
> remains one of the least reliable places. It is also prone to

Yes. But, what sorts of failures did you encounter? Problems
because folks "played" with the parts (because they *looked*
like they were removable)? Failures of the connections over
time (oxidation, biological agents, etc.)? Intermittent
due to things like vibration? I.e., are there mitigating
factors that *could* be addressed to better your experience
in that case (a "no user serviceable parts inside" enclosure
to keep out prying hands; conformal coat for atmosphere-born
contaminants; mount on something that *doesn't* vibrate, etc.)

> manufacturing problems, such as loose soldering. So, in the next

"Loose soldering" because the component was fastened to the board
in a secondary operation? Or, because of mechanical stresses
placed on the socket by the (repeated?) insertion and removal
of the card?

> revisions of the project we changed to the bare NAND flash soldered
> directly on the board, and that was heck of a lot better.

That's what I would expect. Though I'm not sure how to put
a "figure" on "heck of a lot better". :< Removable media
offers some advantages (i.e., it can be replaced/upgraded
over time so you don't end up replacing the entire device)
From: D Yuniskis on
news(a)rblack01.plus.com wrote:
> In article <hj6dcs$3st$1(a)speranza.aioe.org>, not.going.to.be(a)seen.com
> says...
>>
>> I'm now thinking about putting "consumer" flash memory
>> devices in a design in lieu of equivalent components
>> soldered onto the PCB. E.g., mount an SD socket and
>> use an SD *module* (or other media choices).
>>
>> The point is, this is done AS IF it was a permanently
>> attached device. I.e., imagine fab'ing the board,
>> slipping an SD card into the socket, and then encasing
>> the entire assembly in a sealed box (so the SD card is
>> socketed yet never removed).
>>
>> But, I'm not sure that these types of sockets are
>> really intended for this type of long term use.
>> I.e., do they *expect* frequent insertions and removals
>> to wipe the contacts clean periodically?
>
> We have just done exactly this - micro-SD card in a socket on the board,
> to hold calibration data.

How often is the data updated or referenced? I.e., this isn't
XIP-able technology so it inherently needs to be cached...

> The card and socket contacts are both gold-plated, so I'm not expecting
> any problems. Other contact materials, I'd be a bit wary.

Agreed.

> Lots of embedded-PC-based systems (including ours) boot from a Compact
> Flash card. These usually have gold-plated contacts on both sides; our
> oldest machines have been in the field for about 5 years with no
> problems in this area.

Yes, but how often are they rebooted? And, how tenacious/finnicky is
the bootstrap loader?

What environment are you operating in? Relatively benign
(office, etc.) or more aggressive (industrial, outdoor, etc.)?
What sorts of environmental extremes do you see (shake 'n' bake)?
From: Mark Borgerson on
In article <hj6dcs$3st$1(a)speranza.aioe.org>, not.going.to.be(a)seen.com
says...
> Hi,
>
> I don't like using sockets in products. They add to
> cost, decrease reliability, tempt customers to "play"
> with the device(s) in those socket(s), etc. So, most
> of the things I work on simply can't tolerate them
> (either for reliability or "regulatory" requirements).
>
> But, the sockets I *have* used in the past have always
> been for *components* that would otherwise be soldered
> onto the PCB. And, were of high enough quality that
> I didn't fear the socket+device failing.
>
> I'm now thinking about putting "consumer" flash memory
> devices in a design in lieu of equivalent components
> soldered onto the PCB. E.g., mount an SD socket and
> use an SD *module* (or other media choices).
>
> The point is, this is done AS IF it was a permanently
> attached device. I.e., imagine fab'ing the board,
> slipping an SD card into the socket, and then encasing
> the entire assembly in a sealed box (so the SD card is
> socketed yet never removed).
>
> But, I'm not sure that these types of sockets are
> really intended for this type of long term use.
> I.e., do they *expect* frequent insertions and removals
> to wipe the contacts clean periodically?
>
> Anyone with any experience in this regard? And, any
> preferences to a particular technology that would be
> least likely to cause problems when used this way?
> (not sure what criteria would need to be maximized,
> there).
>
Many cell phones use micro SD cards for music and
picture storage. They often put the music on
through a USB connection. The pictures are often
taken and sent out via the phone. I've never
removed the 2GB sd micro in my phone, but it
still works fine after more than a year.

A lot of digital cameras use SD memory and have the
capability to upload the photos via high-speed
USB. The card may stay in the camera for many
months at a time.

I came to the conclusion a few years ago that SD
and SD micro sockets were OK for data storage,
and have incorporated them in a number of
data loggers. Before that, I had only used
CF cards for storage---but they had worked
out OK.

I'll add the disclaimer that I'm using the
SD and SD micro cards primarily in oceanographic
data loggers. The loggers are in sealed pressure
cases, so dust and humidity are not an issue.
(If anything gets wet, it's generally a catastrophic
failure!).


Mark Borgerson


From: steve_schefter on
On Jan 20, 12:59 pm, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote:
> The NAND flash that I used had eMMC interface,

I used a similar chip on a recent project. Just one word of caution:
MMC flash chips do not fit under Linux's MTD subsystem (for NAND and
NOR) that Lewin mentioned. That has implications for file system
support (no JFFS, for example).

Steve