Reverse-engineering and analysis of SanDisk High Endurance microSDXC card

Posted on July 16, 2020 by ginbot86

As seen on Hackaday!

TL;DR – The SanDisk High Endurance cards use SanDisk/Toshiba 3D TLC Flash. It took way, way more work than it should have to figure this out (thanks for nothing, SanDisk!).
In contrast, the SanDisk MAX Endurance uses the same 3D TLC in pMLC (pseudo-multi-level cell) mode.

In a previous blog post, I took a look at SanDisk’s microSD cards that were aimed for use in write-intensive applications like dash cameras. In that post I took a look at its performance metrics, and speculated about what sort of NAND Flash memory is used inside. SanDisk doesn’t publish any detailed specifications about the cards’ internal workings, so that means I have no choice but to reverse-engineer the ~~can of worms~~ card myself.

The Help Desk That Couldn’t

In the hopes of uncovering more information, I sent an email to SanDisk’s support team asking about what type of NAND Flash they are using in their High Endurance lineup of cards, alongside endurance metrics like P/E (Program/Erase) cycle counts and total terabytes written (TBW). Unfortunately, the SanDisk support rep couldn’t provide a satisfactory answer to my questions, as they’re not able to provide any information that’s not listed in their public spec sheets. They said that all of their cards use MLC Flash, which I guess is correct if you call TLC Flash 3-bit MLC (which Samsung does).

Dear Jason,

Thank you for contacting SanDisk® Global customer care. We really appreciate you being a part of our SanDisk® family.

I understand that you wish to know more about the SanDisk® High Endurance video monitoring card, as such please allow me to inform you that all our SanDisk® memory cards uses Multi level cell technology (MLC) flash. However, the read/write cycles for the flash memory is not published nor documented only the read and write speed in published as such they are 100 MB/S & 40 MB/s. The 64 GB card can record Full HD video up to 10,000 hours. To know more about the card you may refer to the link below:

SANDISK HIGH ENDURANCE VIDEO MONITORING microSD CARD

Best regards,
Allan B.
SanDisk® Global Customer Care

I’ll give them a silver star that says “You Tried” at least.

Anatomy of an SD Card

While (micro)SD cards feel like a solid monolithic piece of technology, they’re made up of multiple different chips, each performing a different role. A basic SD card will have a controller that manages the NAND Flash chips and communicates with the host (PC, camera, etc.), and the NAND Flash itself (made up of 1 or more Flash dies). Bunnie Huang’s blog, Bunnie Studios, has an excellent article on the internals of SD cards, including counterfeits and how they’re made – check it out here.

Block diagram of a typical SD card.

MicroSD cards often (but not always!) include test pads, used to program/test the NAND Flash during manufacture. These can be exploited in the case of data recovery, or to reuse microSD cards that have a defective controller or firmware by turning the card into a piece of raw NAND Flash – check out Gough Lui’s adventures here. Note that there is no set standard for these test pads (even for the same manufacturer!), but there are common patterns for some manufacturers like SanDisk that make reverse-engineering easier.

Crouching Controller, Hidden Test Pads

microSD cards fall into a category of “monolithic” Flash devices, as they combine a controller and raw NAND Flash memory into a single, inseparable package. Many manufacturers break out the Flash’s data bus onto hidden (and nearly completely undocumented) test pads, which some other memory card and USB drive manufacturers take advantage of to make cheap storage products using failed parts; the controller can simply be electrically disabled and the Flash is then used as if it were a regular chip.

In the case of SanDisk cards, there is very limited information on their cards’ test pad pinouts. Each generation has slight differences, but the layout is mostly the same. ~~These differences can be fatal, as the power and ground connections are sometimes reversed (this spells instant death for a chip if its power polarity is mixed up!).~~

CORRECTION (July 22, 2020): Upon further review, I might have accidentally created a discrepancy between the leaked pinouts online, versus my own documentation in terms of power polarity; see the “Test Pad Pinout” section.

My card (and many of their higher-end cards – that is, not their Ultra lineup) features test pads that aren’t covered by solder mask, but are instead covered by some sort of screen-printed epoxy with a laser-etched serial number on top. With a bit of heat and some scraping, I was able to remove the (very brittle) coating on top of the test pads; this also removed the serial number which I believe is an anti-tamper measure by SanDisk.

: Epoxy coating over test pads

: Test pads exposed

After cleaning off any last traces of the epoxy coating, I was greeted with the familiar SanDisk test pad layout, plus a few extra on the bottom.

Building the Breakout Board

The breakout board is relatively simple in concept: for each test pad, bring out a wire that goes to a bigger test point for easier access, and wire up the normal SD bus to an SD connector to let the controller do its work with twiddling the NAND Flash bus. Given how small each test pad is (and how many), things get a bit… messy.

: Breakout board assembled.

: Closeup of card breakout.

I started by using double-side foam adhesive tape to secure the SD card to a piece of perfboard. I then tinned all of the pads and soldered a small 1uF ceramic capacitor across the card’s power (Vcc) and ground (GND) test pads. Using 40-gauge (0.1 mm, or 4-thousandths of an inch!) magnet wire, I mapped each test pad to its corresponding machine-pin socket on the perfboard. Including the extra test pads, that’s a total of 28 tiny wires!

For the SD connector side of things, I used a flex cable for the XTC 2 Clip (a tool used to service HTC Android devices), as it acted as a flexible “remote SD card” and broke out the signals to a small ribbon cable. I encased the flex cable with copper tape to act as a shield against electrical noise and to provide physical reinforcement, and soldered the tape to the outer pads on the perfboard for reinforcement. The ribbon cable end was then tinned and each SD card’s pin was wired up with magnet wire. The power lines were then broken out to an LED and resistor to indicate when the card was receiving power.

Bus Analysis

With all of the test pads broken out to an array of test pins, it was time to make sense of what pins are responsible for accessing the NAND Flash inside the card.

Test Pad Pinout

Diagram of the test pads on SanDisk’s High Endurance microSD card. (click to enlarge)

The overall test pad pinout was the same for other microSD cards from SanDisk, but there were some differences, primarily regarding the layout of the power pads; notably, the main power pins are backwards! This can destroy the card if you’re not careful when applying power.

CORRECTION (July 22, 2020): I might actually have just gotten my own documentation mixed up in terms of the power and ground test pads. Regardless, one should always be careful to ensure the correct power polarity is sent to a device.

I used my DSLogic Plus logic analyzer to analyze the signals on all of the pins. Since the data pinout was previously discovered, the hard part of figuring out what each line represented (data bus, control, address, command, write-protect, ready/busy status) was already done for me. However, not all of the lines were immediately evident as the pinouts I found online only included the bare minimum of lines to make the NAND Flash accessible, with one exception being a control line that places the controller into a reset state and releases its control of the data lines (this will be important later on).

By sniffing the data bus at the DSLogic’s maximum speed (and using its 32 MB onboard buffer RAM), I was able to get a clear snapshot of the commands being sent to the NAND Flash from the controller during initialization.

Bus Sniffing & NAND I/O 101 (writing commands, address, reading data)

In particular, I was looking for two commands: RESET (0xFF), and READ ID (0x90). When looking for a command sequence, it’s important to know how and when the data and control lines change. I will try to explain it step-by-step, but if you’re interested there is an introductory white paper by Micron that explains all of the fundamentals of NAND Flash with much more information about how NAND Flash works.

: Logic analyzer trace of RESET command. Dotted line indicates where the write and reset occurs.

: Logic analyzer trace of READ ID command. Dotted lines indicate where read/writes occur.

When a RESET command is sent to the NAND Flash, first the /CE (Chip Select, Active Low) line is pulled low. Then the CLE (Command Latch Enable) line is pulled high; the data bus is set to its intended value of 0xFF (all binary ones); then the /WE (Write Enable, Active Low) line is pulsed from high to low, then back to high again (the data bus’ contents are committed to the chip when the /WE line goes from low to high, known as a “rising edge”); the CLE line is pulled back low to return to its normal state. The Flash chip will then pull its R/B (Ready/Busy Status) line low to indicate it is busy resetting itself, then releases the line back to its high state when it’s finished.

The READ ID command works similarly, except after writing the command with 0x90 (binary 1001 0000) on the data bus, it then pulls the ALE (Address Latch Enable) line high instead of CLE, and writes 0x00 (all binary zeroes) by pulsing the /WE line low. The chip transfers its internally programmed NAND Flash ID into its internal read register, and the data is read out from the device on each rising edge of the /RE (Read Enable, Active Low) line; for most devices this is 4 to 8 bytes of data.

NAND Flash ID

For each NAND Flash device, it has a (mostly) unique ID that identifies the manufacturer, and other functional data that is defined by that manufacturer; in other words, only the manufacturer ID, assigned by the JEDEC Technology Association, is well-defined.

The first byte represents the Flash manufacturer, and the rest (2 to 6 bytes) define the device’s characteristics, as set out by the manufacturer themselves. Most NAND vendors are very tight-lipped when it comes to datasheets, and SanDisk (and by extension, Toshiba/Kioxia) maintain very strict control, save for some slightly outdated leaked Toshiba datasheets. Because the two aforementioned companies share their NAND fabrication facilities, we can reasonably presume the data structures in the vendor-defined bytes can be referenced against each other.

In the case of the SanDisk High Endurance 128GB card, it has a NAND Flash ID of 0x45 48 9A B3 7E 72 0D 0E. Some of these values can be compared against a Toshiba datasheet:

Byte Value (Hex)	Description/Interpretation
45	Manufacturer: SanDisk
48	I/O voltage: Presumed 1.8 volts (measured with multimeter) Device capacity: Presumed 128 GB (unable to confirm against datasheet)
9A	NAND type: TLC (Triple-Level Cell / 3 bits per cell) Flash dies per /CE: 4 (card uses four 32GB Flash chips internally)
B3	Block size: 12 MiB (768 pages per block) excluding spare area (determined outside datasheet) Page size: 16,384 bytes / 16 kiB excluding spare area
7E	Planes per /CE: 8 (2 planes per die)
72	Interface type: Asynchronous Process geometry: BiCS3 3D NAND (determined outside datasheet)
0D	Unknown (no information listed in datasheet)
0E	Unknown (no information listed in datasheet)

Although not all byte values could be conclusively determined, I was able to determine that the SanDisk High Endurance cards use BiCS3 3D TLC NAND Flash, but at least it is 3D NAND which improves endurance dramatically compared to traditional/planar NAND. Unfortunately, from this information alone, I cannot determine whether the card’s controller takes advantage of any SLC caching mechanisms for write operations.

The chip’s process geometry was determined by looking up the first four bytes of the Flash ID, and cross-referencing it to a line from a configuration file in Silicon Motion’s mass production tools for their SM3271 USB Flash drive controller, and their SM2258XT DRAM-less SSD controller. These tools revealed supposed part numbers of SDTNAIAMA-256G and SDUNBIEMM-32G respectively, but I don’t think this is accurate for the specific Flash configuration in this card.

External Control

I wanted to make sure that I was getting the correct ID from the NAND Flash, so I rigged up a Texas Instruments MSP430FR2433 development board and wrote some (very) rudimentary code to send the required RESET and READ ID commands, and attempt to extract any extra data from the chip’s hidden JEDEC Parameter Page along the way.

My first roadblock was that the MSP430 would reset every time it attempted to send the RESET command, suggesting that too much current was being drawn from the MSP430 board’s limited power supply. This can occur during bus contention, where two devices “fight” each other when trying to set a certain digital line both high and low at the same time. I was unsure what was going on, since publicly-available information didn’t mention how to disable the card’s built-in controller (doing so would cause it to tri-state the lines, effectively “letting go” of the NAND bus and allowing another device to take control).

I figured out that the A1 test pad (see diagram) was the controller’s reset line (pulsing this line low while the card was running forced my card reader to power-cycle it), and by holding the line low, the controller would release its control of the NAND Flash bus entirely. After this, my microcontroller code was able to read the Flash ID correctly and consistently.

Reading out the card’s Flash ID with my own microcontroller code.

JEDEC Parameter Page… or at least what SanDisk made of it!

The JEDEC Parameter Page, if present, contains detailed information on a Flash chip’s characteristics with far greater detail than the NAND Flash ID – and it’s well-standardized so parsing it would be far easier. However, it turns out that SanDisk decided to ignore the standard format, and decided to use their own proprietary Parameter Page format! Normally the page starts with the ASCII string “JEDEC”, but I got a repeating string of “SNDK” (corresponding with their stock symbol) with other data that didn’t correspond to anything like the JEDEC specification! Oh well, it was worth a try.

I collected the data with the same Arduino sketch as shown above, and pulled 1,536 bytes’ worth of data; I wrote a quick program on Ideone to provide a nicely-formatted hex dump of the first 512 bytes of the Parameter Page data:

Offset 00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F 0123456789ABCDEF
------ --+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- ----------------
0x0000 53 4E 44 4B 53 4E 44 4B 53 4E 44 4B 53 4E 44 4B SNDKSNDKSNDKSNDK
0x0010 53 4E 44 4B 53 4E 44 4B 53 4E 44 4B 53 4E 44 4B SNDKSNDKSNDKSNDK
0x0020 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 ..... ...H.....A
0x0030 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 Hcj..... ...H...
0x0040 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 ..AHcj..... ...H
0x0050 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 .....AHcj..... .
0x0060 02 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 ..H.....AHcj....
0x0070 06 20 00 02 01 48 9A B3 00 05 08 41 48 63 6A 08 . ...H.....AHcj.
0x0080 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 48 .... ...H.....AH
0x0090 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 cj..... ...H....
0x00A0 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A .AHcj..... ...H.
0x00B0 B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 ....AHcj..... ..
0x00C0 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 .H.....AHcj.....
0x00D0 20 00 02 01 48 9A B3 00 05 08 41 48 63 6A 08 08  ...H.....AHcj..
0x00E0 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 48 63 ... ...H.....AHc
0x00F0 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 j..... ...H.....
0x0100 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 AHcj..... ...H..
0x0110 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 ...AHcj..... ...
0x0120 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 H.....AHcj..... 
0x0130 00 02 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 ...H.....AHcj...
0x0140 08 06 20 00 02 01 48 9A B3 00 05 08 41 48 63 6A .. ...H.....AHcj
0x0150 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 ..... ...H.....A
0x0160 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 Hcj..... ...H...
0x0170 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 ..AHcj..... ...H
0x0180 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 .....AHcj..... .
0x0190 02 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 ..H.....AHcj....
0x01A0 06 20 00 02 01 48 9A B3 00 05 08 41 48 63 6A 08 . ...H.....AHcj.
0x01B0 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 48 .... ...H.....AH
0x01C0 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 cj..... ...H....
0x01D0 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A .AHcj..... ...H.
0x01E0 B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 ....AHcj..... ..
0x01F0 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 .H.....AHcj.....

Further analysis with my DSLogic showed that the controller itself requests a total of 4,128 bytes (4 kiB + 32 bytes) of Parameter Page data, which is filled with the same repeating data as shown above.

Reset Quirks

When looking at the logic analyzer data, I noticed that the controller sends the READ ID command twice, but the first time it does so without resetting the Flash (which should normally be done as soon as the chip is powered up!). The data that the Flash returned was… strange to say the least.

Byte Value (Hex)	Interpreted Value
98	Manufacturer: Toshiba
00	I/O voltage: Unknown (no data) Device capacity: Unknown (no data)
90	NAND type: SLC (Single-Level Cell / 1 bit per cell) Flash dies per /CE: 1
93	Block size: 4 MB excluding spare area Page size: 16,384 bytes / 16 kiB excluding spare area
76	Planes per /CE: 2
72	Interface type: Asynchronous Process geometry: 70 nm planar

This confused me initially when I was trying to find the ID from the logic capture alone; after talking to a contact who has experience in NAND Flash data recovery, they said this is expected for SanDisk devices, which make liberal use of vendor-proprietary commands and data structures. If the fourth byte is to be believed, it says the block size is 4 megabytes, which I think is plausible for a modern Flash device. The rest of the information doesn’t really make any sense to me apart from the first byte indicating the chip is made by Toshiba.

Conclusion

I shouldn’t have to go this far in hardware reverse-engineering to just ask a simple question of what Flash SanDisk used in their high-endurance card. You’d think they would be proud to say they use 3D NAND for higher endurance and reliability, but I guess not!

Downloads

For those that are interested, I’ve included the logic captures of the card’s activity shortly after power-up. I’ve also included the (very crude) Arduino sketch that I used to read the NAND ID and Parameter Page data manually:

Recovering the SIM card PIN from the ZTE WF721 cellular home phone

Posted on December 21, 2019 by ginbot86

As seen on Hackaday!

TL;DR – If you have a ZTE WF721 that’s PIN-locked your SIM card, try 2376.

Recently I picked up a used Samsung Galaxy Core LTE smartphone from a relative after they upgraded to an iPhone. As the Core LTE is a low-end smartphone, I suspected that the phone was SIM locked to its original carrier (Virgin Mobile), but in order to test this I needed a different SIM card. My personal phone was on the same carrier, so I wasn’t able to use that to test it.

However, the previous summer I picked up a ZTE WF721 cellular home phone base station (that is, it’s a voice-only cell phone that a landline phone plugs into), which came with a Telus SIM card. The issue is that the WF721 sets a SIM card PIN to essentially “lock” the card to the base station, and it wasn’t the default 1234 PIN; brute-forcing a SIM card is not possible as you get 3-5 attempts before the card needs to be unblocked using a PUK (PIN Unblock Key), failing that, the card is permanently rendered unusable. I decided to take the base station apart, and use my knowledge in electronics and previous research into smart cards to see if I could recover the PIN.

(Yes, I went through all this work instead of just buying a prepaid SIM card from the dollar store. I’m weird like that.)

Test Pads & Signals

After a bit of disassembly work involving removing screws hidden under rubber non-slip feet and a lot of spudgering open plastic clips, I got access to the four test pads that connect to the SIM card, accessible on the opposite side of the PCB from the SIM card socket.

The ZTE WF721 opened, with test pads broken out and connected to DSLogic for reverse engineering.

An ISO 7816-compliant smart card (and a SIM card is one) require 5 different lines to work: Vcc (power), ground, clock, I/O (data), and reset. The I/O is an asynchronous half-duplex UART-type interface, whose baud rate is determined by the card’s characteristics and the clock frequency that it is given by the reader (in this case, the WF721). The details of how the interface work can be obtained for free in their TS 102 221 specification from the ETSI (European Telecommunications Standards Institute).

The test pads that connect to the WF721’s SIM card socket.

I then soldered the ground wire to a free test pad elsewhere on the board, whereas the four other wires were soldered to the test pads near the SIM card socket. I then connected these wires to a pin header and plugged it into my DSLogic Plus logic analyzer. I analyzed the logic captures after turning the WF721 on and allowing it to initialize the SIM card and attempt to connect to the cellular network (the service to it has been disconnected so it doesn’t actually succeed).

Command Analysis

After looking at the raw logic capture, there was a lot that I had to sift through. I needed to create a custom setting for the UART decoder as the serial output isn’t your traditional “9600-8-N-1” setting. Rather, the interface uses 8 data bits, even parity, and 2 stop bits. The baud rate is determined by a parameter in the card’s initial identification, the ATR (Answer to Reset). I parsed the card’s ATR that I previously captured on the PC using the SpringCard PC/SC Diagnostic tool using Ludovic Rousseau’s online tool, I determined I needed to use a baud rate of 250 kbit/s, since the card was being fed a 4 MHz clock.

T=0 Smart Card Command (APDU) Structure

The smart card communicates to and from the host through APDUs (Application Protocol Data Units). The command header for a T=0 smart card (character-based I/O, which most cards use) is made up of 5 bytes: class, instruction, 2 parameter bytes and a length/3rd parameter byte. To acknowledge the command, the card sends the instruction byte back to the reader and the data is transferred to/from the card, depending on the command used. The card then sends two status bytes that indicate whether the command is successful; if it is, the response is 0x9000. A graphical representation of this process can be seen in the next section.

VERIFY PIN Command Decoding

The raw data structure of a SIM card’s VERIFY PIN command. Each part of the flow is labeled for ease of understanding (click image to see full size).

The command I’m looking for is 0x20 (VERIFY PIN), and I had to sift through the command flow in the logic analyzer until I found it. After a lot of preceding commands, I found the command I was looking for, and I found the PIN… and it’s in plaintext! As it turns out, it is sent as an ASCII string, but it’s not null terminated like a regular string. Instead, the data is always 8 bytes (allowing up to an 8-digit PIN), but a PIN shorter than 8 digits will have the end bytes padded with 0xFF (all binary ones). It was easy to determine that the bytes 0x32 33 37 36 is the ASCII representation of the PIN 2376, and after the card waited many tens of milliseconds, it acknowledged the PIN was correct as it gave the expected 0x9000 response code.

PIN Testing & Unlocking

Dekart SIM Manager showing the phone number programmed into the SIM card (censored for privacy).

I tried the PIN in the Dekart SIM Manager software on my computer, and it worked! I was able to read out the contents of the SIM and find out what phone number it used to have, although no other useful information was found.

By using the legacy GSM class 0xA0, I was able to manually verify the PIN by directly communicating with the SIM card using the same command syntax in PC/SC Diagnostic:

Testing the VERIFY PIN command directly in SpringCard PC/SC Diagnostic.

I took the SIM card out and put it in my Galaxy Core LTE phone, entered the PIN, and as expected it brought up the network unlock prompt. I was able to contact my carrier to get the phone unlocked, and they did it for free (as legally required in Canada) – it turned out to be helpful I was on the same network, as they needed an account to authenticate the request against, even if the phone is registered to another account holder. After entering the 8-digit unlock PIN they provided, the phone was successfully unlocked!

The WF721 is in all likelihood also network locked, but that’s a bridge I haven’t crossed yet.

Conclusion

After a bit of sleuthing into how SIM cards communicate with a cell phone, I was able to decipher the exact command used to authenticate a SIM card PIN inside a disused cellular home phone, all to check if a hand-me-down smartphone was network-locked to its original carrier. Was it a lot of effort just to do that? Maybe, but where’s the fun in buying a prepaid SIM card? 🙂

Unboxing and review of SanDisk 64GB microSDXC High Endurance Card

Posted on August 17, 2019 by ginbot86

UPDATE (July 19, 2020): I’ve analyzed a 128GB version of the High Endurance card, and it appears that SanDisk is using 3D TLC Flash.

Dashcams: they can be a crucial tool when reconstructing events in a vehicular incident, or a source of entertainment when watching compilations on YouTube. Like any modern device, they generally use SD or microSD cards as their storage medium. However, not all cards are created equal.

Cheaper cards, like SanDisk’s Ultra lineup, use cheaper TLC (triple-level cell) NAND Flash that is ill-suited to the harsh working conditions of a dashcam. Not only does the card have to endure temperature extremes, the constant writes can burn through the Flash’s write cycles in short order. In fact, SanDisk specifically denounces this line of cards for use in continuous-recording applications.

The solution: high-endurance memory cards! These cards (at least in theory) use more durable MLC or even SLC NAND Flash, which can take many more write cycles. I purchased the 64-gigabyte model, the SDSQQNR-064G-G46A.

Unboxing

The card’s packaging isn’t much different than SanDisk’s typical microSD card offerings. The paper-and-plastic package includes a small blister pack that holds the microSD card itself and the full-size SD card adapter, without a carrying case (granted, the memory card is expected to stay inside the dashcam for most of its working life).

The packaging also includes a license key for a 1-year subscription to the RescuePRO data recovery software (although in all honesty, you’d be better off using the free PhotoRec software instead).

Endurance Rating

SanDisk’s lineup of high-endurance memory cards are designed for use in very write-intensive workloads, such as constant video recording.

Unfortunately, the endurance specifications for these cards are (probably intentionally) vague, only providing a set number of hours of video recording. However, we can infer a rating with a little bit of math.

SanDisk’s card packaging defines Full HD video to be 26 Mbps, which is equivalent to 3.25 (binary) megabytes per second. This equates to 11,700 megabytes per hour, or 11.426 gigabytes per hour. With a rating of 5,000 hours at this data rate, we get a specified endurance of 57,128.91 gigabytes written, or 55.79 terabytes written (TBW).

Memory cards, like other block-based storage media, often define capacities with decimal prefixes, whereas computers usually binary. A “64-gigabyte” card is really 59.605 binary gigabytes (“gibibytes“) in capacity, but in this blog post I’m using the Windows notation of gigabytes; that is, calculating in binary but displaying as decimal. 😛

Therefore, we get a final calculated P/E (program-erase) cycle count of… 936 cycles. This is more in line with traditional 2D TLC NAND Flash, so I suspect that this rating is either based on different bitrates, or SanDisk is being really, really conservative in their estimates – or heck, maybe this really is just TLC NAND Flash that’s being configured and/or warrantied differently by SanDisk. As much as I am tempted to remove the epoxy coating that covers the manufacturing test pads in order to get a NAND Flash signature directly, I like having a warranty for at least a few years. Maybe I’ll buy another card to try this on…

UPDATE (July 19, 2020): I got my paws on another card (the 128GB variant), and did some reverse-engineering work on it to determine what Flash SanDisk used. It turns out they used 3D TLC NAND, which is still quite durable and reliable due to the use of larger process geometries. The Flash should easily withstand thousands of write cycles without much issue.

Card Information

Using an older laptop with a true SD-compliant slot (most newer ones are just USB card readers internally), I was able to grab the card’s metadata from Linux. These information files are found in /sys/block/mmcblkX/device, where X is usually 0 depending on your host machine. Android used to be able to do this as well, but nowadays it’s not possible without a rooted operating system.

Item	Value
CID (Card ID)	035744534836344780ed1bbb9e013100
CSD (Card Specific Data)	400e0032db790001dbd37f800a404000
Manufacturer ID	0x03 (SanDisk)
Manufacture Date	January 2019
Device Name	SH64G
Firmware Version	0x0
Hardware Revision	0x8

Initial Formatting

The card is formatted as exFAT, with a 16 MB offset (that is, the first 16 MB of the card is unallocated), with an allocation unit size of 128 kilobytes. It uses a very basic MBR (Master Boot Record) partition structure, with the first sector being the bare minimum to be recognized as a valid structure.

: The card’s file system properties in Windows.

: The card’s partition structure in Hard Disk Sentinel.

: The card’s MBR.

Performance

Now that I’ve probably irked some of my readers with my usage of decimal and binary prefixes, it’s time to see how fast this card can go. SanDisk’s own ratings for the card are very brief, citing a sequential read/write speed of 100 and 40 MB/s respectively. It is rated for the V30 Video speed classification, which guarantees a minimum of 30 MB/s sequential writes continuously.

All the tests below were performed on my desktop computer using a FCR-HS4 USB 3.0 reader from Kingston, which is based on the Realtek RTS5321 chipset.

CrystalDiskMark

CrystalDiskMark is the de-facto standard for storage benchmarks. I’m using the 64-bit edition of CDM, version 5.2.0.

I/O Type	Read	Write
Sequential QD32	91.80 MB/s	60.56 MB/s
Sequential	93.33 MB/s	61.66 MB/s
4K Random QD32	8.319 MB/s 2129.7 IOPS	4.004 MB/s 1025.0 IOPS
4K Random	8.121 MB/s 2079.0 IOPS	3.971 MB/s 1016.6 IOPS

The sequential I/O speeds are on par with a modern microSDXC card, and the IOPS aren’t too shabby either; they exceed the IOPS requirements for the A1 performance class which requires R/W IOPS of 1500 and 500 respectively. This could make this type of card a viable option for other write-heavy environments – this includes single-board computers (SBCs) like the Raspberry Pi, where memory card failures due to excessive writes are common.

ATTO Disk Benchmark

The card’s read/write performance levels off at around the 64-kilobyte mark during testing, showing that operations smaller than this incur a significant performance penalty. This may also be indicative of the internal page and block sizes of the NAND Flash itself.

Hard Disk Sentinel

Hard Disk Sentinel comes with a bunch of disk benchmarking tools, including some to test the entire “surface” of a drive. I used the software’s Surface Test tool to measure the card’s performance before and after filling the drive with data – first with random data, then with all zeroes.

Random Seek Test

The Random Seek Test measures the card’s latency when performing random “seeks”, although more accurately it reads a single sector from a random location.

State	Average Latency	Minimum Latency	Maximum Latency
Empty/Initial (0x00)	360 µs	350 µs	420 µs
Random Fill	600 µs	590 µs	670 µs
Zero Fill	600 µs	590 µs	690 µs

The card initially had about 420 microseconds of latency, but after filling the card with random data, this increased to 670 microseconds. Filling the card with all zeroes again did not improve performance, and his isn’t helped by the fact that SD cards generally lack the ability to “TRIM” unused sectors like SSDs or eMMC chips.

Full Surface Read (or at least an attempt)

: Sequential read speeds over the length of the card, taken from Hard Disk Sentinel.

This is where things get a bit… interesting. It was around this time that I noticed some performance inconsistencies that didn’t show up on other benchmarks. Although the I/O speeds largely matched what my other benchmarks revealed, I noticed frequent dips below normal, often down to the mid-20 MB/s range! I wasn’t sure that this was necessarily the card’s fault (pauses in read/writes could result in performance degradation on a device if it can’t buffer the writes well enough), or if my card reader/operating system/etc. was responsible.

I decided to hold off on publishing the sequential write test until I get this issue figured out – perhaps it’s worthy of a blog post all on its own…

Resurrecting a dead MacBook Pro (mid-2012 13-inch, model A1278)

Posted on July 7, 2019 by ginbot86

As seen on Hackaday!

A couple weeks ago, I picked up a dead MacBook Pro that was on its way to the recycle bin, and was curious as to whether I would be able to fix it. It had a note attached to it citing several issues with the computer: the display doesn’t work, the battery doesn’t charge, one of the USB ports doesn’t work, and it won’t load an operating system. It certainly didn’t look particularly promising, but I felt it would be a good way to test my skills in component-level repair – with a pretty nice prize if I succeeded.

Triage

The computer I picked up is a mid-2012 MacBook Pro by Apple; it is the A1278 model with a logic board number of 820-3115-B, and it comes with an i7-3520M CPU and 8 GB of DDR3 RAM – however, the hard drive was taken out of the computer by the time I received it. As previously noted, the computer had a laundry list of issues that were certainly the reason the original owner decided to discard their computer – a laptop that doesn’t boot nor have a display isn’t a particularly useful one.

Connecting a MagSafe AC adapter to the computer revealed even more issues: even though the unit was already noted that it wouldn’t charge, I noticed there was no LED indicator on the power adapter’s plug, and the computer wouldn’t power on, even with external power connected; the only sign of life was one of the LED level indicators rapidly flashing when I pressed the button. With this functionality test being unsuccessful, I decided to open up the computer to see what else was wrong…

Troubleshooting & Diagnosis

Unscrewing the bottom cover revealed what horrors the computer had experienced. There was clear evidence that it had suffered from liquid damage: rampant corrosion around the LCD connector and some of the power circuitry, and some of the corrosion deposits were even left on the computer’s bottom cover! If you watch Louis Rossmann’s videos, you would know that liquid damage rarely is an easy fix, especially when high-voltage LED backlight circuitry gets involved.

: Corrosion deposits around LCD backlight connector, backlight driver, and power rail current sensor.

Liberal use of a 70% isopropyl alcohol solution and a brush was able to scrub away all the corrosion on the computer’s logic board, and the results were not pretty:

: After cleaning up all the corrosion, lots of components and PCB traces have been corroded or lost entirely. Note the dark and tarnished probe points – they should be silver. The pads in the center used to have a fuse…

Many PCB test pads were either corroded or entirely gone, the backlight fuse (and its pads) were nowhere to be found, and some ICs were missing entire pins! Whatever was spilled on this area of the MacBook certainly had some corrosive properties to it, and it looks like nothing was done to stop the initial damage. With a schematic and board-view software in hand, it was time to investigate what particular components had suffered damage.

: F9700 (backlight fuse) as shown in the schematic, which can be looked up in the board view.

: OpenBoardView in use, showing what F9700 connects to, and where.

Power Supply

Before any device can perform any useful functions, it needs power. I reconnected the AC adapter and started to check the voltages around the DC input jack and its surrounding support circuitry. Since I was able to press the MacBook’s battery indicator and get some response when connected to power, I knew that the main input fuse was intact, and that the SMC (System Management Controller) chip was receiving power via the PP3V42_G3H rail and functional; the G3H (G3-Hot) designation means that the power rail is always on, even if the computer is otherwise turned off. I checked the voltage at the DC jack’s ADAPTER_SENSE line, which is normally at approximately 3.3 volts and uses the 1-Wire protocol to communicate with the power adapter and control the LED on the power adapter’s MagSafe plug. To my surprise, it was at a staggering 16 volts, which meant that something was shorting the DC input voltage (about 16.5 volts) onto a low-voltage communication line – no wonder there wasn’t any LED indicator when I plugged it in! A multimeter measurement found about 2 kOhms of resistance from the power line to the communication line. Thankfully the MacBook’s logic board features a MAX9940 1-Wire overvoltage protection chip, which is rated to protect against voltages as high as 30 volts. I scavenged another DC input connector from an older, dead MacBook which shared the same connector and pinout. After connecting this to the logic board, I found that I got a green LED upon connecting the AC adapter, and the CPU fan started spinning; this is a very good sign as this means the main power circuitry is intact. Measuring the CPU’s Vcore voltage revealed a voltage of about 0.8 volts, which is normal for a modern laptop CPU. With the “heart” of the computer checked out, it was time to focus on the area most affected by the water damage.

LCD & Backlight

Examining the backlight connector and its surrounding circuitry revealed significant damage to many components and the PCB itself. The power supply pins on the LCD connector showed a significant amount of corrosion, and I was concerned that the backlight’s output voltage (up to 52 volts!) could have made its way through all the corrosion residue and damaged critical data lines between the display and the graphics controller. I noticed the backlight fuse (F9700, a 3-amp 0603-size fuse) had gone more than just open-circuit – I couldn’t even find the fuse or its corresponding PCB pads initially! I then probed the LCD connector and found that the display’s 3.3-volt power lines were open-circuit; the corrosion had eaten through the traces between the connector and its decoupling capacitors nearby. Using a diode-mode measurement on the FPD-Link (often called LVDS) lines revealed that the connections were intact; there weren’t any anomalous readings or short-circuits on those lines, the DDC (Display Data Channel) lines, and the 3.3-volt power lines.

Due to the high voltages used to drive LED backlights, I had my suspicions on U9701 (a Texas Instruments LP8550 LED backlight driver). It’s a tiny ball-grid array (BGA) package, and attempts to clean the chip from its edges didn’t seem to do much. Its corrosion looked limited at first – only the feedback line’s probe point was lost – but I was sure the chip was on its last legs (or is it balls?).

Power Management

The LCD connector is in close proximity to the computer’s DC input and its “PPBUS_G3Hot” power rail, which is always on (even if the computer is otherwise turned off), which exacerbates any corrosion due to liquid damage due to its high voltage. Further examination revealed significant corrosion on the outside of the CPU’s high-side current sense resistor (R5400), and the current-measurement pins (pins 4 and 5) on U5400 (a Texas Instruments INA213 current-sense amplifier) were completely gone! Clearly there was no way to salvage that component.

There was significant damage to the SMC’s DC input voltage sense circuitry (“VD0R”), with pins 3 and 4 of Q5490 (an ON Semiconductor NTUD3169CZ complementary pair of N-channel and P-channel MOSFETs) being completely eroded away, much like U5400’s current-sense pins; this part of the circuit uses a P-channel MOSFET to switch on a resistive voltage divider, allowing the SMC to measure what the voltage is on its MagSafe input connector. Also, many of the probe points related to that circuit were also completely eroded, revealing dark pits instead of silver-plated copper pads.

FireWire

The FireWire circuit wasn’t spared from the carnage, either. Pins 3 and 4 on Q4262 (a Diodes Incorporated BSS8042DW complementary MOSFET pair) were also severely damaged; these pins are used to quickly disable the FireWire power output transistor (Q4260, an ON Semiconductor FDC638P P-channel MOSFET) in case of a “Late-VG event“. This occurs if the ground pins of the FireWire connector are mated too late when plugging in a device – this creates a dangerous overvoltage condition on the FireWire data lines, as up to 30 volts briefly find a return path through the data lines, risking damage to the device and host controller. I wasn’t as concerned with this circuit, as I don’t have any FireWire peripherals, and the circuit in its current state simply means the FireWire port will be unable to disconnect power if a bad cord is plugged in.

Thunderbolt

The area that had the least liquid damage was C3897, which belonged to U3890 (a Linear Technologies LT3957, a 15-volt boost converter for the MacBook’s T29 chip and Thunderbolt interface). All this area needed was a bit of corrosion cleanup.

USB Port

During the functionality tests, I noticed the metal casings of the USB port were getting very hot to the touch, and I nearly burned myself on U4600 (a Texas Instruments TPS2561, a dual-channel load switch with internal current limiting)! I found a short-to-ground problem on a power line on one of the USB ports, which explains the symptom listed on the note. I desoldered the chip, initially thinking the issue was in the chip itself, but the fault remained. I narrowed the problem down to C4695, a 10-microfarad ceramic capacitor that had short-circuited internally; this caused the TPS2561 to go into current-limiting mode, which turns the chip into a resistor and dissipate copious amounts of heat into the PCB, which made its way to the USB ports (and then my fingers – ouch).

Hard Drive Cable

During the repair process, I was able to install Mac OS X Lion to a SATA SSD, but soon found the MacBook unable to recognize SSDs, despite hard disk drives showing up just fine! As it turns out, the A1278 is notorious for bad HDD cables, with even replacements failing within months of installation. This appeared to be caused by chronic frictional damage, as the cable is sandwiched between the hard drive and the MacBook’s rough aluminum casing – even regular use of the laptop was found to create hairline cracks in the cable. Thankfully replacements are relatively inexpensive, and a little bit of Kapton tape as a barrier against the casing was the “vaccine” against future cable failures.

: Replacement SATA cable on top. The PCB traces seem thicker and more robust than the original.

Repairs

With all of the problems written down, it was time to start fixing up the MacBook. Time to break out the hot air rework station, soldering iron, solder, magnet wire, and plenty of flux!

DC Input Jack

I desoldered the DC input jack, and found there was a lot of corrosion residue bridging the +16.5-volt power line to the ADAPTER_SENSE 1-Wire communication line.

: Black corrosion deposits under the MagSafe connector, causing a high-resistance short of the ADAPTER_SENSE data line to 16.5 volts.

: The PCB side of the corroded MagSafe connector. Note the loss of copper on the pads.

With some isopropyl alcohol and some scrubbing with a small brush, I was able to clean up the corrosion and resoldered the jack into place. A quick multimeter test found that there was no more 2 kOhms of resistance from the power to the data line, and I was able to get an LED indication when I plugged in the AC adapter, including an orange light that indicates the battery is charging.

LCD Connector

I wanted to determine if the display was still functional, so I first focused my attention to the LCD connector, even if I had to eschew the LED backlight for a bit.

I ran a jumper wire from L9004 to pins 2 and 3 of the LCD connector; this belongs to PP3V3_LCDVDD_SW_F, which provides the 3.3-volt power to run the LCD panel except the backlight. After cleaning out the flux and corrosion on the logic board’s connector as well as the LCD cable, I was able to get an image on the display!

: Jumper from L9004 to pins 2 and 3 on J9000 backlight connector. Damage to Q4262 also visible.

: A “frontlit” MacBook LCD.

USB Port

With the faulty component identified, I replaced C4695 with an identically-rated 10-microfarad 6.3-volt X5R ceramic capacitor in an 0603-sized package. After replacing the capacitor, the USB port was fully functional again!

: Replaced C4695 USB output capacitor. 10 uF, 6.3 volt X5R, 0603 size.

Current-Sense Amplifier

After ordering both the INA213 and LP8550 from Texas Instruments, it was only a few days before they arrived in the mail. I desoldered the dead chip from the logic board, cleaned up the pads with some flux and desoldering braid, and installed the new chip. Running Apple Service Diagnostic tools showed that the current-sensing circuit was working correctly.

DC Input Voltage Divider Switch

: Replaced PFET half of Q5490 (centre) with NTK3142P, bypassing lost traces/probe points. R5494 replaced with wire jumper, on left.

I didn’t want to buy another transistor pair for Q5490, so I replaced the P-channel half with an ON Semiconductor NTK3142P P-channel MOSFET that I salvaged from an older donor MacBook logic board. I scraped away some solder mask on one of the broken traces heading to the SMC’s voltage divider so I could solder the transistor’s drain terminal to it, and used magnet wire to connect the transistor’s gate and source to their corresponding locations across R5491. R5494, leading to PM_SUS_EN, was found to have a 0-ohm resistor that was open-circuit; this was easily bypassed with a wire jumper across the resistor’s original pads. After cleaning off the flux and performing continuity measurements, I measured the voltage at the SMC’s voltage divider resistors and got a valid voltage reading when I plugged in the AC adapter.

LED Backlight Driver

The LP8550 was up next for repair. I took a 2-amp 0603-sized fuse from a dead hard drive, and used some magnet wire to reattach it to the remnants of F9700, which was a 3-amp fuse originally; note that it’s far safer to use a fuse of a smaller rating instead of a larger one, should a circuit fault still exist.

Tracing the other lines to the LP8550 revealed that R9731 (leading to PPBUS_SW_LCDBKLT_PWR) was open-circuit at a via, which was easily bridged with some solder and magnet wire. R9010 (leading to PPBUS_SW_BKL) was open as well.

After reinstalling the fuse, I actually got the backlight working! However, upon a power cycle I heard a snap, saw a puff of smoke, and lost the original backlight chip. Chances are there was indeed some corrosion residue had caused 50-odd volts to end up on a more sensitive pin on the LP8550. I used an Xacto knife to lightly scratch an outline around the chip, then used copious amounts of flux and desoldered the dead chip with my hot air rework station; I also removed the fuse to help in further troubleshooting to ensure that there weren’t any short-circuits to ground on the backlight circuit. I cleaned up the area with leaded solder and some solder wick, and cleaned up the residual flux in anticipation of the new chip’s installation.

: The remnants of the original LP8550 (U9701). Note the damage to lowest-right ball on PCB, lowest-left on chip. F9700 temporarily removed.

: New LP8550 installed, with replacement fuse.

The chip was remarkably easy to install – just get the A1 ball lined up according to the board view, and heat the board to the right temperature. After thoroughly cleaning away the flux from the area, I turned on the MacBook… and let there be (back)light! I power-cycled the computer and the LED backlight remained functional! (And for the record, the fuse didn’t even blow during the entire ordeal.)

FireWire Late-VG Protection Circuit

~~I considered this issue to be a “WONTFIX“~~, as I had no use for FireWire connectivity (nor do I have the correct FireWire 800 cables anyway). If I want to sell this computer, I might install a P-channel MOSFET to replace Q4262 (see the LCD Connector section above) in a similar fashion to the DC input voltage-sensing circuitry.

UPDATE (February 26, 2020): Actually, several months ago I decided to finish things once and for all, so I replaced the damaged P-channel MOSFET circuitry. Do I have much use for FireWire? Not really, but it at least means I can experiment with it or something later on, if desired.

Testing

It takes a little bit of Google-Fu, but with the help of a BitTorrent client, I downloaded the disk images to create an Apple Service Diagnostic (ASD) drive. This is far more sophisticated than the built-in diagnostic when you boot the computer while holding down the D key. With ASD, one has the option to use a stripped-down version of Mac OS X – in a similar vein as WinPE – or a very lightweight UEFI (Universal Extensible Firmware Interface) environment that looks very much like Mac OS 9 and earlier.

: LCD backlight restored; all tests passed in Apple Service Diagnostic!

It took over half an hour, but all the tests passed without a problem, since all the sensor readings were valid. My MacBook Pro has been restored to working order! I installed Mac OS X High Sierra to a 1TB SSD, and used Boot Camp to run Windows 10 Pro as the default operating system (what can I say, I like Windows 🙂 ). The Mac Precision Touchpad driver project makes the touchpad a pleasure to use, as the built-in Boot Camp driver provides a much less-comfortable experience.

Conclusion

Much like solving a puzzle, component-level troubleshooting of modern electronics is possible, but this is only feasible if the relevant documentation exists as a good reference point. One can do without them, but the act of reverse engineering isn’t easy if one only has a non-working device.

With the help of a schematic and board view (including the open-source software OpenBoardView), one can easily find what circuits a component belongs to, and where it goes. By following the connections, one can track down the problem(s) with the board, and hopefully save a device from an untimely end in the landfill or a recycling facility.

Right to Repair

This project is an example of why I believe in the right to repair. If I didn’t have (even unofficial) access to schematics, board views, and diagnostic software, I wouldn’t have been able to bring this dead MacBook Pro back to life. However, with a little bit of electronics troubleshooting knowledge and skill, I was delighted that I diverted a discarded dysfunctional device from a demise in the dumpster. In fact, this blog post was written from the MacBook I just repaired!

Discreet Quality: Review of the sketchiest-looking 512GB Lexar SDXC card

Posted on February 24, 2019 by ginbot86

It’s amazing how much Flash-based storage technology has advanced in the last few years, especially considering how much prices have dropped.

Naturally, when it comes to speed, capacity and price, consumers tend to look for the lowest price; as manufacturers race towards the bottom line, many will take the low road and sell counterfeit goods. This is especially prevalent in the NAND Flash market, and online marketplaces like eBay, AliExpress and even Amazon are fraught with countless fake storage devices that claim high capacities at too-good-to-be-true prices. It’s not uncommon to see unrealistic capacities sold for a few tens of dollars, but what the customer ends up receiving is a storage device with a falsified capacity that will pass a simple copy-paste test but will corrupt itself with extended use.

While browsing eBay for some deals on some Flash storage, I happened upon a very strange-looking 512GB SDXC card. It was listed as an OEM Lexar card but had no labels, selling for an unprecedentedly low price of $60 USD (the card would cost several times more at normal retail outlets). On the outside, everything about the card’s exterior seems to raise a red flag that the card is not to be trusted.

eBay listing of the Lexar OEM 512GB SDXC card

Upon closer inspection, there are some hints that one shouldn’t always judge a book – er, card – by its cover. The laser-etched markings might look like cryptic gibberish to the layperson, but the markings “SM2702BAC” and “L95B” have actual meanings; the SM2702 is an SD card controller by Silicon Motion, and L95B refers to the 16nm generation of MLC NAND Flash by Micron, which owns the Lexar brand (but unfortunately is being discontinued). The seller also says that the cards have been tested, which is reassuring.

I decided to take the plunge and plunk down about $80 USD including shipping (or $105 CAD at the time) and buy a card for myself.

A Closer Look

After waiting a few weeks, the card showed up in my mailbox. The seller did a very good job packaging it, even placing the card in an ESD shielding bag before wrapping it with foam and placing it in a bubble mailer (it’s much better than the plastic wrap I’ve had some used i7 CPUs by a huge amount).

Back of the Lexar OEM 512GB SDXC card

Front of the Lexar OEM 512GB SDXC card

The card looks very plain, with the top label area lacking any labeling, and the same laser-etched markings on the back. The card’s contacts indicate that it has been placed in a card reader a few times before (presumably for testing).

Card Identification

I used my old Gateway M-7305u laptop with Kali Linux to see what information the card reports. These older laptops have true SDA (SD Association) compliant card slots, so they will identify as an actual SD card instead of a USB drive like with many modern laptops; in Linux these show up as devices like /dev/mmcblk0 instead of /dev/sda. By using the “dmesg -wH” command I can read the kernel logs once the card is connected to the computer.

[Jan24 10:52] mmc0: new high speed SDXC card at address 59b4
[ +0.094917] mmcblk0: mmc0:59b4       483 GiB 
[ +0.001111] mmcblk0: p1

The card reports a capacity of 483 GiB (that’s binary gigabytes, or 519.6 decimal – a.k.a. “weasel” – gigabytes), but the SD card name is ” ” – five ASCII spaces. Everything about the card superficially rings alarm bells! However, I wasn’t phased, and decided to try the card in my Kingston FCR-HS4 USB 3.0 card reader, which uses the Realtek RTS5321 chipset.

OEM Lexar 512GB SDXC card in Disk Management

Examining the card in Windows shows that the card was formatted as exFAT with a drive name of “SDXC”, suggesting it may have been formatted by the seller with the SD Formatter tool. Looking at the raw sector data in Hard Disk Sentinel suggests that the seller indeed do a full capacity test, as the data patterns match that of the program H2testw, an excellent tool for detecting fake Flash memory. This is a good sign – the seller did their due diligence and by this point I already had a good feeling that the card is genuine.

However, I wanted to test this for myself, so I ran the H2testw utility myself and let it run on the card. The write speed remained consistent throughout, which is a good indication that the card is not overwriting memory locations like in fake Flash storage (the card did get uncomfortably hot during the process, however). It took four hours to complete the write and read test, but everything came out clean – the card is genuine, even when every other sign says otherwise!

H2testw verifying that the OEM Lexar card’s 512GB capacity is genuine

Performance

With the card verified, it was time to put it to the test.

CrystalDiskMark

The card showed sequential read speeds of 92.03 MB/s and sequential write speeds of 60.45 MB/s; the sequential write speed coincides with the seller’s rating of 400x (400 * 150 kB/s = 60 MB/s).

The random 4K I/O performance isn’t great, especially with writes, but it isn’t bad either. The card managed 4K random read speeds of 6.644 MB/s (1700.9 IOPS) and 4K random write speeds of 0.671 MB/s (171.8 IOPS).

Benchmark of the 512GB Lexar OEM SDXC card in CrystalDiskMark 3.0.4

Conclusion

In the end, I was satisfied – I got a 512GB SDXC memory card at a fraction of the cost from a normal retail outlet. It’s not exactly a speed demon, but it’s not a slowpoke either. The looks may be deterring for most folks (and rightly so), but with the right tools and knowledge, one can pick up one of these less aesthetically-pleasing memory cards and save some serious coin in the process.

eMMC Adventures, Episode 4: Recovering data from physically damaged BGA eMMC Flash storage chips

Posted on January 22, 2019 by ginbot86

As seen on Hackaday!

The ball grid array (BGA) chip package has been instrumental in getting modern electronics to fit in smaller and smaller spaces, as it uses tiny balls of solder on the bottom of the package to make electrical connections, instead of copper leads on the edge of the chip package. This allows for hundreds of connections to be made in a small amount of PCB area, but their size also makes them very vulnerable to damage as well.

: eMMC with severe pad cratering on critical data/control lines

One common way for BGA chips to become damaged is called “pad cratering“, where the copper pad on the package’s substrate (basically a wafer-thin circuit board) separates and leaves behind a crater.

In the case of eMMC (Embedded MultiMediaCard), its package type is known as an FBGA (Fine-pitch Ball Grid Array), so the area of each pad is very small (0.4 mm in diameter!); it doesn’t take much at all to crater the pad – even gently removing solder with solder wick and generous amounts of flux can still cause damage! Most of the pads on an eMMC package are unused, but if any one of the DAT0, CLK, or CMD pads are damaged, then the chip is rendered unusable, even if the chip is placed into a socket for data recovery. If the DAT1-DAT7 pads are damaged, data recovery becomes much slower as the chip is forced to use fewer lines to transmit data (the MMC standard supports data over 1, 4, or 8 lines).

However, there is some hope. Many FBGA packages, including eMMC, use pads that are SMD (solder-mask defined); this means the solder mask is what defines the size of the pad, not the copper itself. Therefore, when the pad gets cratered, often there is a “halo” of copper left behind that still has a chance of getting an electrical connection.

: Top and side diagram of normal and cratered BGA pad, with ZIF socket

: Detail showing the pins in the eMMC ZIF socket

The trick is how to to get a flat conductive area that a chip socket can use to get a reliable connection (without a copper pad, soldering is no longer an option). The eMMC socket adapter I used breaks out the eMMC onto an MMCplus-shaped PCB that can be inserted into any commercial SD card reader.

Filling in the Blanks

There are a few possible materials that can be used to restore contact area on a damaged BGA pad. One possible option is a silver-filled conductive epoxy, but I have not tested its efficacy; an additional consideration is that the volume of the filled-in crater might not be enough to get a filling with sufficiently low resistance for a good connection.

Another option is using solder paste, which I used in this case. Unfortunately, solder’s surface tension is our enemy when trying to fill in a flat area (it wants to form cohesive balls and therefore won’t want to stick to the ring of copper left around the crater), so a means of forcing the solder into the crater requires something flat, rigid and capable of handling the high temperatures experienced during soldering.

At first I tried Kapton (polyimide) tape, but that was a massive failure since it didn’t have the rigidity to stay flat when the solder paste began to melt, and the liquid flux rendered the adhesive useless.

The solution to the issue came in the form of glass. Specifically, I used very thin (0.15 mm thick!) glass “cover slips” normally used to prepare specimens for viewing under a microscope. These can be very inexpensive and one can obtain hundreds of them for a few dollars. The key is to fill the craters with the solder paste by using a knife as a squeegee, then placing the cover slip on top of the eMMC and reflowing it.

It took a few iterations for the pads on some of my eMMC chips to be restored sufficiently, as the volume taken up by the solder will be less than the paste and its accompanying flux. It doesn’t have to fill the entire crater – it just needs to be enough for the eMMC socket’s pins to make a solid connection.

: eMMC with pad contact partially restored with solder paste and microscope cover glass

: Diagram of how the glass cover slip keeps solder paste in place to restore pad contact

Conclusion

The high-density nature of modern BGA chips is both a blessing and a curse. When trying to do data recovery from devices that use such tiny chips, such as eMMC or UFS Flash storage, sometimes the desoldering process is too much for the chip’s pads to handle. With some ingenuity (and thin glass), it might be possible to temporarily restore enough conductive pad area to get the data off with the help of an eMMC socket.

eMMC Adventures, Episode 3: Building a custom adapter to use cheap eMMC-based 32GB SSD modules

Posted on November 6, 2018 by ginbot86

As seen on Hackaday!

While on my quest for more eMMC-based storage devices, I stumbled upon a few devices that piqued my interest: eMMC-based SATA SSDs! I found two models of particular interest: Dell had M.2 modules with a 2.5″ adapter, and HP had custom boards intended for use in cheap laptops (for example, the HP 14-an012nr). Although the former was easier for me to use (but not acquire), I will be focusing on the latter in this blog post.

Overview of HP 14-am/14-an Series SSD Module

Unlike Dell’s convenient M.2 modules, the cheaper boards from HP (costing about $12 USD when I purchased them) had a physical interface intended for use only with its intended host; despite using a SATA interface, physically it used a 10-pin FFC (Flat Flexible Connector, aka “ribbon cable”) since it was designed to work only with HP’s 14-am/14-an series of low-cost laptops. The boards are labeled “DINERAMD-6050A2862201-DB-A01” and have a copyright date of 2016 in my case.

: HP eMMC SSD board in its natural habitat (courtesy of YouTube: https://www.youtube.com/watch?v=ulmmYmbwowY)

: Close-up of board

The BayHub OZ788WR2 Bridge Chip

These eMMC-based SSDs use a curious little chip, the BayHub OZ788WR2 (labeled 788WR2A on the chip itself). It is an SD/MMC-to-SATA adapter, with an SD UHS-II/MMCplus HS200 device interface and SATA II 3Gbps host interface. Apart from the brief description from the manufacturer, no other data is available for the chip (and even finding the chip online is basically impossible).

It’s a shame that so little is known about this chip (and that it’s so rare to find in actual devices), especially since high-performance SD-to-SATA adapters otherwise do not exist, as they use outdated SD-to-CompactFlash adapter chips that are limited to 25 MB/s speeds. If I had the engineering expertise, time, money, and ability to acquire these chips, I’d totally try to make an SD-to-SATA adapter with this chip… but alas, that will still remain a fantasy.

Step 1: Pinout Discovery

The single connector on the eMMC SSD is a ZIF FFC (Zero Insertion Force, Flat Flexible Connector), with no publicly available pinout or any other information. Perhaps this was why I got them for so cheap – apart from holding only 32 GB, nobody could even use them in their own computer even if they wanted to!

When trying to reverse engineer an unknown connector pinout, one needs to first look for ground pins. This is easily accomplished by using a multimeter with a continuity or diode test function, with the multimeter’s positive lead on a known ground point on the DUT (Device Under Test) – screw holes are often good candidates to look for. Ground pins will read as a short, but active IC and power pins will look like a forward-biased diode – appropriately 0.5 to 1 volt. I found 3 power pins (these are often grouped together on connectors for greater current capacity), 3 ground pins, and 4 SATA data pins. The data pins don’t show up on the multimeter test since they have series AC coupling capacitors, but they are easily located next to the connector and have clearly visible differential pairs leading to them.

The issue now is trying to find what order the SATA data pins are in, and how they relate to a regular SATA interface. As it turns out, the pinout is very simple: it matches the pinout of the 7-pin regular SATA interface! This makes sense as the SSD module and the laptop itself are designed to be cheap to manufacture.

: Pinout for the HP eMMC-based SATA SSD module

Step 2: Building the Adapter (Take 1)

With the pinout known, the harder part is wiring up the connector. However, without a matching connector for the ribbon cable, I have no choice but to solder to it.

As I soon learned, not all flex cables are made of heat-resistant polyimide (aka Kapton) – this one melted before I could even tin the exposed leads. No matter, I’ll just use my trusty magnet wire and hook up the data and power lines! With the help of a salvaged SATA connector from a dead laptop drive, I was able to cobble together a crude adapter for the eMMC SSD board.

Although I didn’t end up taking a picture of the adapter, it wasn’t pretty. It also wasn’t very functional either – although the eMMC SSD board was able to identify itself (on my PC it showed up as a “BHT WR202HH032G E70211F5”), I couldn’t actually perform any data transfer without causing the OZ788WR2 to log hundreds of interface checksum failures (but hey, it supports S.M.A.R.T. data reporting!).

After some tweaking of the wire spacing, I was able to get the adapter stable enough to work, and encased it in hot glue for protection. It lasted a few weeks but eventually stopped working because one of the data wires broke off inside the blob of hot glue. Additionally, the outer contacts on the ribbon cable connector were peeling away from its plastic substrate. It was time for a rebuild.

Step 3: Building a Dedicated eMMC SSD (the teaser!)

Since I had multiple eMMC SSD boards, I took one, replaced the eMMC with a 128GB one from Samsung (the KLMDG8JENB-B041) and removed the ribbon cable connector. In its place, I used some very thin twinaxial cable from a dead MacBook and used a gutted CFast-to-SATA adapter for a shell. Stay tuned for that in another blog post!

Step 4: Building the Adapter (again!)

Much like my previous attempt, I used a salvaged PCB from a dead laptop drive, but left a lot of it instead of chopping it off directly at the connector. This particular one was a dead Samsung HDD, and it had one particular feature that I could use to make a stronger adapter: it had a TSOP footprint for the DRAM cache, which was just the right pitch for me to solder the ribbon cable to!

With a little help of my hot air rework station, I removed the DRAM cache and DC-DC converter, leaving the SATA AC coupling capacitors and the power input components (filtering choke and capacitors, and input overvoltage protection) behind.

After scraping off some solder mask, I soldered the SATA data wires and the ground wires surrounding them with very thin magnet wire, trying to keep the data pairs as close to each other as possible to minimize the chance of interference causing problems. The power wire was soldered to the power input components, right next to the input capacitor for better power delivery.

: Completed adapter for HP eMMC SSD board

: Close-up image of connections and depopulated components

: Finished adapter with SSD board

After checking with the multimeter that no short circuits were present, I hooked up an eMMC board and plugged it into my PC. It enumerated without issues, and running several tests including CrystalDiskMark, h2testw, and Hard Disk Sentinel’s random read test, amassing several hundreds of gigabytes in reads and writes with zero CRC errors logged in the S.M.A.R.T. data.

: Benchmark of SK Hynix H26M64208EMR eMMC 5.1 in CrystalDiskMark

: Benchmark of Samsung KLMBG2JENB-B041 eMMC 5.1 in CrystalDiskMark

With everything checked out, I cleaned the circuit with isopropyl alcohol and covered the exposed end of the ribbon cable and the magnet wires with clear epoxy for protection. I also used a bit of epoxy on the flex connector to re-secure the lifted contacts to the substrate.

Conclusion

With a bit of wire and a circuit board from a dead HDD, I was able to reuse cheap eMMC-based SATA SSDs on computers that they weren’t meant for (and they even had copies of Windows 10 Home with extractable license keys! 🙂 ). Although not as fast as a modern full-fledged SSD, its relatively high 4K IOPS performance means it works well enough as a quick boot drive for running quick tests of OS installation without needing to sacrifice a bigger drive just for testing – and they consume less than a watt even when fully active!

Tutorial: Recovering Cookie Clicker saves from an offline installation/backup of Google Chrome

Posted on May 3, 2018 by ginbot86

Update (August 29, 2018): Turns out cleaning out your cookies/cache will erase your Cookie Clicker save. Who would’ve thought…

Cookie Clicker saves: You don’t realize the importance of saving your progress until you lose your save data. A few days ago I opened Chrome to my always-running instances of Cookie Clicker, but found that all of my progress was deleted (and it was showing a “Don’t forget to back up your save” message just to add insult to injury).

My heart sank when I realized that one of my runs, over three years old, had suddenly vanished into thin air. I tried restoring Google Chrome’s data via a Shadow Copy; no dice. I tried using my Windows Home Server 2011 backups, but realized that it would take over an hour to restore my Chrome folder. After much frustration, I decided to retrieve and examine Chrome’s Local Storage folder and see whether I could retrieve my save files that way – and it worked! Here’s how to recover your own Cookie Clicker saves…

Retrieving an older version of Google Chrome’s data folder

If you have Shadow Copy (aka Previous Versions) enabled, you may be in luck if the restore point(s) available have intact game save information. If you have an offline backup solution, that may be usable as well. If you have neither, you could try it on your current Chrome installation but your chances of recovery are much slimmer.

For Windows, Google Chrome’s default Local Storage folder located at: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Local Storage

There will probably be a large number of files ending in .localstorage and .localstorage-journal – these are unlikely to contain your saves, and if they are present, they will be many months out of date; Google has begun storing websites’ local storage in a LevelDB database. The database in question is stored in a folder called leveldb.

If you are attempting to retrieve the data from a current Chrome installation, close Chrome before continuing.

Copy this “leveldb” folder to another (safe) location as to avoid any accidental overwrite of the database while trying to recover the game saves. Download and install the FastoNoSQL database browser software (it’s a trial, but for our purposes it will do just fine – just follow the registration instructions and you can whip up a temporary email address if you need to).

Browsing the LevelDB database

When FastoNoSQL is opened for the first time, the Connections window will appear. Click the “Add connection” button (it looks like a green button with a + symbol on it); even though we’re just browsing some database files, it’s considered to be a “connection” to the database. Select “LevelDB” and choose the folder that holds the “leveldb” folder that was previously copied.

: Start FastoNoSQL, and open a new connection. Select “leveldb”.

: Select the “leveldb” folder that you previously copied.

: Click OK to open the database connection.

Once the database is opened, note the number of database keys (in my case it was 1212), right-click the “default” database in the Explorer tree on the left-hand side of the FastoNoSQL window, and select “Load content of database”. Enter the number of keys previously noted into the “Keys count” field, then click OK.

: Right-click the database connection and select “Load content of database”. Notice the “Search…” box below – we will find our save using this feature.

: Enter the number of keys and click OK.

: A large number of entries will appear. We will filter these out to find the saves.

In the “Search…” box, enter this text (select all the text in this box):

\\x5f\\x68\\x74\\x74\\x70\\x73\\x3a\\x2f\\x2f\\x6f\\x72\\x74\\x65\\x69\\x6c\\x2e\\x64\\x61\\x73\\x68\\x6e\\x65\\x74\\x2e\\x6f\\x72\\x67\\x00\\x01\\x43\\x6f\\x6f\\x6b\\x69\\x65\\x43\\x6c\\x69\\x63\\x6b\\x65\\x72\\x47\\x61\\x6d\\x65

This cryptic-looking text is a hexadecimal-escaped version of the string _https://orteil.dashnet.org, an SOH (Start of Header) character, and CookieClickerGame.

If your saves are found, you will see one or two entries, depending on whether or not the normal and/or Beta saves are present. The first entry will be the normal version of Cookie Clicker, and the second one, with a slightly longer key (ending in “\x42\x65\x74\x61”) is the for the Beta. Right-click the desired entry and choose “Edit…” to view the game save data. Copy the contents of the “Value” field into a text editor (Notepad, etc.), and delete the very first character before “Mi4w” – this is an SOH (Start of Header) character and we don’t need it to restore the game save. Save this text file so you have a backup of your game save, and import the file into Cookie Clicker (either by copy-pasting the text or using the “Load from file” button).

: Edit the entries found after entering the search string, and save the contents of the “Value” field. These are your game saves!

The game save should look like this (look for the bolded characters to ensure the game save data is intact):
Mi4wMDQ1fHwxNTI [... text omitted ...] OkwoDCgAR8%21END%21

If everything works out, your Cookie Clicker game save should be restored from the brink of destruction!

eMMC Adventures, Episode 2: Resurrecting a dead Intel Atom-based tablet by replacing failed eMMC storage

Posted on February 25, 2018 by ginbot86

As seen on Hackaday!

Recently, I purchased a cheap Intel Atom-based Windows 8 tablet (the DigiLand DL801W) that was being sold at a very low price ($15 USD, although the shipping to Canada negated much of the savings) because it would not boot into Windows – rather, it would only boot into the UEFI shell and cannot be interacted with without an external USB keyboard/mouse.

The patient, er, tablet

The tablet in question is a DigiLand DL801W (identified as a Lightcomm DL801W in the UEFI/BIOS data). It uses an Intel Atom Z3735F – a 1.33GHz quad-core tablet SoC (system-on-chip), 16GB of eMMC storage and a paltry 1GB of DDR3L-1333 SDRAM. It sports a 4500 mAh single-cell Li-ion battery, an 8″ 800×1200 display, 802.11b/g/n Wi-Fi using an SDIO chipset, two cameras, one microphone, mono speaker, stereo headphone jack and a single micro-USB port with USB On-The-Go support (this allows the port to act as a USB host port, allowing connections with standard USB devices like keyboards, mice, and USB drives).

Step 1: Triage & troubleshooting

The first step was to power on the tablet to get an initial glimpse into the issues preventing the tablet from booting. I was able to confirm that the eMMC was detected, but did not appear to have any valid MBR or file system; therefore, the UEFI firmware defaulted to entering the UEFI shell (which was of little use on its own as there is no on-screen keyboard available for it).

DigiLand DL801W with UEFI shell

However, one can immediately notice there is an issue with the shell: how do you enter commands without an on-screen keyboard? The solution was to use a USB OTG (On-The-Go) dongle to convert the micro-USB type B port into a USB type A host port.

Using the shell commands, I tried reading the contents of the boot sector, which should end with an MBR signature of 0x55AA. Instead, the eMMC returned some nonsensical data: the first half of the sector had a repeating byte pattern of 0x10000700, and the second half was all zeroes (0x00) except the last 16 bytes which were all ones (0xFF). The kicker was that this data was returned for every sector I tried to read. No wonder the eMMC was unbootable – the eMMC had suffered logical damage and the firmware was not functioning correctly.

After creating a 32-bit Windows 10 setup USB drive (these cheap low-RAM PCs often use a 32-bit UEFI despite having a 64-bit capable CPU), I opened Hard Disk Sentinel to take a deeper look at the condition of the onboard eMMC.

Malfunctioning Foresee 16GB eMMC visible in Hard Disk Sentinel

The eMMC identified itself with a vendor ID of 0x65, and an MMC name of “M”. It reported a capacity of 7.2 GB instead of the normal 16 GB, another sign that the eMMC was corrupted at the firmware level.

Foresee 16GB eMMC returning corrupted data

Using HDS, I performed a read scan of the entire eMMC despite its failed condition. The read speeds were mostly consistent, staying between 40 to 43 MB/s. A random read test revealed a consistent latency of 0.22 ms.

In order to assess whether the eMMC was writable in its current state, I ran a zero-fill and subsequent read scan. The eMMC appeared to accept writes but did not actually commit them, as HDS threw verification errors for all sectors.

After the tests in HDS, I decided to attempt an installation onto the eMMC to assess its writability. Windows Setup failed to create the disk partition structures, throwing an error message reading “We couldn’t create a new partition or locate an existing one”.

Step 2: Teardown & eMMC replacement

Since the onboard Foresee NCEMBS99-16G eMMC module was conclusively determined to be faulty, there was no point keeping it on the tablet’s motherboard. This also provided an opportunity to upgrade the eMMC to a a larger and faster one. Since this required the tablet to be disassembled, I decided to do a teardown of the tablet before attempting to replace the failed eMMC module (the teardown will be in a separate blog post when the time comes).

After removing the insulating plastic tape on the bottom of the PCB, I masked off the eMMC with some kapton tape to protect the other components and connectors from the heat of my hot-air rework station. With some hot air and patience, the failed Foresee eMMC was gone. This also revealed that the eMMC footprint supported both the 11.5×13 mm and 12×16 mm sizes, but the 12×16 mm footprint did not have the extra 16 solder balls for reinforcement (most eMMC balls are unused so their omission had no negative functional effect).

Foresee eMMC removed from DL801W’s motherboard

Instead of a barely-usable 16 GB of eMMC storage, I opted to use the Samsung KLMBG4GEND-B031 – a 32 GB eMMC 5.0 module. This chip boasts more than 2000 IOPS for 4K random I/O, which should be a boon for OS and application responsiveness.

Replacement Samsung KLMBG4GEND-B031 eMMC installed

A little flux and hot air was all I needed to give the 32 GB eMMC a new home. Time to reassemble the tablet and try installing Windows 10 again.

Step 3: OS reinstallation

After spending a few minutes cleaning the board and reinstalling it in the tablet, it was time to power the tablet back on, confirm the presence of the new eMMC and reattempt installing Windows.

Installing Windows 10 from USB drive via USB-OTG adapter

The eMMC replacement proved to be successful; within minutes, I was off to the races with a clean installation of Windows 10.

Conclusion

DL801W restored, running Texas Instruments’ bqSTUDIO software

This was a pretty fun project. With some electronics and computer troubleshooting skills, I had a tablet capable of running desktop Windows programs. Its low power consumption and USB host capabilities made for a great platform to run my Texas Instruments battery hardware and software without being tethered to my desktop.

However, I was not finished with this tablet. The 1 GB of onboard RAM made Windows painfully slow to use, as the CPU was constantly bogged down performing memory compression/decompression. The 32GB of eMMC storage I initially installed began feeling cramped, so I moved to a roomier 64GB (then 128GB) eMMC.

I won’t go into the details of how I upgraded the RAM in this post, as it’s a long story; simply put, soldering the RAM ICs was the easy part.

eMMC Adventures, Episode 1: Building my own 64GB memory card with a $6 eMMC chip

Posted on October 28, 2016 by ginbot86

As seen on Hackaday!

There’s always some electronics topic that I end up focusing all my efforts on (at least for a certain time), and that topic is now eMMC NAND Flash memory.

Overview

eMMC (sometimes shown as e.MMC or e-MMC) stands for Embedded MultiMediaCard; some manufacturers create their own name like SanDisk’s iNAND or Hynix’s e-NAND. It’s a very common form of Flash storage in smartphones and tablets, even lower-end laptops. The newer versions of the eMMC standard (4.5, 5.0 and 5.1) have placed greater emphasis on random small-block I/O (IOPS, or Input/Output operations per second; eMMC devices can now provide SSD-like performance (>10 MB/s 4KB read/write) without the higher cost and power consumption of a full SATA- or PCIe-based SSD.

MMC and eMMC storage is closely related to the SD card standard everyone knows today. In fact, SD hosts will often be able to use MMC devices without modification (electrically, they are the same, but software-wise SD has a slightly different feature set; for example SD cards have CPRM copy protection but lack the MMC’s TRIM and Secure Erase commands. The “e” in eMMC refers to the fact that the memory is a BGA chip directly soldered (embedded) to the motherboard (this also prevents it from being easily upgraded without the proper tools and know-how.

When browsing online for some eMMC chips to test out, I found a seller that had was selling 64 GB eMMC modules for $6 Canadian per pop; this comes out to a very nice 9.375 cents per gigabyte (that’s HDD-level pricing right there!). With that in mind, I decided to buy a couple modules and see what I could do with them. A few days later, they arrived in the mail (and the seller was nice enough to send three modules instead of just two; the third module’s solder balls were flattened for some reason).

Toshiba eMMC Module

Toshiba THGBM4G9D8GBAII eMMC 4.41 modules

The Flash memory I used is a Toshiba THGBM4G9D8GBAII. According to a Toshiba NAND part number decoder:

TH: Toshiba NAND
G: Packaged as IC
B: Vcc (Flash power supply) = 3.3 V, VccQ (controller/interface power supply) = 1.8 or 3.3 V
M: eMMC device
4: Controller revision 4
G9: 64 GB
D: MLC NAND Flash
8: Eight stacked dice (eight 8 GB chips)
G: 24nm A-type Flash (appears to indicate Toggle Mode interface NAND)
BA: Lead-free and halogen-free
I: Industrial temperature grade (-40 to 85 degrees Celsius)
I: 14 x 18 x 1.2 mm BGA package with OSP (Organic Solderability Preservatives)

Given the low, low price of the eMMC chip, I had to make sure that I wasn’t given counterfeit Flash memory (often fake flash would have only 4 or 8 actual GB usable, with most of the address space looping over itself, causing data loss with extended usage). This involved find a way to temporarily connect the eMMC to my computer. I had a USB 2.0 SD/MMC reader on hand as well as a laptop with a native SD host interface, so now all I needed to do was break out the eMMC signals on the BGA package so that I can connect it to the reader.

eMMC Pinout… or is it Ball-Out?

There are plenty of pinouts for eMMC on the Internet, but they all show the pinout for a top view. Since I’m not soldering the eMMC to a PCB, I need to get a bottom view. I took a pinout diagram from a SMART Modular Technologies eMMC datasheet, rotated it to a landscape view, flipped it vertically, then flipped each row’s text in order to make it readable again. I then copy-pasted this into PowerPoint and traced out the package and ball pinouts. This allowed me to colour-code the different signal and power lines I’ll need to implement, including the data, clock, command and power lines. Curiously enough, one of the ground pins (VssQ, or controller/MMC I/O ground) was not a ground pin like the standard required; because of this, I decided to leave that pin open-circuit. Additionally, there were several pins that were not open-circuit, but did not have a known purpose either (these are probably used as test pads for the internal NAND Flash interface – perhaps they could be reused as raw NAND with the right controller, but the exact purpose of these pads will need to be reverse engineered).

Toshiba THGBM4G9D8GBAII eMMC pinout (solder balls facing up)

eMMC Reader: Take 1 (Failed!)

For the first reader, I cut open a microSD-to-SD adapter, exposing the eight pins inside. I soldered a cut-up UDMA IDE cable and glued them in place. Despite my careful work, I still melted a hole through the thin plastic shell of the adapter; thankfully this did not affect the adapter’s ability to be plugged in.

I used double-sided foam adhesive tape and a piece of perfboard to create a small “test bed” for the eMMC module. Using some flux, solder wick, and a larger soldering iron tip, I removed all the (lead-free) solder balls on the center of the IC and replaced them with leaded solder bumps to make soldering the tiny 40-gauge magnet wire easier.

After bringing out the minimum wires required (VCC/VCCQ, GND, CLK, CMD, and DAT0 for 1-bit operation), I soldered the wires of my quick SD adapter, and plugged it into the SD card slot of a (very old) Dell Inspiron 9300.

: eMMC to SD adapter board, first attempt

: First attempt of eMMC adapter plugged into laptop

Calling this board’s operation flaky doesn’t do it justice. It would fail to enumerate 9 out of 10 times, and if I even tried to do anything more than read the device capacity, the reader would hang or the eMMC would drop off the SD/MMC bus and show an empty drive in Windows. It was clear I had to do a full memory card “build” before I could verify the usability of the eMMC Flash memory.

eMMC in an SD Card’s Body: Take 1 (Success… half of the time)

I had a 16 MB (yes, megabyte) SD card lying around somewhere, but as usual, I couldn’t find it among all the clutter around my desk and workspace. Instead, I found an old, slow Kingston 2 GB SD card that I felt would be a worthy “sacrifice” since it was an older type that still had a thin PCB inside (most SD cards nowadays are monolithic, which means it’s one solid chunk with a few pads exposed). After opening up the case carefully with an Exacto knife, I wiggled out the old PCB. I desoldered the orignal 2 GB NAND Flash, and began work on breaking the SD card controller from the PCB as it was a chip-on-board design. It took a while, but I was able to ensure that none of the old SD card hardware would interfere with my rebuild.

: SD card board with original Flash. Ironically we’re replacing Toshiba NAND with Toshiba eMMC.

: eMMC attached and soldered to SD card PCB.

I removed the eMMC from the board I made previously, and tested the thickness of it to ensure that it would fit inside the SD card case. It did, although the 0402 surface-mount decoupling capacitors I intended to install would cause a few bumps to be visible through the thin plastic SD card casing.

With my eMMC and SD card pinouts on hand, I used a small bead of epoxy to affix the eMMC to the PCB, balls-side up. I used magnet wire to connect the data lines (4 wires for 4-bit operation which is the maximum that the SD standard supports), and used the unused pads on the eMMC as a kind of prototyping space where I could install ceramic capacitors as close to the module as possible. I used a 0.1 µF 0402 size ceramic capacitor across the VDDi (eMMC internal regulator) and a neighouring GND pad. The rest of the power pads were wired in parallel with a few extra 0.1 µF capacitors added. I made use of the existing three 1 µF capacitors on the PCB as both extra decoupling and connection points for VCC and VCCQ. To prevent shorting of the inner CMD and CLK pins, I only removed the enamel coating from the magnet wire at the very end so I could solder them but avoid the issue of shorting those pins against the other signal and power lines. I then soldered these wires to the terminals on the other side of the PCB.

After spending about ten minutes wriggling the PCB into the SD card casing without damaging the wires, I used a multimeter to ensure all the pins were connected (use a multimeter in diode mode, with the positive lead connected to ground – any valid pins should read ~0.5 volts), and also ensured that there were no polarity reversals or shorts on the power pins.

Now… the moment of truth. At this point my USB 2.0 card reader still wasn’t cooperating with me, so I tried the only other ‘fast’ reader I had at the time – an SD to CompactFlash adapter.

: eMMC in SD-to-CF adapter visible

: eMMC MBR

To my relief, I finally got a (mostly) usable card. It appears this particular model has been pre-formatted with FAT32. Viewing the MBR in Hard Disk Sentinel shows nothing notable, apart from the fact that it’s pretty blank and is indicative that it wasn’t formatted for use as a PC boot medium.

Things began to fall apart after I tried running speed tests, as the card would hang if it experienced a lot of write activity at once. I suspected this was a power supply-related issue, so I modified my layout to add more capacitance. For good measure, I added 56 ohm termination resistance for the DAT0-4 data lines, using a small resistor network harvested from an old dead MacBook motherboard.

After these modifications, performance was much, much better. Now that the card was usable, I could finally run some speed tests.

eMMC in an SD Card’s Body – This time, with more feeling decoupling!

After adding several 100 nF and 1uF 0402-size ceramic capacitors on the eMMC package, I was able to get a stable card that could be read by (most) SD card readers. As I was rather anxious to get a decent benchmark from the eMMC, I decided to forego the cheaper Amazon Prime route, and go to my local PC parts store to buy a USB 3.0 card reader – the Kingston FCR-HS4.

After placing the eMMC and SD card PCB back into its plastic casing, I was relieved to see that Windows immediately recognized its presence. All I had to do then was open CrystalDiskMark and run the benchmark. Drum roll please…

Toshiba THGBM4G9D8GBAII/064G4A benchmark in CrystalDiskMark

Although I was happy to get a usable benchmark score, my belief that all eMMC devices inherently had better 4K random I/O speeds than their SD counterparts was immediately busted. My guess is that random I/O wasn’t considered to be a priority until eMMC 4.5 or 5.0, and my eMMC modules are only version 4.41.

eMMC module listed as version 4.41

After the speed test, I ran the card through the popular Flash memory testing tool h2testw to make sure that I was not given a counterfeit device.

H2testw showing flash memory is good

Excellent – it’s a genuine device. Despite the slower performance than expected, I’m happy that the memory capacity is as it should be.

“eMMC identification and CSD data, please”

As is the case with any USB memory card reader, I cannot access any of the eMMC device information (that is, the CID/Card Information Data and CSD/Card Specific Data registers). I took a spare SSD from my collection and got a quick Windows 10 installation running on one of my laptops that had a native SD host interface.

eMMC identified as Toshiba 064G4A MMC

Interesting. The eMMC identifies itself as a Toshiba 064G4A MMC card. Googling that information brought up literally zero information, so it appears I’m the only one to have found (or published) any information about it. Although eMMCs support some degree of S.M.A.R.T. health reporting like mainstream SSDs and HDDs, no (easily-available) software (for Windows at least) is available to read it.

Linux has the ability to report the CID and CSD data as long as the native SD host interface is used, as opposed to a USB card reader.

CID: 11010030363447344100151344014e00
CSD: d00e00320f5903ffffffffef96400000
date: 04/2011
enhanced_area_offset: 18446744073709551594
erase_size: 8388608
fwrev: 0x0
hwrev: 0x0
manfid: 0x000011
oemid: 0x0100
preferred_erase_size: 8388608
prv: 0x0
raw_rpmb_size_mult: 0x2
rel_sectors: 0x10
serial: 0x15134401

With the help of Gough Lui’s CID and CSD decoders, I was able to gain some more information about the eMMC device, but not too much as the information I was originally interested in was already collected by this point.

: eMMC CID decoded with Gough Lui’s online tool

Out of the Reader and Back Into the (CF) Adapter

Now that I know what the eMMC is capable of, I decided to try putting it back into my SD-to-CF adapter and doing another benchmark.

eMMC in FC-1307A SD-to-CF adapter. Note the limited performance of this chipset.

This test highlights one of the biggest limitations of the FC1306T/FC1307A chipset that so many adapters use: their performance is limited to a maximum of 25 MB/s per channel. Good thing I purchased that USB 3.0 reader…

Conclusion

This was quite the learning experience. I not only learned that eMMC flash memory does not necessarily have the near-SSD performance that the latest devices offer, but I learned how to “exploit” the unused pads of a BGA device as a sort of “prototype area” for soldering small components onto.

Did I save any money by rolling my own Flash storage device? Absolutely not – given how much time I spent on this, if I paid myself minimum wage ($12 per hour where I live), I could have bought at least three higher-performance 64GB SDXC cards with none of the frustration of trying to adapt an embedded memory device as a removable memory card. But where’s the fun in that? 🙂

Ramble: Fixstars’ 6TB SATA SSD – is it a thing?

Posted on May 13, 2015 by ginbot86

If you know me personally, you’ll know that I absolutely love SSDs. Every PC I own has one, and I can’t stand to use a computer that runs off an HDD anymore. Naturally, when I read about a 6 TERABYTE SSD coming out, it piqued my curiosity.

Photo is owned by Fixstars and is not my property. Retrieved from http://www.fixstars.com/en/news/wp-content/uploads/2015/05/SSD-6000M.png

Official SSD-6000M promotional photo, taken from Fixstars’ press release

A Japanese company by the name of Fixstar has recently announced the world’s first 6TB SATA-based SSD. Although 2.5″ SSDs in such a capacity range already exist, they’re SAS (Serial Attached SCSI) based which limits them primarily to server/datacenter usage. According to Fixstars’ press release, their SSD-6000M supports sequential read speeds of 540 MB/s, and sequential write speeds of 520 MB/s, which is on par with most modern SATA III (6 Gbps) SSDs on the market today.

Concerns

However, after reading a bit online, I’m beginning to have some concerns about the drive’s real-world performance. One thing that is rather worrying is that the company has only mentioned sequential I/O speeds and has said nothing on random I/O or read/write latency; although SSDs do have much better sequential speeds than their mechanical spinning counterparts, they really shine when it comes to random I/O (which makes up much of a computer’s typical day-to-day usage). In the early, early days of SSDs, manufacturers cared only about sequential I/O and it resulted in some SSDs that were absolutely terrible when it came to random I/O (fun fact: I once had an early SSD, the Patriot PS-100, and its performance was so bad that it actually turned me off of SSDs for a few years, so I know how bad such unoptimized SSDs can perform).

Construction

The SSD appears to be made up of 52 eMMC (embedded MultiMediaCard) chips in a sort of RAID 0 configuration and an FPGA (field-programmable gate array) as the main controller. In layman’s terms, this SSD is literally made up of a bunch of SD cards “strapped” together with a chip so that it appears as one single drive. In that sense, one can make a similar solution using a board like this, which parallels multiple microSD cards to act as a single ‘SSD’.

Image retrieved from Amazon (http://ecx.images-amazon.com/images/I/51y0QqWL5sL.jpg)

The consumer equivalent of the SSD-6000M: SD cards and a controller chip. You can even get them from Amazon.

Conclusion

I’m wary of how well this SSD is going to take off. It could end up being a tremendous success, but it’ll certainly be out of the reach of the consumer market – either by its potentially poor random I/O performance, or its price (apparently it will cost well over $6000 USD).

Review of SanDisk Extreme CompactFlash 32GB (SDCFXS-032G)

Posted on May 2, 2015 by ginbot86

After my previous review of a Silicon Power 8GB CompactFlash memory card, I was looking around for more CF cards to review, in the hopes of finding a higher-performing card with S.M.A.R.T. health reporting and the ability of acting as a “fixed disk” (that is, identifying to the system as a hard drive rather than a removable disk), and decided to purchase this memory card from Amazon.

: Front of card

: Back of card with pins visible

: Additional serial number on edge of card

Advertised specifications

The card’s specifications indicate that the CompactFlash card is capable of 120MB/s sequential read and 60MB/s sequential write speeds, has a lifetime warranty and comes with a license key for a 1-year subscription to their RescuePRO data recovery software. It is advertised to have internal RTV (room-temperature vulcanization) silicone potting, has an operational temperature range of -25 to 85 degrees Celsius (-13 to 185 Fahrenheit), and uses their “ESP (Enhanced Super-Parallel) Technology” which I presume is some sort of proprietary multi-channel controller, and is UDMA 7 (167 MB/s maximum interface speed) capable.

Benchmark – Setup

To connect the card to my computer, I used a CompactFlash-to-IDE converter and a Marvell 88SE9128-based SATA/PATA host bus adapter. This allows me to use up to UDMA 6 (133 MB/s maximum interface speed) as UDMA 7 is basically restricted to cameras as it’s only part of the CompactFlash official specifications.

Benchmark – CrystalDiskMark

For this test, I manually zero-filled the card using Hard Disk Sentinel, formatted it with exFAT, then ran CrystalDiskMark, set to 3 runs with a 500MB file size using random data, all zeros (0x00), and all ones (0xFF).

: CDM benchmark (random data)

: CDM benchmark (0-fill)

: CDM benchmark (1-fill)

Data Type	Test	Read (MB/s)	Write (MB/s)	IOPS Read	IOPS Write
Random	Sequential	103.2	52.45
	512K Random	99.55	29.57
	4K Random (QD1)	11.37	0.916	2775.2	223.6
	4K Random (QD32)	17.24	1.413	4208.2	344.9
All 0 (0x00)	Sequential	104.3	54.25
	512K Random	98.27	31.22
	4K Random (QD1)	11.36	1.1	2773.3	268.5
	4K Random (QD32)	17.39	1.263	4244.5	308.4
All 1 (0xFF)	Sequential	104.5	53.95
	512K Random	98.05	25.84
	4K Random (QD1)	11.19	1.112	2733	271.4
	4K Random (QD32)	17.32	1.437	4229.3	351

It appears that there is no significant difference between the tests depending on what data was used for the benchmark.

Benchmark – AS SSD

As with CrystalDiskMark, I zeroed out the card and formatted it as exFAT before running the test.

: AS SSD benchmark

Test	Read	Write
Sequential	99.70 MB/s	46.13 MB/s
4K	11.40 MB/s	0.74 MB/s
4K 64 Thread	12.80 MB/s	1.03 MB/s
Access Time	0.389 ms	5.504 ms
Score	34	6
Score	61

Benchmark – Hard Disk Sentinel

I ran three separate benchmarks with Hard Disk Sentinel’s Surface Test feature, using the read and write (both empty and random data) tests, and used the Random Seek Test to measure the card’s responsiveness after filling it with empty and random data.

: HDS read 0x00

: HDS read 0x00

: HDS write 0x00

: HDS write 0x00

: HDS read random

: HDS read random

: HDS write random

: HDS write random

: HDS seek 0x00

: HDS seek random

Test	Speed
Read 0x00	95.20 MB/s
Read Random	97.30 MB/s
Write 0x00	49.81 MB/s
Write Random	49.04 MB/s
Seek Time 0x00	0.35 ms
Seek Time Random	0.37 ms

Once again, there does not appear to be any appreciable difference between an empty (zeroed-out) or full card.

Analysis – HWiNFO64

Now that the benchmarks are out of the way, let’s take a look at the card and what it can (and can’t) do. Let’s take a look at the details of the drive…

: HWiNFO64 overview

: List of “available” features

The card shows up as a regular IDE drive in HWiNFO, and has information about its CHS (Cylinder-Head-Sector) geometries and supported I/O interface speeds. Here we can see the card supports up to UDMA 7 but is running at UDMA 6 as because it is connected to a PC IDE bus.

Now for the kicker: Does the drive identify itself as a fixed or removable disk? Cross your fingers…

: Removable Drive flag set

NOPE! The SanDisk Extreme CompactFlash card does NOT identify as a fixed disk, but instead as a removable drive. This means that the hopes of using this as a bootable Windows disk are now out the window. [ba-dum-tssh!]

Analysis – Hard Disk Sentinel

Looking at the Overview tab in HDS, something weird is happening. It states that “the hard disk status is PERFECT” yet it has no health or performance percentages available. If I open the Information tab, I can see that the SanDisk Extreme CompactFlash card does NOT support S.M.A.R.T. health reporting. Bummer. Additionally, it appears that Windows does not like removable IDE drives that lack S.M.A.R.T. and instead report garbage data (or data mirrored from another drive in the system).

Looking further inside the Information tab, we can see the features that the memory card does support. It supports DMA, Ultra DMA, APM (advanced power management), write caching, 48-bit LBA (logical block address) addressing, IORDY (flow control), a NOP (no-operation) command, and has the CFA (CompactFlash Association) feature set.

: HDS overview

: HDS info 1/3

: HDS info 2/3

: HDS info 3/3 (S.M.A.R.T. unavailable)

: Erroneous S.M.A.R.T. data mirrored from another drive

: Similar issue in S.M.A.R.T. log

: Similar issue with temperature

Since the card reported that it supported APM, I tried to enable it but the card refused to accept the command.

: APM dialog in Hard Disk Sentinel

: Card refuses to enable APM

Conclusion

Overall, I like this card quite a bit. It has fast sequential I/O and a respectable random read speed. However, this is soiled by the fact that the card is configured to show up as a removable disk, which renders the card unusable as a Windows boot drive, and the lack of S.M.A.R.T. health and temperature reporting makes me a bit uneasy as I cannot track the card’s program-erase cycle count during use.

Oh well. Looks like the hunt for a fast, fixed-disk CompactFlash card continues…

Teardown/review of Silicon Power 8GB 200x CompactFlash memory card

Posted on February 1, 2015 by ginbot86

Hooray for nice hand-me-down SLR cameras! I finally have a better camera than the one built into my (now ancient) Samsung Galaxy S II that I use for pictures on this blog. The camera, a Canon EOS 50D, had an 8GB CompactFlash card that I was preparing to erase and reuse, and had problems trying to read out the card’s contents; a few stubborn files would refuse to copy and Explorer would simply hang until I restarted the program or unplugged the card. Additionally, when using my Hard Disk Sentinel program to do a surface scan, it too would freeze when reading a certain sector on the card.

: Top of card

: Bottom of card

: Close-up of card’s pins

Instead of using a USB-to-CompactFlash adapter (I could not find my card reader and have not seen it for over a year now, come to think of it) I used a CompactFlash-to-PATA adapter, then a PATA-to-SATA adapter so I could directly hook up the card to my computer. In addition to having greater theoretical throughput, it allows me to view the S.M.A.R.T. diagnostic data that the card provides.

: Silicon Power CF card in CF-to-PATA, then PATA-to-SATA adapter

Memory card issues and performance

: CF card’s entry in Hard Disk Sentinel

: Card’s S.M.A.R.T. data

: Phison PS3006 controller identified

The diagnostic information doesn’t really provide any insight into the health of the card; none of the S.M.A.R.T. attributes are listed as critical, and many of them are listed as vendor-specific. Oh well, at least it gave me some sort of information…

: HDS’ surface scan right before freezing up

: Some card sectors showing up unreadable

: Speed of card when writing with zeros

After finding a copy of the card’s contents on my home server (I seem to have previously backed up the card before the corruption occurred but didn’t recall doing so until I had raked through some of my archives), I decided I’d do a full card erase and see if it would cause the card to be usable again. I called up the Surface Test in Hard Disk Sentinel and used its surface-write tool to erase the user-accessible area of the card. A few blocks seemed to write dramatically slower than the rest and repeated write tests did not resolve their sluggishness; I call shenanigans with the memory card’s controller and its reluctance in reallocating problematic sectors…

: Silicon Power 8GB 200x CF card’s speeds in CrystalDiskMark

: HDS’ graph of card’s random-access time

The card itself isn’t very fast. The sequential I/O of the card is good enough for casual photography, but I would definitely not use this card in an embedded system that uses a CompactFlash as a sort of mini-SSD; even though it shows up in my system as a hard drive (non-removable), its random I/O is quite sluggish and its random write speed is worse than that of a standard hard disk drive.

Teardown

The card itself is a sandwich of aluminum plates, a plastic case and the PCB assembly that holds the controller, Flash memory and the CompactFlash connector. A hobby knife run under the aluminum plate was able to separate the plate from the plastic body; some glue and a couple clips were the only things holding the card together.

: Knife placed under plate

: Top plate removed; controller and memory visible

: Bottom plate removed; memory and unpopulated footprints visible

The card’s controller is a Phison PS3006, which sports a PCMCIA (and therefore CompactFlash) interface with True IDE (or plain PATA) support. It contains an 8051 microcontroller core with a few components to assist with interfacing with the Flash memory, such as a hardware ECC (error correction code) engine and a small amount of SRAM for a buffer.

The datasheet for the PS3006 doesn’t provide information on the S.M.A.R.T. attributes, nor does it indicate what type of Flash wear-leveling is provided. Given the controller’s limited computing capabilities, I’m thinking it uses a less-complex but less-reliable form of wear leveling, known as dynamic wear leveling (see Micron’s application note for more information). It’s less capable of dealing with memory wearout, but doesn’t require the computing overhead of static wear leveling (which proper SSD controllers use to keep performance up).

The memory is an Intel 29F32G08AAMD2 device, which is an asynchronous MLC NAND Flash memory chip. There are two installed on this card with another two footprints on the PCB being unpopulated, suggesting that the 16GB version of this card has all four footprints populated.

Conclusion

Given the simplicity of the card, I don’t really have much else to add about this card. Either way, it’s lost my trust with regards to holding my photos. I bought a NOS Disk 16GB CF card from Amazon as well as a SanDisk Extreme 32GB, and plan to use the latter to hold my photos, with the former mainly being a simple curiosity of the construction of a card from a lesser-known manufacturer. Hopefully those will also provide S.M.A.R.T. data, as I prefer Flash-based storage devices with some sort of S.M.A.R.T. data capability. (Is it an insatiable thirst for knowledge? A means of doing regular ‘check-ups’ on my storage device? Probably the latter, but maaayyyybe the former as well. 🙂 )

A Little Pick-Me-Up: Samsung 840 EVO SSD slowdowns, and how to fix it (for now…)

Posted on October 4, 2014 by ginbot86

There’s been word going around that Samsung’s 840 EVO solid-state drives have an issue where they become really, really slow to read if the data on it has been sitting around for a few months, and I can confirm this is the case as well.

: Hard Disk Sentinel reading out data. Dark green squares indicate slow data transfer.

: Graph of read speeds on the SSD.

The first half of the drive (which holds a fair amount of static data) was being read at around 30 MB/s, with newer data being read at almost 500 MB/s. That’s a pretty big difference. One thing to note (I didn’t take a screenshot for this) is that although the overall read speed was significantly affected, the read latency was only somewhat slower; only about 10-20 microseconds of extra latency.

To temporarily fix this (at least until Samsung releases a firmware update in the middle of October), I used Hard Disk Sentinel to read and rewrite all of the data on the SSD. Because this involves accessing data that is normally locked by Windows, I made a custom WinPE (a slimmed-down, portable version of Windows that’s used for installation and recovery) image with Hard Disk Sentinel inside it. This allowed me to boot outside of the normal Windows setup, and perform the Read+Write+Read test to refresh all of the data stored on the SSD. Note that this will impart a lot of write activity to the NAND flash in the SSD (hence a chance for increasing wear), but modern SSDs aren’t as delicate as people might think.

Hard Disk Sentinel’s “Refresh Data Area” test

This took about 2 hours on my 250 GB SSD. Afterwards, another read test showed that the drive was working smoothly again.

Will I still buy a Samsung SSD? Absolutely. No data was lost and Samsung did the right thing by acknowledging the issue and also finding a way to fix it, as opposed to simply calling it a non-issue and sweeping it under the rug.

(Part 2 of 2) Microdrive Adventures: Looking into (and butchering) the Hitachi Microdrive and Seagate ST1 CompactFlash hard drives

Posted on May 3, 2014 by ginbot86

(Part 1 viewable here)

Content advisory: electronics gore! 😀

I sent screenshots from Hard Disk Sentinel to the seller of the microdrives, and they refunded my money but didn’t want the drives back. Even then, it’d probably be a good idea to destroy the drives since re-use of them would be a bit… fraudulent after getting refunded. I decided to throw the drives around to see how well they’d hold up to physical abuse.

The Microdrive died when I whipped it against the concrete floor of my basement, go figure. The impact was strong enough to bend the steel frame but not enough to shatter the glass hard disk inside. Obviously, the disk didn’t spin up or enumerate in Hard Disk Sentinel. Now that the drive’s murder has been accomplished, it’s autopsy time!

: Circuit board exposed

: Microdrive opened

: Other end visible

: Read/write head preamp

: It’s a 1-inch disk alright…

: … and only .4 mm thick!

: I think this drive needs some defragmenting…

The Seagate ST1 was put through a similar treatment, but it died much less gracefully when plugged in. The main controller chip (I think) shorted internally, and after about 15 seconds of being powered up, it released the magic smoke. The board’s plastic liner was melted where the chip shorted out. The drive internals weren’t much different than the Hitachi drives so I didn’t bother taking pictures of the drive’s insides.

: Plastic liner melted

: Liner removed – note chip-on-board construction

: Epoxy packages removed, chip areas visible

: Protective cover (label) removed

: Hard disk magnet on backing

After the damage was done, the drives were promptly put in a small plastic bag to be put in an electronics recycle bin.

(Part 1 of 2) Microdrive Adventures: Looking into (and butchering) the Hitachi Microdrive and Seagate ST1 CompactFlash hard drives

Posted on April 15, 2014 by ginbot86

A few weeks ago I decided to hop onto eBay and buy a couple microdrives for fun. If you haven’t heard of the term, a microdrive is a hard disk drive that fits into a CompactFlash slot. These were intended to be the future in mobile storage, with 20 GB drives being the biggest around 2006. Of course, these drives proved to be very delicate, and besides, now we get 128 GB microSD cards!

The drives I purchased appeared to be pulled from some old iPod minis. The seller tried to remove the Apple logo with some sort of solvent, but left the smudges behind.

: Seagate ST1 4 GB

: ST1 back labeling – note the smudged-out Apple logo on the left of the card

: The Hitachi 4 GB Microdrive

: Microdrive back labeling – note the smudged-out Apple logo on the top right… all that’s left is the (R) symbol

The problem with the iPod mini drives is that their CompactFlash interface is disabled. That is, the drive is really just a PATA drive in a CompactFlash’s body. Few devices that aren’t PCs support CompactFlash cards in this mode.

: Seagate ST1 in Sony Clie

Being the curious type, I popped the drives into my Sony Clie NX73V, which I still carry with me even though it’s 11 years old 🙂 . It has support for CompactFlash Type I and II (thin and thick, basically), and, according to the properties window in the OS, uses the ATA protocol to talk to the cards. This means it should interface with the cards just fine… right?

: … nope! No dice with the ST1.

: It enumerates at least…

: … ish.

First, I popped the Hitachi Microdrive in my Clie. One second after inserting the card, I see a question mark in the memory card’s taskbar icon. No dice.

Then, I moved on to the Seagate ST1. It spun up, but the Clie hung for about 30 seconds before finally displaying “The card cannot be recognized”. However, it did at least enumerate with the OS and I could pull up the manufacturer and model number of the drive.

Hm, well those ideas were dashed pretty quickly. Later, I bought a CompactFlash-to-PATA adapter, and a PATA-to-SATA adapter so I could hook it up to my laptop. From there, I used Hard Disk Sentinel (great software, by the way!) to analyze the drives and see if they have S.M.A.R.T. health reporting…

: Screenshot of Hitachi Microdrive

: S.M.A.R.T. data for Microdrive – note that Reallocated Sectors Count has a red X on it…

: HDS screenshot of Seagate ST1

: S.M.A.R.T. attributes for ST1 – note Seek Error Rate has a red X on it…

… and they do, alright! In fact, the drives I purchased were both soon to be dead. The Seagate drive had hundreds of bad sectors and a failing disk head/head actuator. The Hitachi drives had so many reallocated sectors that the drive literally ran out of spares. Too bad the Microdrive didn’t report how many sectors were reallocated though…

The drives themselves were in really bad shape, as seen below:

: Microdrive’s surface scan. Red blocks here mean that the disk had no spare sectors to replace them. Dark green means that the access time was rrrreeeealllllyyyy sloooooow…

: ST1’s surface scan. Yellow blocks indicate bad sectors were reallocated.

In the next part, I’ll show the aftermath of both drives. (Content Advisory: electronics gore)

The Help Desk That Couldn’t

Anatomy of an SD Card

Crouching Controller, Hidden Test Pads

Building the Breakout Board

Bus Analysis

Test Pad Pinout

Bus Sniffing & NAND I/O 101 (writing commands, address, reading data)

NAND Flash ID

External Control

JEDEC Parameter Page… or at least what SanDisk made of it!

Reset Quirks

Conclusion

Downloads

Share this:

Like this:

Test Pads & Signals

Command Analysis

T=0 Smart Card Command (APDU) Structure

VERIFY PIN Command Decoding

PIN Testing & Unlocking

Conclusion

Share this:

Like this:

Unboxing

Endurance Rating

Card Information

Initial Formatting

Performance

CrystalDiskMark

ATTO Disk Benchmark

Hard Disk Sentinel

Random Seek Test

Full Surface Read (or at least an attempt)

Share this:

Like this:

Triage

Troubleshooting & Diagnosis

Power Supply

LCD & Backlight

Power Management

FireWire

Thunderbolt

USB Port

Hard Drive Cable

Repairs

DC Input Jack

LCD Connector

USB Port

Current-Sense Amplifier

DC Input Voltage Divider Switch

LED Backlight Driver

FireWire Late-VG Protection Circuit

Testing

Conclusion

Right to Repair

Share this:

Like this:

A Closer Look

Card Identification

Performance

CrystalDiskMark

Conclusion

Share this:

Like this:

Filling in the Blanks

Conclusion

Share this:

Like this:

Overview of HP 14-am/14-an Series SSD Module

The BayHub OZ788WR2 Bridge Chip

Step 1: Pinout Discovery

Step 2: Building the Adapter (Take 1)

Step 3: Building a Dedicated eMMC SSD (the teaser!)

Step 4: Building the Adapter (again!)

Conclusion

Share this:

Like this:

Retrieving an older version of Google Chrome’s data folder

Browsing the LevelDB database

Share this: