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:
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.
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:
- Nintendo already used XtraROM for the 3DS
- Horizon OS is an evolution of the 3DS's kernel
- 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.
