Tag Archives: analysis

Review and analysis of XTAR 3600 mAh 18650 Li-Ion protected battery

Posted on by
5

TL;DR – Yes, the XTAR 3600 mAh protected 18650 battery meets its rated capacity! Just make sure your device can drain down to 2.5 volts.

The 18650 lithium-ion battery, named after its size (1.8 cm diameter and 6.50 cm length), has seen continuous improvements in capacity over the years. Nowadays it’s easy to get capacities in excess of 3000 mAh, with the highest capacity cells reaching and even exceeding 3500 mAh.

The XTAR 3600mAh protected 18650 lithium-ion battery, pictured with its original box.

The XTAR 3600 mAh protected 18650 lithium-ion battery, pictured with its original box.

Earlier this year, XTAR, a Chinese company specializing in batteries and battery accessories, announced the newest and highest-capacity addition to their protected 18650 lineup, boasting an impressive 3600 mAh capacity and aimed towards medium-drain applications like power banks and LED flashlights (sorry vapers, this one’s not for you!). After submitting my name for consideration, I was one of a few people selected to receive some samples for review; considering how much I’ve blogged about lithium-ion batteries on here, it only makes sense to talk even more about them!

FULL DISCLOSURE: XTAR provided these batteries to me at no charge for an independent review. They had no editorial control over this review, I have not been compensated monetarily, and all opinions expressed in this review are my own.

Introduction

XTAR’s new 3600 mAh protected 18650 comes in a discreet box, holding nothing more than the battery itself. Like all protected 18650s, the protection comes in the form of a small PCB (printed circuit board) that is stacked on the negative end of the bare 18650 cell, with a metal strap running up the cell’s body to the positive terminal, where a small “button top” is attached to improve electrical connectivity for spring-loaded battery holders.

Positive and negative terminals of the XTAR 3600mAh protected 18650 battery.

Positive and negative terminals of the XTAR 3600 mAh protected 18650 battery. Note the added length due to the button top on the left, and the protection circuit and protective plate on the right.

I was able to request an official datasheet for the battery, which I have included at the end of my blog post. My main goal with this review is to test the batteries from an objective perspective, using dedicated test equipment rather than in-application testing in devices like flashlights. If I do decide to perform such tests, I’ll add a second part to my review (stay tuned!).

Datasheet specifications

Parameter Value
Cell manufacturer (Unspecified)
Nominal voltage 3.6 V
Nominal capacity 3600 mAh
Minimum capacity 3500 mAh
Discharge cutoff voltage 2.5 V
Cycle life @ 80% capacity At least 300 times
(0.5C charge to 4.2 V, 0.03C taper; 0.5C discharge to 2.5 V)
Size 18.1~18.7 mm diameter
68.3~69.3 mm length
Weight ≤50 g
Internal AC resistance ≤45 mΩ
Standard charge CC 720 mA
CV 4.2 V
Taper 50 mA
Fast charge CC 2500 mA (0.7C)
CV 4.2 V
Taper 36 mA (0.01C)
Standard charge voltage 4.2 V
Standard discharge 720 mA CC to 2.5 V
Continuous discharge current >8.5 A
Overvoltage protection Trip 4.25~4.35 V
Recover 4.0~4.2 V
Undervoltage protection Trip 2.4~2.5 V
Recover 2.8~3.0 V
Overcurrent protection Trip 11~13 A
Working temperature Charging: 0~45 °C
Discharging -20~60 °C

Test 1: EBL TC-X Pro battery analyzer

Initial testing of the batteries was tested using my EBL TC-X Pro 4-bay battery analyzer. The test procedure for the batteries was performed as follows:

  1. Record out-of-box/initial voltage before charging
  2. Run automatic capacity test with programmed 1500 mA charge current to 4.2 V, and fixed 500 mA discharge to 2.75 V (charge -> discharge -> charge); record discharge capacity and reported internal resistance
  3. Run manual discharge test with fixed 500 mA current to 2.75 V; record discharge capacity and reported internal resistance
  4. Run manual charge with 1500 mA charge current to 3.65V/LiFePO4 mode (moderate voltage is best for long-term storage); record charge capacity
Parameter (charge current = 1.5A) Cell 1 (bay 1) Cell 2 (bay 2)
Initial voltage (V) 3.65 3.55
Capacity run 1 (mAh @ 2.75 V end of discharge) 3349 3369
Capacity run 2 (mAh @ 2.75 V end of discharge) 3334 3386
Internal resistance run 1 (mΩ) 54.9 46.9
Internal resistance run 2 (mΩ) 53.4 45.1
Storage capacity (mAh charged to 3.65 V) 1402 1494

The capacity numbers seemed a bit low to me, even for an incomplete discharge to 2.75 volts instead of 2.5 volts. I decided to continue testing with a more accurate (and calibratable) battery fuel gauge board, revealing the true capacity of this battery… and it’s as good as the manufacturer promised!

Test 2: Texas Instruments bq78z100 fuel gauge

After realizing that my dedicated battery analyzer wasn’t quite as accurate as I wanted, I decided to use a battery fuel gauge board that I had more confidence in. I had previously built a board based on the Texas Instruments bq78z100, a dedicated battery management system (BMS) on a chip, aimed at 1S and 2S battery packs. This allowed me to calibrate the voltage and current measurements against my Agilent/Keysight U1253B multimeter and therefore get the most accurate results, as I can also program the bq78z100’s autonomous protection features to provide precise control over the discharge cutoff voltage during testing.

Example of the bq78z100-based fuel gauge board being connected to the XTAR 3600mAh protected 18650 battery. (note: actual setup is different than as pictured)

XTAR 3600 mAh protected 18650 battery connected to the bq78z100-based fuel gauge board. (note: actual setup is different than as pictured)

Using this circuit, I was able to get multiple measurements of the battery’s capacity with the help of a Texas Instruments GDK (Gauge Development Kit) as a charger and adjustable load for some of the capacity tests; and an Arachnid Labs re:load 2 adjustable constant-current load, with some additional forced-air cooling for the higher discharge rates.

I suspect that if I had a more, erm, “professional” setup, I could extract even more capacity from the battery, as additional resistance between the battery and the fuel gauge board will cause a voltage drop and subsequent loss in measured capacity.

Available capacity vs. end-of-discharge voltage

This is one of the most interesting test results, in my opinion. Many 1S/”single-cell” devices can’t take full advantage of modern NMC (nickel-manganese-cobalt) cells whose end-of-discharge voltage is below 3 volts, and the following chart helps quantify how much capacity can be extracted if one stops earlier than that. One advantage of reducing the depth of discharge, however, is that it can extend the battery’s cycle life and reduce the amount of capacity loss it experiences with age. As long as you discharge all the way to 2.5 volts and at a modest rate, the XTAR 3600 mAh battery achieves its rated capacity, and then some!

Chart plotting the XTAR 3600mAh protected 18650's voltage, compared to discharge capacity and discharge rate.

XTAR 3600 mAh protected 18650’s voltage/capacity curves at various discharge rates. (click here for full-size chart)

Discharge Rate Capacity/DoD@ 3.3V
(Rel/Abs)		 Capacity/DoD @ 3.0V
(Rel/Abs)		 Capacity/DoD @ 2.75V
(Rel/Abs)		 Capacity/DoD @ 2.5V
(Rel/Abs)
C/10
(350 mA)		 2616 mAh
72.4%/72.4%		 3357 mAh
92.9%/92.9%		 3539 mAh
97.8%/97.8%		 3613 mAh
100%/100%
C/5
(720 mA)		 2555 mAh
(N/A)/70.7%		 3250 mAh
(N/A)/90.0%		 (No Data) (No Data)
C/2
(1800 mA)		 2310 mAh
67.2%/64.0%		 3076 mAh
89.4%/85.1%		 3338 mAh
97.1%/92.3%		 3438 mAh
100%/95.2%
1C
(3600 mA)		 1995 mAh
57.2%/55.2%		 2874 mAh
82.4%/79.5%		 3330 mAh
95.5%/92.2%		 3486 mAh
100%/96.5%

Note that “relative” and “absolute” percentages correspond to the 2.5 volt discharge values for each row and the C/10 rate, respectively. The curve for the C/5 discharge rate ends early, as that data was collected with my Texas Instruments GDK (Gauge Development Kit), which has a hardcoded discharge cutoff at 2.9 volts. One oddity of the 1C curve is how it actually gets slightly more capacity than the C/2 rate; I suspect this is because the internal resistance of the battery was decreasing due to cell heating, allowing the lithium ions to travel across the cell’s separator more easily. Additionally, the capacity under-reporting issue I was having with the EBL tester is more visible in this chart, since a rough extrapolation would bring the discharge curve at 500 mA around 3550 mAh, which is a fair amount higher than the measured ~3340 mAh. If I have the time to recollect some data, I’ll add it to the chart.

Thermal performance

I don’t have the equipment to test beyond a 1C discharge rate, but even at a C/2 discharge rate I noticed significant heating of the battery; nothing disconcerting but still noteworthy. At 1C, the temperature rose to just over 40 degrees Celsius (104 degrees Fahrenheit) by the end of the discharge cycle – definitely warm to the touch but not burning hot. However, I imagine that a discharge rate at 2C or even higher will result in battery temperatures exceeding 50 degrees Celsius (122 degrees Fahrenheit), hot enough to be uncomfortable to hold. Note that lithium-ion batteries should not be charged if they are warmer than 45 degrees Celsius (113 degrees Fahrenheit).

Chart plotting the XTAR 3600mAh protected 18650's temperature, compared to discharge capacity and discharge rate.

XTAR 3600 mAh protected 18650’s temperature curves at various discharge rates. (click here for full-size chart)

Chemistry analysis

After running the data taken at a C/10 discharge rate through TI’s online tool, GPCCHEM, I was able to get two chemistry IDs that would allow me to get an accurate model of the cells for use in their Impedance Track line of fuel gauges.

Chemistry ID (hex) Chemistry Description Cell match Max DoD error (%) Max Ra deviation ratio
5267 LiMn2O4 (Co,Ni)/carbon, 4.2 V Bak: N18650CP (3350 mAh) 2.3 0.27
5634 LiMn2O4 (Co,Ni)/carbon, 4.2 V NanoGraf: INR-18650-M38A (3800 mAh) 2.72 0.61

Don’t pay too much attention to the details; they are provided for informational purposes only and mainly of use for those that want to use these batteries with TI’s fuel gauge chips. The specific models listed are not a guarantee that these batteries actually are that cell model, but it does confirm that our data is otherwise trustworthy; both listed models are high-capacity cells and use a chemistry system containing nickel, manganese, and cobalt (NMC for short), and such chemistries tend to have a relatively high capacity at the expense of lower terminal voltage (3.6 V nominal, 2.5 V at end of discharge; versus the typical 3.7 V nominal and 3.0 V end of discharge).

Conclusion

After my testing, I can confidently say that XTAR’s 3600 mAh 18650 really does achieve its rated capacity. As long as your target device is capable of discharging to 2.5 volts and at a modest rate, it will be able to get the most out of this battery.

If you want to purchase this battery, you can do so from their online store: https://xtardirect.com/products/18650-3600mah-battery?VariantsId=10393

At the time of writing, XTAR is selling this battery at $11.90 USD for a single battery, or $23.80 USD for a two-pack with carrying case.

Downloads

The datasheet for the battery can be found here: https://www.dropbox.com/s/wibdm2ty6zfa7xo/XTAR%2018650%203600mAh%20Specification.pdf?dl=1

Advertisement

Reverse-engineering and analysis of SanDisk High Endurance microSDXC card

Posted on by
32

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.

SD Card Anatomy

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.

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.

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.

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.

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.

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: