The way I read this is that you tried the 64 GB card one time only and that you did this at a time the 32 GB card also didn't work / showed the exact same errors.
Am I right with this and if so: Could you try to clone the 32 GB card to the 64 GB one and try this, please? From a technical standpoint the Wii U knows 2 MMC sizes: 8 GB and not 8 GB. All not 8 GB is expected to be 32 GB, so using a 64 GB card should work (but waste space).
After I flashed back the SLC and it began working again with the 32GB card, I put the 64GB card back and it still didn't work. When I looked at the logic analyzer I saw that the Wii U gave up after querying the status, it didn't even attempt a read from the SDXC card, so it doesn't matter what was on it.
The strange thing is, the SDXC card is working fine in the normal SD Slot of the Wii U, so the Cafe OS should be able to handle it.
Amazing work! Interesting that the Wii U doesn't like higher than 32GB SD Cards, maybe Cafe OS is hard limited to 32GB max, who knows.
I'm a bit worried because I have my Wii U since launch, so it's a 32GB launch unit, still works perfectly fine without a single issue, but I don't now how longer will the NAND work.
Also, I did read that you couldn't get better performance out of a faster SD Card? That's interesting, I remember when I was using redNAND with a high class SDCard, the Wii U Menu loading and the apps felt faster.
By the way, an eMMC is supposed to have a better read/write life cycle right than SDCards right? Although, I guess that after you do this mod, it will just be easier to replace a dying SDCard than a new dying eMMC (But the eMMC should last another 10 years I guess, it's probable that other Wii U component will begin to fail first).
Nintendo used different eMMC chios from different Vendors. My failed eMMC is a Hynix H26M64002BNR 228A.They probably had a bad batch or something together with the Cafe OS, wich seems to be write heavy (because it is also known for killing USB sticks) it was just a bad combination in my case. Also the Wii U was unused for many years. Flash can also loose it's content over time just sitting there.
I assume the reason I didn't see a performance difference is the SLC cache doing it's job. With redNAND you don't have the SLC cache.
I would also assume eMMC should be better in general. But here it seems to really be a bad batch of eMMC chips. Also a current SD card from a good brand should last for some time. I am using a Sandisk, but that's just my personal preference as I will never trust Samsung again with anything containing flash (They are also known for many eMMC bugs, like on the Galays S2 and S3 and Nexus 7 and also the 840 Evo (which I own one) has a few known problems). So it's Sandisk for me, never had problems with them. But I also had a HTC HD2, where I was running Android from an Samsung SD card for a long time. Back then I never had Problems with the SD card. But it is the same SD card I used for the comparison. When I made an Backup of the old card before overwriting it with the Wii U MLC I also saw some bit rod there (some blocks needed a few attemps, but it seems the controller was able to correct them finally). Or maybe the contacts where just oxidized and reinserting it a few time scratected them clean...
I'm quoating a post of mine from another thread, but I'm seeing some people are starting to have NAND corruption with the typical 160-0103 error, the article is from 2015, but it suggests that for older SSDs you should power it before a year passes since the last time you use your device, so I suggest everyone to power on their Wii Us every 8 months or so (whatever the time you want, just make sure isn't close to a year).
Yes, but it's not only affecting old SSDs. I would even assume old SLC SSDs are more robust. It is a general problem of flash and it only get's worse the finer the structures get and the more bits you have in a cell. Over time the electrons are migrating out of the Gate in the flash cell, The question is just how long it take till enough cells are corrupted so the ECC can't fix it. It also can happen to BIOS chips (butnot as often, as they are not pushing the limits) and SD cards, CF Cards and the SSD in your computer. Depending on how smart the controller is, it might not be doing a scrub on it's own and only detects errors when reading. I would add to your suggestion, that in addition to powering on it's also a good Idea to do a NAND backup, so every block gets read and the controller can detect the error, while it's still correctable.
I've heard multiple things:
- This information is pretty old and just now getting traction
- It only impacts Hynix emmc's
- Time isn't necessarily the issue since it has to do with the emmc's ability to write data to failed blocks
Would OP be willing to address those issues? Also are you planning on releasing a tutorial for replacing the emmc with an SD card? I could follow the picture, but I want to ensure I'm getting the correct connections and pinholes.
Yes in my case it was a Hynix.
I am not sure what caused my emmc to fail completely over time, if it was bitrod over time or if the cells died from too much writing, so it was running out of reserve blocks. Maybe it was also a combination of the two.
In this German Forum (you don't need to understand the text, just look at the pictures), where I first described the Problem the user nino postet a picture on how to connect the pins:
https://forum.wii-homebrew.com/inde...nach-Speicherfehler/?postID=715489#post715489 I don't want to repost it because of copyright. The only thing I would different is cutting the clk trace between the pads and then tie the clk on the emmc side to GND. Also having the pad there gives you the chance to reconnect the emmc if you ever want to.
I was informed that this piece of homebrew should detect it without taking the console apart
https://github.com/GaryOderNichts/mdinfo
Good to know, I also only knew the method of looking at the size. I guess I have to see what this tool has to say about my SD Card.
Does it make sense to move all the games from NAND to external drive to protect the console in this context?
Maybe. From what I know the Wii U writes cheap usb sticks to death when launching games from them. So that would indicate that you would move wear from the eMMC to the USB device. It would be interesting to see what is causing the writes. Maybe someone who knows more about the Firmware could insert some debug code to log all writes to serial or something like that.
@michalt We don't know the internal details of the Wii Us implementation so this is guesswork but yes.
Keeping your NAND as free as possible means more free cells which translates to better wear leveling. Also you will reduce writes (save files and stuff) as these files will move with the game.
When I scrolled through my NAND dump in a hex editor, it doesn't seem like the Wii U is discarding unsued blocks. So from the perspective of the eMMC everything, except some blocks at the end are used. But it was really just a very quick look and I was mostly interested in the part, that didn't fit on the SD card.
Maybe I will take a look again, but not today.
If the eMMC reached it's read/write limits... then there is nothing that can be done, only replacing the eMMC with another one, or with a SDCard (just like OP did).
Also, as consumer flash drives get older (for 2010s at least) then data retention starts to deteriorate if the chip is not powered on in a while (MLC), making the data corruption error to appear, that's why it's suggested to power up the console before a year passes since your last usage.
If data is corrupted, then it's fixeable via UPDIH, as long the IOSU is working (which usually should be, since it's on the SLC and not MLC, SLCs seems to be more durable).
To add a little to your answer: it seemed that in my case the FTL got corrupted and running the discard allowed the eMMC to clear and rebuild the FTL. Also it could be possible that the eMMC is returning I/O errors if it is degraded to much. Mine didn't (but it should have instead of returning random data). When you rewrite the eMMC the I/O errors are gone, which might help IOSU not crashing (but it also could make it worse).
I also saw a few videos from Voultar, maybe I should try to contact him.
whaou! Thanks to you all. I wasn't aware about this memory problem; so sad for the less sold nintendo console. I'll follow your recommandations and begin by move a max of thing from nand to usb.
And nowdays, is there something to backup the usb storage (or saves at least)?
I just use dd for my USB stick. But that would also save the unused space, which isn't much in my case. Together with the otp.bin and the seeprom.bin you can also extract it in the PC and copy it back over FTPiiU (but it takes a long time). I had to do this, because I did a Factory Reset at some point, which changed the USB key in the seeprom and I am to afraid of bricking to write the old seeprom back.
I now bought a broken Wii U from ebay. The seller said it just died, which also seems to be a common problem. Maybe I can figure something out. May 'hopeÄ is that it is also the MLC, but I think thats unlikely.
