Gaming Nintendo Switch/3DS cartridge lifespan

[socram8888]

I've seen multiple posts through the internet about people worried that their cartridges could die anytime in the future due, and given I have a significant collection, I decided to stop guessing like everyone else seems to be doing and start researching into the matter.

First we should talk about the elephant in the room: what technology is being used by Nintendo for their cartridges? Some people say it's mask ROM, others say it's NAND, and others say it's an hybrid of both, containing both read-only and read-write memory on the same chip.

Well, since the 3DS, they have been using a technology from Macronix known as XtraROM. Although it bears "ROM" in it, suggesting it could be based on a MaskROM technology used until since the NES all the way to the DS, it is not.

This isn't really explicitelly explained anywhere on Macronix's website, making it kinda ambiguous. However, by looking at Macronix's 2015-Q2 report, in page 22, we can see they list XtraROM as a "Multi bit/cell Technology Charge Trapping Technology". This means that, essentially, XtraROM is a fancy marketing term for a factory-programmed MLC NAND FLASH.

This brings the real question you might be worried about if you are reading this: are all our carts going to die?

If the Switch and 3DS cartridges were read-only FLASH memories, without the capability to periodically rewrite their contents, it would be the case. It's basic physics - electrons leak from their respective charge traps over time and the contents become fuzzy for the controller to make sense of them.

However, today a new Nintendo leak has happened that shines some more key insight in the XtraROM technology, and how they are not as read-only as previously thought.

This leak contains an archive called "datasheet.7z". Inside this archive (which for legal reasons I will not be linking), there are datasheets for the memory ICs used in Nintendo's Switch cartridges, including Lapis' MR20RG2410D and MR20RG4410E, and Macronix's MX23J8GL0, MX23J16GL0, MX23J32GL0, MX23K64GL0, MX23K128GL0 and MX23K256GL0.

They are all pretty sparse and lackluster, but there's one in particular (Lapis MR20RG2410D, "datasheet.7z/データシート/GC/Lapis/ES/4GB_ROM.pdf") that contains a very interesting piece of information: all Nintendo Switch cartridges support two special commands, known as "RD_SELF_REFRESH" and "RD_REFRESH_STATUS", meant to fix any possible degradation in the contents of the NAND memory during reflow (aka soldering).

This means that a cartridge is, even though read-only from the console-facing port, still capable of reprogramming itself to fix its own errors using error correction algorithms, whenever it is sent this command.

However, this brings another question: is the Switch actively issuing these commands to refresh the NAND contents, or are they, as the datasheet implies, only to be used after soldering in the manufacturing plant?

We don't have access to the Nintendo Switch source code to be 100% sure, so all we can do is speculate. However, rather than just making up facts, let's dig some more into the 3DS.

Remember that:

1. Nintendo already used XtraROM for the 3DS
2. Horizon OS is an evolution of the 3DS's kernel
3. The full kernel got leaked a while ago.

First, skimming through the vast amount of leaked documents, I've found on "Documents.7z/Documents/セキュリティチーム運営/セキュリティ仕様書/CTR/CTR_Card_Memrory_SPEC20121212正式版.pdf" that 3DS cartridges also contain a command (0xC3, known as s*RD_REFRESH), that like the Switch, is meant to fix any possible data corruption in the memory.

Now that it's certain they can be also refreshed, I've had a look at the kernel sources, specifically into the drivers used to access the cartridges ("ctr.7z/ctr/sources/libraries/drivers/card/CTR/ARM946ES/").

These source files contain the last piece of the puzzle: the console indeed implements such functionality in the "CardInterfaceBase::SendRefresh" function in card_CardBaseInterface.cpp.

This function is called every 10k sectors read (from card_CardAsyncController.cpp), or every 3 milliseconds (from card_CardConfig.cpp), whichever happens first.

We can thus conclude that, for a card to be healthy, it's good to be periodically plugged in into a console so their NAND contents can be refreshed and thus avoid any data losses. Of course, this is only possible to a certain extent - ECC algorithms aren't magical and can only correct errors up to a limit. So if your cartridge is beyong that limit, though luck.

TL;DR: plug in your cartridges every now and then into your consoles and let them idle for a while, and everything will be fine.

 

[katastam]

in page 22, we can see they list XtraROM as a "Multi bit/cell Technology Charge Trapping Technology". This means that, essentially, XtraROM is a fancy marketing term for a factory-programmed MLC NAND FLASH.

first of all, Cartridge is made from ROM, ROM is made from NOR flash. Second, MLC and Charge Trap technology is not limited in NAND flash. QLC NOR flash was already developed by STMicroelectronics in 2000, and MLC NOR flash by Intel in 2003. Charge Trap technology for NOR flash was developed in 2013.

 

[M7L7NK7]

3 years and 6 days

 

[FAST6191]

Fun investigation however I would be looking at BGA failure long before this becomes a real problem for most purposes. Indeed we have already seen people take up reflowing things and getting it back on track.

Do the datasheets mention what level of ECC they have/are suggested to have? Don't know if it is programmable/selectable if the game maker wanted to cheap out and drop ECC amount* to gain a bit more space like some do for NAND chips and replacement sectors.

*for those unfamiliar with the idea. Imagine an infinitely long line on a graph. Basic maths says you need two points on the line to define it, however if one breaks then you don't have the original line any more. Now you have three points. Bit redundant but if you have some other means of checking (say a hash) you can reconstruct the line, four points either makes more sure or allows more damage, 5 points better still, 6 points now we are getting somewhere but also without compression 3 times as much data needed to store if just doing points and thus you can contemplate dropping to lower safety for higher storage for the same amount. Computer data is not straight lines but can still be represented by an equation for a geometric shape (see fun with sine curves they teach electrical engineering types, usually how any segment can be a series of sine curves, same idea here) and thus with enough data points you have the ability to reconstruct damaged data. You will tend to meet this in these sorts of circles in PAR2 files/par files which are popular in usenet circles where corrupted posts is/will likely always be a problem.

Though I am curious. I wonder what an accelerated testing regime would look like here. Get a bunch of cheapo sports games or something, put in various higher temperatures (higher temp = faster ageing in most things, though I have no models for things here) for extended periods and see. Would probably take a fair few games though; 1 datapoint is probably worse than none for most testing purposes, and you then either want to build a reader that will not use the refresh command or have enough that you still have enough samples even when it does, multiplied by say 3 or 4 to give different temp ranges up to around 90 degrees maybe, plus power to heat things for extended periods.

 

[Skv0ra]

TL;DR: plug in your cartridges every now and then into your consoles and let them idle for a while, and everything will be fine.

Excellent post OP! I would've figured that to prolong anything with write enabled would be to use it as little as possible. This also clearly goes to show to backup alllll your saves twice or thrice.

 

[Deleted member 568892]

How long is "periodically"?

 

[Maeson]

I know it's an old thread but I believe it's worth thanking socram8888 for this information.I do not have a Switch so I don't visit this section, but I bumped on this thread by accident and it's a fascinating read, and good to know for my 3DS games.

I actually bought a dead game (Little Battlers Experience) and I even tried one homebrew app that tries to revive them, without any luck. Fortunately I could change it for a working one when it happened some months ago, and since then I've kept looking from time to time information about this.

Again, thanks. My only doubt is how often is "every now and then".

 

[remlei]

Masked ROMS is still the best, its like your asking TSMC to actually put those game on the chip itself.

Flashed based storage basically have expiration the longer you dont use it. Not all NAND chips are created equal so the degradation may actually happen just a few years, just like what happen to Wii U.

 

[TinaNinja]

One of the best posts out there,
So from now on im going to use my cartridge everyday in order to keep it healthy

 

[shadowofdarkness]

Hopefully someone will make a Switch version of the 3DS Corrupted Cartridge Fixer if it is possible. To help with the problem and give people a easy test to run occasionally on the game carts rather then just finding random bad data that may happen to be in a obscure part of the game if it does exist.
I did ask the creator of the 3DS cartridge fixer and he said he would not be working on a Switch version as it would be too hard for him.