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

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

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 (I’m not sure what A-type means)
  • 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: Your Balls (Aren’t) Showing

(There is no real way to word a subtitle about BGA solder balls that can’t be interpreted in a… dirtier manner. Moving on…)

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 (I suspect these were factory test/programming points for the eMMC controller).

Toshiba THGBM4G9D8GBAII eMMC pinout (solder balls facing up)

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.

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.

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.

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

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

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

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

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.

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.

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? 🙂

Advertisements

HDQ Utility version 0.96 now available!

Whew, I’ve been working on this version for quite a while. With the helpful feedback of many people that have tried my software, I’ve made a large number of improvements to the software; of course, there are plenty of features that aren’t implemented yet, but are being worked on.

More information about how this utility works can be found here.

Download HDQ Utility v0.96 here: https://www.dropbox.com/s/pf0vszgfei7s8ly/HDQ%20Utility%200.96.zip?dl=0

Updates

  • (Major improvement!) Improved HDQ logging functionality (logs are now saved to a separate file instead of being overwritten).
    • Example: “HDQ Log (2015-10-26 at 19.02.50) – HDQ Utility v0.96.txt”
  • Improved HDQ communication (HDQ breaks no longer require the serial port to be opened more than once, and HDQ no-response timeouts are decreased from 0.5 to 0.3 seconds.
  • Reworded certain error messages for clarity.
    • Example: “Communication error: Cannot read byte from address 0x02 (No response from device).” 
  • Renamed file ‘config.txt’ to ‘Config – COM Port.txt’ for clarity.
  • Improved state-of-health warnings by making them non-modal (they do not require the user to dismiss the message).
  • Added more notifications for unidentified and uninitialized batteries. (Uninitialized batteries are determined by a FULL ACCESS security state, with Impedance Track disabled.)
  • Fixed invalid device name and maximum load current readings for v5.02/sn27545-A4 based batteries (e.g. iPhone 6, 6+…).
  • Added time-to-full readings (for firmware older than v2.24).
  • Improved error-checking for device identification (it will display a notice that the tool may need to be restarted).
  • Updated DingoLib UI library to auto-resize window to 0.9x display resolution for improved readability on larger monitors.

To-Do

  • Create a dedicated section on my blog for the HDQ Utility.
  • Create a user’s manual describing the parameters displayed by the program (in particular, the Advanced Battery Information section).
  • Improve data logging functionality by saving logs to a subdirectory instead of the program’s root to decrease file clutter.
  • Improve error-checking for commands (retry reads if one or more bytes are not received from the device).
  • Add error statistics indicating how many communication errors occurred during data collection.
  • Improve support for older (older than v1.25) firmware.
  • Improve support for v5.02/sn27545-A4 devices (make use of advanced commands available in this firmware version).
  • Add support for restarting of data collection without having to re-execute the program.
  • Add Data Flash memory functions to allow for readout of advanced configuration, serial number, lifetime/black-box data, etc.
  • Rewrite this program in something that’s not LabWindows/CVI… also, use of a GUI rather than a non-console text UI.

Reading out HDQ-equipped battery fuel gauges with a serial port

Battery fuel gauges are the unsung hero of the battery world. There’s more to it than just measuring the voltage on the battery terminals,. These little chips are microcontrollers (tiny computers, essentially) that sit inside the battery pack and keep tabs on the battery’s performance for the life of that battery pack.

Texas Instruments makes battery fuel gauges that are small enough to fit in the circuitry of a cell phone, and one of the most common ones that uses this technology are iPhone batteries. These batteries use a single-wire interface called HDQ (which stands for High-Speed Data Queue). It may sound similar to Dallas Semiconductors’ 1-Wire protocol, but the two are completely different and incompatible with each other.

Protocol details

The HDQ protocol can be emulated with a serial port and a little bit of external circuitry. The protocol can be emulated with a serial port at 57600 baud with 8 data bits, no parity bit and 2 stop bits. Because this is a bi-directional bus, an open-drain configuration is needed. Most TTL serial ports are not open-drain, so some circuitry is required to do this. TI’s application note suggests using a CMOS inverter and an N-channel MOSFET along with a 1 kOhm pull-up resistor, but this can be cut down with a 74HC07 open-drain buffer and pull-up resistor.

[EDIT: June 13, 2015 – Corrected schematic]

The HDQ protocol uses a short pulse to indicate a logic 1, with a longer pulse to indicate a logic 0. The data is sent LSB (least significant byte) first, with a 7-bit address and an eighth bit to indicate if the operation is a read or write (0 is read, 1 is write). If it is a read operation, the fuel gauge will respond with one byte of data. As you might think, this is a very slow means of communication; the typical bus speed is 5-7 kilobits per second, but the actual usable throughput will be less than this.

The hack in this is that the bit timing can be made by sending a specially crafted UART byte that meets the timing specifications. Each bit takes up one byte of UART buffer memory, with 24 bytes being enough to perform an HDQ read (the first 8 bytes are echoed back to the PC and need to be ignored by the software). TI’s application note goes into this with a bit more detail.

Windows HDQ utility

HDQ utility icon, in all its pixelated glory.

HDQ utility icon, in all its pixelated glory.

I have written a small Windows program that will read out the battery’s main data, identify as a certain iPhone battery model (most iPhone batteries are supported), and save a copy of this data to a text file for safekeeping. This program requires the National Instruments LabWindows/CVI Runtime library to run, since I whipped this program up with the first available IDE on my college PC.

fdd82eef8d

Screenshot of HDQ Utility version 0.96

The source code is not yet available (translation: I’m too ashamed of my programming skills to share it with others); however, a Windows executable is available for download below.

You will need to download the National Instruments LabWindows/CVI Runtime to run this program.

Current version (0.96): https://www.dropbox.com/s/pf0vszgfei7s8ly/HDQ%20Utility%200.96.zip?dl=0

Version 0.95: https://www.dropbox.com/s/7xdurbh9qibdftl/HDQ%20Utility%200.95.zip?dl=0
Version 0.9: https://www.dropbox.com/s/cd3esa5us6elfgr/HDQ%20Utility.zip?dl=0

Contributions are always accepted! Email me if you would like to send in a battery for me to analyze, or you can buy me a coffee through PayPal:


[EDIT – July 28, 2016] Welp, looks like the PayPal button’s broken (or was it never working to begin with…?). If you’d like to send anything to me, just give me a shout at ginbot86@gmail.com!

[EDIT – August 2, 2016] Whoops, looks like I never had the button working in the first place. Hopefully it works this time.

 

An Easy Hook-Up: Creating breakout Power/HDQ breakout boards for iPhone smart batteries

Now that I’ve been amassing a greater and greater arsenal of iPhone batteries, it’s gotten to the point that it makes most sense to create a connector board that can bring out the Pack+/Pack- pins alongside the HDQ data pin so I can view the gauge’s status in GaugeStudio.

Why use iPhone batteries in DIY projects?

The benefit of using iPhone batteries (note they must be for the iPhone 4 or newer; older ones will lack the fuel gauge) in microcontroller-based projects, is that the fuel gauge allows the microcontroller’s program to read out its current battery level, power consumption, capacity and time-to-empty; you also get the usual built-in protection circuit to safeguard against short-circuits, overcharge/overdischarge and overcurrents.

Additionally, iPhone replacement batteries are easy to find online or in cell phone repair shops, making them cheap and plentiful.

What is this “HDQ” that I keep talking about?

HDQ is a communication bus originally made by Benchmarq (now a part of TI). It stands for “High-Speed Data Queue”, and is a serial bus that transmits data over a single wire. This, however, is not to be confused  with Dallas Semiconductor’s 1-Wire protocol. The basic idea is the same but they are completely incompatible with each other.

Board construction

The board was made up of an iPhone surface-mount connector, a 4-pin connector for HDQ data transfer, a 2-pin male header, and a 2-terminal screw terminal. As with many of my prototype boards, wiring of the board is done with thin, flat solar cell tabbing wire. It’s flat, pre-tinned, and can handle high currents easily.

The benefits of this sort of board is that it allows:

  • Easy, removable connections to the battery; no need to solder to the battery terminals directly
  • Access to the HDQ data pins and power terminals
  • Real-time monitoring of battery State-of-Charge (%), current (mA), voltage (mV), capacity (mAh) and also the remaining time-to-empty (minutes).
  • Adaptability for different connectors (either by making a separate board for that connector or by creating a single “universal” board)
  • HDQ protocol can be used by a microcontroller via either bit-banging the protocol, or using an on-chip UART. (subject to a separate post in the future)

Although I could have created one large breakout with all the available connectors populated, I wanted to be able to use multiple batteries at once for powering different devices. Additionally, the HDQ bus has no support for addressing multiple devices.

The iPhone 4, 4S and 5 batteries have an additional NTC thermistor pin, but I have left them disconnected since I can read out the battery temperature over HDQ anyways.

Safety

Keep in mind that not all Li-Ion batteries have the same charging voltage. The iPhone 4 and 4S batteries use a 3.7 volt cell, charging at 4.2 volts; but the iPhone 5, 5S and 5C batteries are 3.8 volts, charging at 4.3 volts. 4.3 volt cells can charge at 4.2 volts with a capacity reduction of 5-10%, but 4.2 volt cells must not be hooked up to a 4.3 volt charger. There is overcharge protection built into the battery but it should not be relied upon for regular charging. Apart from the usual risk of the battery catching fire (or even just puffing up like a balloon), you also permanently decrease the battery’s capacity and dramatically increase its internal resistance, essentially crippling the battery for life.

A Temporary Hold: Creating Li-Ion battery holders with prototype boards and pin headers

As seen on Hackaday!

Lithium-ion batteries are great. They have high energy density, are lightweight, and in the case of many portable devices, they can be easily swapped in and out. One problem with prismatic (the types you often find on cell phones that have a set of flat contacts on one end of the battery) packs is that they’re all custom; the cell may be standardized but the pack it’s in is often proprietary to a certain make and model. Sure, there are “universal” holders out there, but they provide poor electrical contact at best. Since I need a secure electrical connection when using my battery fuel gauges, I sought to create a more sturdy holder for the batteries I have lying around.

The construction of the holder is pretty simple. A strip of female pin header (I used a single-pin-width header but a double-width one can be used for greater mechanical strength) is used as an end-stop for the battery, and a right-angle pin header is used to create contact with the battery’s terminals and to provide the physical “clamping” needed to create a good connection. The right-angle header can be bent and soldered into place to adjust the holder to the particular cell you’re using. Additionally, be sure to use some high-quality FR4-based boards as the brown-coloured paper/resin-based boards won’t have as good resilience and strength, and probably won’t be plated through either (this improves the structural integrity of the holder since the pin headers will be under a bit of physical stress).

For connections, I have a 2-pin header (physically a 3-pin header with one removed to denote polarity) and a set of screw terminals. These are wired up using a flat ribbon “wire” used to connect solar cells together as they can handle several amps and come pre-tinned with solder.

This sort of setup can be adapted to nearly any commercially available prismatic battery, provided it uses a flat contact area on the sides.

Using a laptop battery to power lighter-socket devices

Laptop batteries can be a rather handy source of power, even if it’s not being used in a laptop computer. I built an adapter that converts the knife-blade connector that a laptop battery uses to a car lighter socket.

2013-12-24 02.02.02The connections are made by taking the blades of an ATO or ATC (regular size) car fuse, soldering them to some 16-gauge speaker wire, then soldering the other end to an inexpensive DC lighter socket.

2013-12-24 02.05.39This setup is only good for roughly 5 amps (the overcurrent protection on this battery is set to 6 amps) and the voltage near the end of discharge can be too low for certain devices; power inverters will stop at about 10 to 11 volts which leaves a small amount of battery capacity unused.

Convenient chips but even more inconvenient packages – Fail, fail, fail and fail again: Trying to solder the TPA2011D1 speaker amplifier

I was doing some prototyping of the TI TPA2011D1 3 watt Class-D amplifier that’s in a 1.2 x 1.2 mm 9-ball BGA package. Unlike my tries with the bq27421, these chips are downright painful to solder. Out of 5 chips that I’ve tried to solder, only one of them actually worked. That’s a 20% success rate. Bummer. The only thing that’s preventing me from being any more angry about these chips is that my back and shoulders hurt quite a bit after hunching over to try and solder these bastards for a good 6 hours.

“Thumbs down!” –Dave Jones

2013-07-25 01.35.11