- Advertised capacity: 512GB
- Speed class markings: U1, V10
| Sample # | 1 | 2 | 3 | Average |
|---|---|---|---|---|
| Obtained from | AliExpress | AliExpress | AliExpress | N/A |
| Price paid | $14.26 | $13.46 | $14.44 | $14.05 |
| Manufacturer ID | 0x00 | Unknown | 0x56 | N/A |
| OEM ID | 0x0000 | Unknown | 0x5344 (ASCII: SD) | N/A |
| Product name | 0x4150505344 (ASCII: APPSD) | Unknown | 0x4150505344 (ASCII: APPSD) | N/A |
| Product revision | 0x00 | Unknown | 0x00 | N/A |
| Serial number | 0x12800003 | Unknown | 0x0000018a | N/A |
| Manufacture date | Mar 2023 | Unknown | Nov 2013 | N/A |
| Logical capacity | Unknown | 536,871,960,576 bytes | 536,871,960,576 bytes | 536,871,960,576 bytes |
| Physical capacity | Unknown | 31,596,637,696 bytes | 31,248,782,336 bytes | 31,422,710,016 bytes |
| Fake/skimpy flash | Unknown | Fake flash | Fake flash | N/A |
| Sequential read speed (MB/sec) | Unknown | 16.64 | 54.63 | 35.64 |
| Sequential write speed (MB/sec) | Unknown | 12.54 | 15.05 | 13.80 |
| Random read speed (IOPS/sec) | Unknown | 1,057.40 | 547.75 | 802.58 |
| Random write speed (IOPS/sec) | Unknown | 0.46 | Unknown | 0.46 |
| Read/write cycles to first error | 0 | 6 | 0 | 2 |
| Read/write cycles to complete failure | 0 | 164 | 0 | 55 |
| Total days to complete failure | 0 | 17 | 0 | 6 |
| Card reader used | N/A | Prograde Digital Dual-Slot Mobile Reader | JJS CR-UTC4AC | N/A |
| Package front |  |  |  | N/A |
| Package back |  |  |  | N/A |
| Card front |  |  |  | N/A |
| Card back |  |  |  | N/A |
Discussion
After deciding to test the Auotkn Extreme 8GB, I purchased a single 512GB card, as I was curious to see if I would find the same manufacturer selling genuine flash and fake flash.
At first, I thought sample #1 was dead on arrival. The card was completely unresponsive whenever I plugged it in. I wasn’t sure if these cards were defective by design or if I had simply received a bad card, but I decided to give it the benefit of the doubt and ordered another one — from a different seller.
Initially, sample #2 was also unresponsive. I was about ready to call it dead on arrival as well, but then I decided to try it with the Prograde reader — and it worked. Unfortunately, I couldn’t use the Prograde reader to read the registers from the card — I’m only able to do that with the Realtek reader — so I wasn’t able to read the CID data from this card.
As I started working on my FPGA design, however, I decided to try out card #1 to see what it would do when the FPGA tried to initialize it. At first, the FPGA complained that the card sent back a response with a bad CRC. I had my logic analyzer hooked up to it, so I decided to do a capture and look at the communications going between my card and the FPGA. This is the command and response where my FPGA was telling me the response had a bad CRC:
Next, I hooked up one of my working cards and captured the same transaction with that one as well:
If you don’t know what you’re looking at: the top row (the blue signal) is the clock signal that my FPGA is sending to the card. The bottom row (the green signal) is the “CMD” line — it’s a bidirectional line that the host uses to send commands to the card, and that the card uses to respond to those commands. Coding is NRZL (basically — a high level represents a 1, a low level represents a 0). In the screenshots, the command and response start at the green dot and end at the red dot.
So as I stared at these captures, I was confused: they looked identical to me. Was the Auotkn sending back voltage levels that were enough for my logic analyzer to detect, but not enough for my FPGA to detect? Was there something wrong with the way I was calculating CRCs? Did a random wire get disconnected from my breadboard?
Eventually I decided to enable the signal tap logic analyzer, which lets you essentially see the signals that the FPGA is seeing — it’s kind of a debugger for the FPGA. I set it to trigger at the point where my card starts to listen for the response from the card, and here’s what I got:
What you’re seeing in the screenshot above is the FPGA’s view of the signals going back and forth over the card’s CMD line. The “0” represents the point where it started listening for the reply.
And seeing this, I suddenly realized what the issue was. When the card sends a reply back to the host, it’s supposed to start it with 00 (the first bit is a “start” bit, and the other bit indicates the direction — 0 for card to host, and 1 for host to card). However, my FPGA took a few clock cycles to switch from “sending mode” to “receiving mode”, and it didn’t have a chance to switch over to “receiving mode” until after the card sent the first bit of its reply back. The card was simply replying back too quickly! I adjusted my design to let the FPGA start listening for the reply sooner — and whaddya know, it was able to communicate with the card successfully, and I was able to query it for its CID! The CID data I have shown above is what I obtained from this process. I haven’t gotten my FPGA design to the point where it can do performance tests, however…so that will have to wait for another day.
This discovery led me to wonder — did my other card readers have this same deficiency in their design? Were they simply not starting to listen for the card’s reply soon enough? As far as I can tell, the SD card specification doesn’t say how many clock cycles the card is supposed to wait before replying back to the host, so I imagine the engineers that designed these card reader ICs never had to specifically think about this issue. I imagine I’ll probably never know for sure.
As I haven’t been able to do performance testing with sample #1, I only have results from sample #2 — and I have to say, they were pretty unimpressive. Unsurprisingly, this card’s physical capacity was not 512GB; its actual capacity was closer to 32GB. The sequential read/write speeds were barely enough to qualify for the U1 and V10 markings that it carries. Additionally, this card only lasted a few read/write cycles before it began showing data mismatch errors; and when it started failing, it failed quickly. By the time the card reached 164 read/write cycles, over half of the sectors on the card had been flagged as bad due to data mismatches.
I do find it interesting to look at exactly what symptoms a card shows when it starts to fail. In this case, some sectors showed a number of bit flips; others simply read back as all ff‘s.
Here’s what the track record for this sample looks like:
As you can see, this sample’s endurance test went as follows:
- A few rounds of nothing (or practically nothing);
- A sudden jump to “halfway to the 50% failure threshold”;
- A slow rise in the number of bad sectors for about the next 150 read/write cycles;
- A sudden jump to “almost 50% of the sectors have failed”;
- And finally, the card becomes unresponsive.
I had to search around a bit for sample #3 — the original seller that I purchased the first two from no longer seemed to carry this card, and many of the other options I saw would have put me over my $15 budget. However, I eventually found one. When I started putting it through testing, however, it decided to self-destruct during performance testing — which is why I don’t have a random write score for this card.
My conclusion: don’t buy these cards. They’re absolute horse shit. They’re fake, and I haven’t had a single one of these that didn’t have issues right out of the package. Go spend your money on something like the Samsung PRO Endurance 32GB instead — you’ll pay about half as much for a much more reliable card.
June 1, 2024