[Gene] has a project that writes a lot of settings to a PIC microcontroller’s Flash memory. Flash has limited read/erase cycles, and although the obvious problem can be mitigated with error correction codes, it’s a good idea to figure out how Flash fails before picking a certain ECC. This now became a problem of banging on PICs until they puked, and mapping out the failure pattern of the Flash memory in these chips.
The chip on the chopping block for this experiment was a PIC32MX150, with 128K of NOR Flash and 3K of extra Flash for a bootloader. There’s hardware support for erasing all the Flash, erasing one page, programming one row, and programming one word. Because [Gene] expected one bit to work after it had failed and vice versa, the testing protocol used RAM buffers to compare the last state and new state for each bit tested in the Flash. 2K of RAM was tested at a time, with a total of 16K of Flash testable. The code basically cycles through a loop that erases all the pages (should set all bits to ‘1’), read the pages to check if all bits were ‘1’, writes ‘0’ to all pages, and reads pages to check if all bits were ‘0’. The output of the test was a 4.6 GB text file that looked something like this:
Continue reading “Flash Memory Endurance Testing”
NAND flash, the same memory chips found in everything from USB thumb drives to very expensive solid state disk drives, are increasingly common. As they (partially) serve as the storage for cellphones, Wiis, routers and just about every piece of consumer electronic devices, you’re probably surrounded by dozens of NAND chips at any one time.
[Sprite_tm], hacker extraordinaire, put up a build a few years ago where he was able to read the contents of NAND Flash chips using a PC parallel port. It’s getting rather hard to find a parallel port on a PC anymore, so he updated his build to read Flash chips off of a USB port.
There are two main components of [Sprite_tm]’s build. First, to read the Flash chip, he needed a way to break out the pins on the very tiny TSOP48 package. [Sprite] found a neat little socket for these chips on eBay for about 10 Euros.
Communicating with the Flash chip via USB was a little harder. [Sprite] knew he needed USB 2.0, but not many microcontrollers have that implemented. Luckily, the FTDI FT2232H has USB 2.0, along with the very nice feature of being able to read data and address pins directly from the Flash chip. After a bit of soldering, [Sprite_tm] was left with the device seen above.
[Sprite_tm] found a nice library to bitbang the pins on the FTDI chip and request one page of memory from the Flash chip at a time. The device works as advertised, but it’s still a bit slow at 250 kBps. [Sprite] figures he can increase the speed of reading a Flash chip by requesting multiple pages at a time, but it’s still orders of magnitude faster than the old parallel port solution.
There’s a good bit of software [Sprite] posted to help him (and possibly others) read bare NAND flash chips via USB. This means if you have a broken USB Flash drive or SD card, it’s possible to desolder the chip and read it with your own controller. Interpreting the blocks of data recovered from a Flash drive as a file system is another story, but it’s still a fairly remarkable build.
Here’s a nice little discussion about reading and writing AVR flash memory that [Windel] put together. He’s using an In System Programmer to read the flash memory from an ATmega328 using AVRdude, the programming software which we used in our AVR Programming Tutorials. He covers the particulars of the commands, how this might be useful, and finishes up with the gotcha’s involved in reading back code from the chip. We recently tried this out with that LED light bulb but were unsuccessful because the lock bits on the ATtiny13 chip had been set in order to protect the firmware from our prying eyes. Hopefully you’ll have more luck with these methods.