Question about digital oscilloscopes flash memory endurance - Page 1
Forum section: electronics / testgear

author: alfredokiwi
author_rank: Contributor
timestamp: February 04, 2017, 04:33:19 pm
content: Hi folks,My name is Alfredo I`m newbie being this my first post, sorry about my poor english is not perfect. The question is related on today flash memory used on most digital oscilloscopes not only for the firmware storage also for the storage of user configurations and last settings. I have the OWON MSO7102TD and SDS5052V that use flash devices for the storage of last used configuration (vertical gain, time base, etc). And here starts the problem because flash devices have a limited endurance on write cycles. Flash memory manufacturers recommends to shift the data to a new sector after reaching a limit (normally 100.000 write cycles) to avoid write errors but unfortunately this is not implemented on most firmware's not only on digital oscilloscopes also on electronics appliances, LCD, TVs, etc.I know there are two types of flash memory devices, NOR and NAND. The big question is if something goes wrong on the flash device leading to malfunctioning. On worst cases the system hangs caused by a run time error due corrupted data on the flash device.The question is if today digital oscilloscopes are well designed on the firmware shifting the data to a new sector avoiding in this way issues on the internal flash memory.

author: PA0PBZ
author_rank: Super Contributor
timestamp: February 04, 2017, 04:44:09 pm
content: 100.000 write cycles means that you are good for 273 years when you write once a day, that would hardly be a problem. The question of course is, when is the data written, only when you power off the scope or each time you change the setting?

author: rstofer
author_rank: Super Contributor
timestamp: February 04, 2017, 04:51:01 pm
content: According to your data, the scope would cease to work after about 274 years when shut down once per day. Maybe we should assume the scope is shut down 4 times per day of use but only used on half the days. This would be about 137 years.The 100,000 write cycles is not considered an issue. There are situations where the write cycle limitation can be a problem but saving settings isn't one of them.If it were a problem, the Internet would be flaming!

author: alfredokiwi
author_rank: Contributor
timestamp: February 04, 2017, 05:02:27 pm
content: Quote from: PA0PBZ on February 04, 2017, 04:44:09 pmThis is another question because with a moderate used is very easy to reach the limit of secure write cycles on some scopes, why?. I don`t think that a flash write when powering off is implemented on OWON oscilloscopes because the power button is a current switch that shut off abruptly the 110/220V mains meaning that every time you change an encoder or press a button flash data is written. But another problem is the silicon quality of the flash memory device for example low quality cheap SD cards have a lot of issues. NOR and NAND flash chips are soldered not easy removable being another problem.

author: testmode
author_rank: Regular Contributor
timestamp: February 04, 2017, 05:08:38 pm
content: I doubt you'll get a common concensus/answer to your question. Each manufacturer have different approaches to FW development and in reality, manufacturer's recommendations are really just recommendations and developers may or may not follow them exactly especially if it is something that will not have adirect/apparenteffect on the operation of the application. And if development is done properly, there are many ways to circumvent reaching the write/erase limits throughout the lifetime of the product, one common and easy way of which is buffering or intermittent flushing, which significantly reduces the write/erase cycles. Though, there is no way to tell this from the end-product itself nor stated in the datasheets.On the bright side, for this type of application (i.e. storage of FW and/or user config), running thru the write/erase spec should be the least of your worries for the flash memory. And unless you're using parts from the bleeding edge of flash process/technology or the really really cheap ones with not much quality testing at all, semiconductor manufacturing is now at a pretty mature point that products are usually reliable and failures are in the low ppm range. And besides, it's not like you're going to change settings a thousand times and do it every single day, right?P.S. I test flash memory for a living - NOR flash memories to be exact, the kind that gets embedded into microcontrollers and custom ASICs.And one more thing - welcome to the EEVBlog forum!

author: smithnerd
author_rank: Regular Contributor
timestamp: February 04, 2017, 05:28:31 pm
content: Can't comment on OWON's approach, but from poking around in the Rigol DS1KZ firmware, I know they do some kind of wear-levelling on the internal flash device. It's a feature of the filesystem they chose:https://sourceforge.net/projects/uffs/

author: rstofer
author_rank: Super Contributor
timestamp: February 04, 2017, 06:02:26 pm
content: Quote from: alfredokiwi on February 04, 2017, 05:02:27 pmHave you ever heard of a single piece of test equipment failing because of FLASH problems? Ever? Or, for that matter, any piece of equipment of any kind? The Internet would be in flames over a single confirmed problem, especially if it was Rigol. Nobody would buy a manufacturer's products if it was ever confirmed to be an issue.Or, take the other side: What can you do about it? If you can't solve it, why worry about it? You certainly won't convince the manufacturers to change technologies or coding.You could also take the approach of not taking a chance. Don't buy equipment that stores settings in FLASH. If you have any doubt about a manufacturer, buy from somebody else.

author: alfredokiwi
author_rank: Contributor
timestamp: February 04, 2017, 06:04:14 pm
content: Quote from: smithnerd on February 04, 2017, 05:28:31 pmIn the case of SSD hard drives on PCs the built in SSD hardware controller and OS stack Windows / Linux do the magic job shifting the data to a new sector. Supposedly there is an unused not declared SSD flash spare space for that being the user unnoticed about sector issues. Such implementation is a smart way to hide the real issues on flash devices. The Rigol DS1000K series are very new so we need to discard that today technology is mature and well developed. If developers may or may not follow the data shift recommendations because will not have a direct/apparent effect on the operation of the application means that there is no guarantee on product durability. A different scenario would be if the flash device is removable in the same way as SD cards or SSD drives giving the possibility to extend the life cycle of the product. An expensive oscilloscope is not a cheap 10 dollar MP3 player but unfortunately both devices use the same latest flash technology for example Samsung flash chips.

author: JPortici
author_rank: Super Contributor
timestamp: February 04, 2017, 06:23:11 pm
content: wear levelling can be done in software if you feel you have the need (there is a nice microchip application note and codebase about that if you want)or you could use other ways to implement nonvolatile storage.. nvram, battery backup, supercap backup, and flash onlly when truly needed

author: Fgrir
author_rank: Regular Contributor
timestamp: February 04, 2017, 08:24:00 pm
content: Quote from: rstofer on February 04, 2017, 06:02:26 pmKeysight seems to be surviving...https://www.eevblog.com/forum/testgear/agilent-dsox2024-won't-boot/msg947382/#msg947382