Hacking Hardware Homebrew Should I be worried about my Wii U eMMC corrupting? What steps can I take to prevent the issue (if there are any)?

[RyanXx]

Alright, so I've been following the whole situation with Wii U eMMCs dying since March this year, and I've been finding conflicting information about what causes Wii U eMMCs to die. Some people say it is from not having the system plugged in for long periods, some people say it is because Hynix chips are faulty, some people say it is because of having a bad auto save, some people say it is because the system lost power during a system update.

As someone who has had a Wii U since 2012, the system is pretty important to me as I have had a lot of memories with it, so I really don't want to lose it anytime soon. My Wii U still works to this day and I haven't seen any of the fatal error codes once within the past 10 years of me using the system, so that has given me hope that my Wii U might live a long life.

Out of paranoia since my Wii U is soft-modded, I made a NAND backup and used WiiUIdent to check the production date and eMMC manufacturer of the system.

These were the results:
Wii U production date: 2012/09/24 03:35
Manufacturer: Samsung
MLC production date: 2012/08

Now I've I mentioned before, a lot of people have pointed to Hynix chips being a possible cause of eMMC failure, and Maschell himself has pointed that out as the potential cause too after the HackMD list was published. As of today, 38 failures were recorded with 36 of them being Hynix, 2 of them being Samsung, and 0 of them being Toshiba.

So I really have to ask, has there been any updates on this situation? Has it been figured out what exactly causes the data on the eMMC to corrupt? Surely it isn't just the Hynix chips as from the HackMD list, 2 Samsung failures were reported and I've seen people on GBAtemp report that their Wii U with a Toshiba chip corrupted too. So what exactly determines whether a Wii U lives or dies? Is it all luck? Because again, I've had my Wii U for over 10 years and never saw any of the fatal error codes. So what exactly did I do differently from everyone else that caused my Wii U to still be fine after all these years? Did I just get lucky with a non-faulty chip?

 

[rcpd]

It’s not known for certain (and likely never will be) what’s causing it. We have a pretty good idea what’s causing it, though.

All NAND chips can fail and will fail eventually. The problem is that certain Hynix chips within a specific manufacturer date are more likely to fail prematurely for various reasons. The most likely reason being cell degradation due to lack of power.

Since yours is a Samsung, there isn’t much you can do to prevent this. Basically the same thing the Hynix users should be doing: creating one or multiple NAND dumps and backing up the dumps, removing the NAND chip from operating using the NAND-Aid from Voultar, verifying your NAND dumps, flash the dump to a microSD, use NUSpli to fix errors in the NAND on microSD, update if needed, and enjoy.

That’s if you’re very paranoid about it. If you’re not, just be sure to turn the darned thing on and play it once in a while.

 

[RyanXx]

The problem is that certain Hynix chips within a specific manufacturer date are more likely to fail prematurely for various reasons.

Do you know what that specific manufacturer date is? Is it 2012-2013?

Since yours is a Samsung, there isn’t much you can do to prevent this.

So Samsung chips are just as likely to fail as Hynix chips?

 

[SDIO]

There are different Problems, which have different causes, but can end with similar Symptoms. You have to understand that everything can fail. Nothing is guaranteed to last forever. And with every chip from every vendor there is a failure rate. From the Data we have so far it's clearly that these early Hynix Chips have a problem, which is most likely a little more leakage on the floating gate than expected. As for the 2 Samsung failures, as already pointed out you have a failure rate on everything. So I wouldn't worry much if you have Samsung. The failures are rare enough that it's just not worth thinking too much about it. Obviously having a Backup is a good idea anyway and besides that I wouldn't do anything.

And if you yank out the power while something is written, you can cause corruption on the data currently written. It will produce the same 160-0103 error on the screen but in the log we will see that it is "just" Data corruption and not Media Error.
Same if you unplug during a update, if it's updating the System menu at that moment you will probably get the same error.
Also a CHBC brick can make 160-0103 show up.

But really your console is fine, don't worry about that.

 

[rcpd]

Do you know what that specific manufacturer date is? Is it 2012-2013?

So Samsung chips are just as likely to fail as Hynix chips?

Have a look here. It has collected some stats from users who have submitted WiiUIdent logs: https://wiiu.gerbilsoft.com/

Have a look here, GerbilSoft provided stats on the stats in this thread: https://gbatemp.net/threads/wiiuident-a-wii-u-identification-homebrew.630023/

No, off hand I don’t know which dates the Hynix chips were bad. And unless you have one of those Hynix chips, you’re NAND chip has just as much chance to die as any other NAND chip by any other manufacturer. Only those specific Hynix chips are prone to premature failure.

I wouldn’t worry about your console unless you have some reason to worry about your console. It sounds like you don’t, so don’t. Enjoy it.

 

[RyanXx]

160-0103

I've also seen 160-2215 error codes happen to people when opening system apps like System Settings, Download Management, Nintendo eShop, Mii Maker etc. Is the 160-2215 error code related? If so, why does the Wii U give a separate error code?

 

[SDIO]

Maybe a little more on flash data retention:
Flash stores your data by saving a charge in a insulated gate of a transistor. As no insulator is perfect the charge leaks out over time. All flash will loose the data after some time. MLC faster than SLC, as SLC only has to states, charged and not charged. MLC has 4 voltage levels, so you need a smaller change in the charge to corrupt data. With higher Temperature the leakage rate increases. So it's maybe not the best to stor your wii u for 30 years in the hot attic and expect it to work, but that goes for all flash based media, like SSDs, Flash drives, SD cards, the CF card in your old camera. But please don't put your Wii U in the freezer. Freezing might also damage stuff and condensation is also bad.

And with the Hynix chips the leakage seems to be worse. Maybe there was some chemistry of in the manufacturing process or who knows what went wrong there.

It is expected that some errors emerge, for that flash drives have some hidden memory, where they save redundant information, which can be used to correct a certain number of bit errors. If few enough bits flip the ECC (Error Correction Code) can detect and correct it. In that case you will notice nothing, it happens completly transperrent , if more fail, it can detect that, but not correct that. In that case we will se MEDIA ERROR in the logs. The emmc notices the data is corrupt and tells the host (Wii U so). If even more bits fail in the right pattern, then ECC can't detect that the data became corrupt and will return erroneous data. In that case the Wii U file system will notice it, because it puts hash checking on everything. Independent of the eMMCs internal ECC.
As a side note the SLC on the Wii U is a RAW flash chip, without a integrated controller, which could do error correction. If you dump that, you will notice that the dump has 528MiB, but the advertised size is 512MiB. These Additional 16MiB are used for ECC and other RAS stuff. This has to be done by the Wii Us file system. That's one reason why it uses another filesystem (ISFS compared to WFS).

There is the hypothesis that this failure can be prevented by regularly turning the Wii U on. And there might be some truth to it.
If errors can be detected while they are still recoverable the eMMCs controller will just correct them and rewrite them (probably to another page) and further degradation in a uncorrectable state is avoided. But as you might already have noticed the data needs to be read, so the controller can detect the errors. Just applying power to the flash won't improve anything.
If the Wii U is just booted, that might still work, but less used functions could still degrade. There is also the possibility that some often read data is only served from the SLC cache and the data beneth it in the eMMC degrades and the errors aren't noticed. If the data then get evicted because the cache is used for something else (maybe a game install or an update) the degraded data from the eMMC would be read the next time.
There is the possibility that the eMMC does check the data, when it is idling, and some eMMCs might do, but this specific eMMC might as well not do it. With the backup you forced the eMMC to read everything once and with that correction of any correctable errors should have been be triggered.

Post automatically merged: Jun 12, 2023

I've also seen 160-2215 error codes happen to people when opening system apps like System Settings, Download Management, Nintendo eShop, Mii Maker etc. Is the 160-2215 error code related? If so, why does the Wii U give a separate error code?

I would need to see the logs then. But I think I got this error, when I deleted these applets like browser, miiverse, eshop etc and tried to launch them, but not sure anymore.

 

[RyanXx]

Okay, I was pretty confused but now I think I understand the situation a bit better. There was a lot of misinformation spreading around so I'm glad things got cleared up, thank you both for the help!