Flash memory dies and the data logging DMM with it ???  - Page 1
Forum section: electronics / projects

author: Kiriakos-GR
author_rank: Super Contributor
timestamp: August 04, 2011, 01:20:28 am
content: I am trying to calm down by reading this piss poor review saying that ... No no read it all ..http://www.amazon.com/Agilent-U1272A-Handheld-Counts-True/dp/B004URG9EU/ref=cm_cr_pr_product_topAnd reply with your comments about the Flash memory comment.I am a piss poor electrician, I am expecting comments from serious EE to solve the puzzle.

author: ejeffrey
author_rank: Super Contributor
timestamp: August 04, 2011, 10:07:01 am
content: That sounds like a made-up complaint to me. First off, even the reviewer doesn't claim that memory memory failure prevents the meter from operating as a meter. To do so would require someone to observe memory failure. Second, the memory is not even necessarily flash. It could be battery backed SRAM with a lithium coin cell or even a capacitor to keep power while changing the battery, or it could be an EEPROM.SRAM lasts forever. Industrial flash and EEPROMS both have limited write number of write cycles, but it is over 1e6, and often much more. I can't really see how you would ever reach that limit even under extraordinary use -- To reach that in 20 years you have to be filling up the log every 10 minutes. 24/7. That isn't really practical with a battery powered hand-held meter.These concerns apply to any logging DMM with the NV ram. Unless there is some specific design flaw in the agilent (there could be, but this appears to be only speculation on the part of that reviewer) there is no problem here at all.

author: Unknown
author_rank: Unknown
timestamp: August 04, 2011, 02:54:46 pm
content: Kyriako, "Tzetzeris rolled about and found the cap".I guess you found your Nemesis.Anyway, Flash memory has a limited write endurance in the 100k cycles ballpark depending on subtechnology. In the functionality within a logging DMM other components will fail first. If it was used as say a scratchpad memory for firmware execution the it would fail within hours. But it is not; it is used for storage.

author: Kiriakos-GR
author_rank: Super Contributor
timestamp: August 04, 2011, 03:35:44 pm
content: Quote from: Alex on August 04, 2011, 02:54:46 pmThe truth is that something had hit me, and I believe that it was the "Tzetzeris " ( large cooking pot)Speaking about memory, every DMM with the Min-Max function it does a heavy use of reading and writing in the interval of 250mS,due the collection of all those samples, and there is no any written limitation about for how many hours you will have the Min-Max active.When you use PEAK ( or Min-Max-PEAK by the Fluke book), the samples is taken at 1mS = a more faster rate = more heavy workload.According some tests of my, when such modes become active the DMM consumes the batteries more aggressively than in any other function.Even today not even one DMM died as far I know from a such a reason.Not to say that with the current technology we have advanced memory modules with amazing capabilities.We have end up to have today, even Solid state disks.And speaking about the data logging memory that probably is the storage, the writing rate of 1 recording per second,how in earth it can effect the lifespan ?Quote from: Alex on August 04, 2011, 02:54:46 pm100k = 100.000 cycles.If I do 100.000 data logging sessions and charge 1$ per its one, I will gain 100.000$ before my HH dies.In this case I do not care..

author: Unknown
author_rank: Unknown
timestamp: August 04, 2011, 04:01:11 pm
content: For min/max averaging, peak and other similar functions I would expect a memory closer to the MCU being used, possibly part of the SRAM on board the MCU.The endurance figure is the mean lifetimefor each memory cell (or block). You would have to write a cell (or block) 100k times to kill it. But since this is the mean of a standard deviation, you can get cells (or blocks) that die sooner and other die-hard cells.Techniques such as dynamic mapping of the data on cells with fewer read/write cycles and of course error correction can also be used.Have a look at the capacity of your pen drive, note it down. Use it for a year and check it again. You will notice that it is less.QuoteTo do 100k sessions you would needa lotof batteries. You will also need to eat, pay rent and bills, possibly petrol to get to the place where you will do the data logging. All of this cost money, so unless you start charging much more per session you will have a loss."This is not a business for me -I'm out!"Now...if you ask for a new DMM for each session then you will probably make a profit!

author: ejeffrey
author_rank: Super Contributor
timestamp: August 04, 2011, 04:04:47 pm
content: min/max and peak hold use normal RAM to hold the results. This has no write cycle limit. Flash /EEPROM is only used for data logging, and maybe storing some configuration settings that need to be preserved when the power is off. These uses will not exceed their wear limits under any normal or even abnormal usage.

author: Kiriakos-GR
author_rank: Super Contributor
timestamp: August 04, 2011, 09:20:23 pm
content: Thanks for the information people, I do appreciate it.I believe that all those PDA GPS , they use identical technology too as storage.My HP iPAQ rx5915 Travel Companion, an 500$ worth GPS PDA ( or was worth) uses 2GB internal Flash /EEPROM.The specific model was made for the American market so to have enough storage for the local maps.I deleted those files, and gained the free space as storage for other files.And the bottom line is that if all those PDA GPS devices can make it, about handling the usage of reading maps / MP3 / movies etc etc.The hand held DMM haves nothing to fear.Not even my ancient Smart media cards of my Olympus digital Camera had not even fail on my hands ( I am gentle to them ),that is a 12 years old or more technology.And by mainly using my first Smart media card 128MB since 2001 until today , I had take 10.000 pictures or more.

author: patb
author_rank: Regular Contributor
timestamp: August 04, 2011, 10:23:32 pm
content: Quote from: Alex on August 04, 2011, 04:01:11 pmAlex, could you elaborate regarding this behavior. I use pen drives regularly and never seen "auto-magically" reduced capacity.

author: Kiriakos-GR
author_rank: Super Contributor
timestamp: August 04, 2011, 11:06:53 pm
content: I think that he is referring about automatic mapping of bad blocks.I have see the USB controller of a pen drive to short and kill the USB port of my MB.But never see any bad blocks, I do not use pen drives that much.

author: patb
author_rank: Regular Contributor
timestamp: August 05, 2011, 07:32:23 am
content: Quote from: Kiriakos-GR on August 04, 2011, 11:06:53 pmI don't see any way that this could work automatically. Sure, you can get bad sectors on any drive (including flash drives), but you would notice it by getting read or write error(s). It is the file-system driver that reports capacity and free space of a drive (for end user), not the USB drive itself. And the FS driver works on higher level than the drive. AFAIK there is no way the drive can tell FS - hey, let's reduce the size of me, because I think some of my cells are damaged. It can only go the opposite way - FS asks drive for physical data and drive may respond - oups, something is wrong - mark that sector as "bad". So I think that the only way to reduce the usable capacity of a drive is by getting bad sectors (or of course writing files). It is also possible and common that various applications create hidden files or even directories on a drive - then it appears to the end user as a reduced free space. After you format that drive you should get the original capacity minus bad sectors. I am 99% sure that it works that way.

author: ejeffrey
author_rank: Super Contributor
timestamp: August 05, 2011, 08:16:01 am
content: All of the wear leveling and bad sector remapping that goes on in flash drives is behind the scenes, handled by the flash controller. The drive has a bit of extra capacity (in the 20% range, depends on the drive) above and beyond the capacity reported to the host computer. Every time you write to a block, the flash controller has the option to remap that to a new physical location on the drive, and move the original block to the spares list. This spreads out the wear so that if you write the same file over, you actually write to many physical locations only a few times each. When a given block starts to wear out, the flash controller will stop using it altogether. When the number of spare blocks drops below a certain level, the drive becomes essentially useless.In any case, the reported total size should not change over the life of the drive. In principle it is possible, and some solid-state drives may allow you to reformat and get a new slightly reduced capacity, but this doesn't happen under normal use, never happens to USB flash drives that I know of, and isn't really standard.Most flash failures occur during writes. The amount of time needed to erase and write a block increases with the number of times it has been erased. When the write time gets to a given threshold, the controller decides that the block is dead. You should never see IO errors from this type of failure, as the drive should automatically redirect the 'write' request to a new block with no loss of data. It is possible to have failures triggered by reads (block was written OK, read OK once, fails the second time) or by writes to an adjacent block. In these cases you will get an IO error as there is data loss. The OS may mark that block as bad, and stop using it, although that is not really helpful or necessary: writing data to that block will cause the firmware to remap it to a new physical location and mark the damaged block as defective.The important thing to keep in mind is that the virtual block address seen by the host computer is not really related to the physical block address at all.All of this only applies to large NAND flash drives like SD/compact flash, USB pen drives, and SATA solid state drives that are designed to hold a general purpose filesystem. Small embedded chunks of flash typically do not work like this at all. They are generally designed either to be occasionally written serially all at once, like the program memory in a microcontroller or the separate boot firmware on a PC or embedded device, or used in a log fasion where they are written a few bytes at a time in a circular fashion (this would be my guess for how the logging meters work). In some cases, they will use a special filesystem called a logging filesystem that is specifically designed for flash drives and writes in a logging format (beginning to end) while providing a more standard filesystem interface, usually at a considerable speed penalty (which is OK as these devices are usually very small: a few MB at most). In any case, these embedded devices typically do not have to provide a full filesystem compatibility, and naturally spread the wear over the whole drive, so the flash controllers don't have to do this.

author: patb
author_rank: Regular Contributor
timestamp: August 05, 2011, 08:47:03 am
content: ejeffrey, your explanation is extactly how I see it.I only wonder if simple flash cards (SD, CF etc) have all those reserved sectors for spare blocks. For SSDs this is out of the question, because they contain advanced flash controllers esp. designed to handle file systems. But is it also the case with flash cards and cheap pen drives? I really don't know.Anyway, designing effective SSD controller must be a really challenging task. And interesting. For example - a question: where do SSD controllers store mappings of blocks to logical sectors? Is it on the same flash chips where the data is stored or maybe in some other memory (built-in maybe?). This is really interesting stuff where hardware meets software.

author: Wartex
author_rank: Frequent Contributor
timestamp: August 06, 2011, 07:26:15 am
content: Quote from: patb on August 05, 2011, 08:47:03 amI have a Panasonic SDHC class 10 that does wear leveling. Most of them don't.