Corrupted Cartridge Fixer Release

[morrisk]

I'm running the cartridge fixer on a Smash cartridge. that didn't get detected by any of my 3DS'. Sitting at over 30 million refreshes right now. I assume it's a lost cause. I just wish I could pull the save file from it, but Checkpoint can't even back up the save file at all. All it says that the cartridge cannot be accessed...

 

[skawo]

Could be some sort of physical issue in that case, like the fabled cracked solder joints.

 

[Deleted member 486901]

Seems to be a lot of problems with Smash carts moreso than others no? Even the 2nd cart ran through was a smash one and I remember it not going so well.

 

[skawo]

Smash and Pokemon ORAS seems the most affected, yeah

 

[morrisk]

I reflowed the solder joints already. Didn't make a difference sadly. I managed to pull the save file with JKSM in the end, but yeah, that cartridge is definitely dead.

 

[mrgamer5409]

I just tried this with my copy of robobot and it was fixed after running the fix, really happy about this since its one of my favorite games and i was super bummed when it stopped working

 

[voltar324]

I tested 8 of my games with with the NCSD verify, 1 of them failed the verification and 7 passed. The one that failed was Megaman Legacy Collection, I tried playing the game and there were no issues but the verification continued to fail. I did 1 fix cycle and the verification still failed after a second cycle it passed.

I looked through a lot of the internal documents to try to understand what this is doing or why it works. The command 0xC5 is known as RD_REFRESH or RD_REFLESH it's possible that is a spelling mistake but multiple documents use that spelling consistently.

There is documentation for a test application that was used to evaluate different memory chips. It appears to be used to stress test the memory chip. The instructions include an "Ageing Test" next to this is a reference to RD_REFRESH stating "When the A button is pressed, RD_REFRESH is issued. If TIME OUT occurs 'TIME OUT' will be displayed".

The documents reference that RD_REFRESH is issued periodically in S1 mode. There is an S1 and S2 mode these seem to be related to the state of the encryption possibly a reference to when the encrypted file system is unlocked.

I couldn't find any information on what specifically the command does but it doesn't take any references for what sector of memory to refresh. It's possible that it refreshes the charges of cells that were most recently read but that doesn't make sense for a memory controller to operate that way. Each recharge will put wear on the cell so it wouldn't be efficient to be randomly refreshing cells. Most memory controllers have some mechanism to detect degraded charges and then recharge. It's clear from the internal documents the RD_REFRESH is issued at regular intervals not in response to detected errors. I think this command may be instructing the memory controller to continue background refreshing possibly for a very short period of time. This may have been done to lower power usage when not in use. It's likely the process of reading the bad sectors repeatedly is triggering the ECC detection and recharge for that sector more so than the RD_REFRESH command. This is how most memory controllers operate.

There may not be any additional effect to excessively issuing the command instead simply reading the data repeatedly will best maintain and correct the charges. If you want to prevent corruption in your collection running the validate process 1-2 times should sufficiently recharge any degraded sectors. But it's likely that it will only recharge a sector when degradation is detected so the whole process would need to be done every year to try to catch the degraded sectors before it can't be corrected by the memory controller. Otherwise I think a lot of 3DS cartridges will start getting corruption around the 10-15 year timeline. From what I could find these are MLC possibly TLC NAND chips and that technology isn't designed for longevity. Cars for example specifically use SLC NAND.

 

[skawo]

That might very well be.

When I was fixing my Paper Jam Bros. cartridge, I dumped the filesystem, compared it to a good one, and then tried running the refresh process on each file separately. In doing this, only the files I was "working" on were getting steadily fixed - the others stayed corrupted. I attributed this to the refresh function, but it could indeed just be the reading itself.

It would be neat to test if just running verify over and over will also fix a game.

 

[voltar324]

When I have more time I will be checking my entire collection and will try to find another corrupted cartridge to test. But I did try running the verify a few times on a few different 3DS systems and it continued to fail so it likely needs more than that. The code in your refresh repeatably reads the same sectors that alone could trigger the ECC mechanism.

I tried to add information about the 3DS system which also has NAND flash but it's getting blocked for filtered keywords. But the 3DS NAND uses pSLC so it will be far more resilient than the cartridges.

 

[skawo]

Here, I attached a version that will keep re-reading the same faulty section over and over without calling the refresh function more than normal:

 

[Spencist]

Hi I downloaded the file and added it to my payload folder, opened Godmode and got to the part where it says NCSD image options, and when I click on it I see all the options except “fix cartridge corruption” is there something missing or that changed? Thank you!

 

[skawo]

Sounds like you opened the regular unchanged Godmode9 and not this version

 

[Kwyjor]

Could be some sort of physical issue in that case, like the fabled cracked solder joints.

Has there been any further research done on that since Voultar's video from three years ago? It'd be nice if there was more support for the idea.

 

[voltar324]

Has there been any further research done on that since Voultar's video from three years ago? It'd be nice if there was more support for the idea.

There's already extensive research into NAND memory durability. NAND uses charge traps to store the data over time those can lose charge and cause corruption. It becomes significantly worse going from SLC to MLC to TLC. With SLC each cell holds 1 bit either a 0 or 1. If the charge is between 0%-50% it is a 0 if it is between 50%-100% it's a 1. This doubles with MLC 0%-25% is 00, 25%-50% is 01, 50%-75% is 10 and 75%-100% is 11. With TLC it goes to 3 bits and the margin drops to just 12.5%. By storing more data in one cell it increases density and reduces costs. There are even further levels with modern high density storage. This is why the cartridges will fail long before the console which is pSLC and some cartridges will be more prone if it is TLC instead of MLC. I'm not sure if the cartridges are MLC or TLC or a mix of both but it's at least MLC, both were widely available at the time of the development of the cartridges. As the density in each cell increases the amount of charge loss that is needed to create corruption reduces.

Post automatically merged: Jan 16, 2025

Also anyone who is using this on a collection should first do a verify on the .3ds file to get an idea of how common corruption is occurring. I tested a copy of Spy Hunter that came with an original 3DS that I got on eBay so it was likely a 2012 copy and it didn't have corruption. The console seemed to be almost unused and the game likely hadn't been used very much. This does defy the expectations of NAND durability but a lot of those assumptions were based on higher temperatures that are common in datacenters. Storage temperature has a big impact on how fast the charge loss occurs. The corrupted Mega Man Legacy Collection that I had came from eBay and the case was relatively dirty and probably wasn't stored in a good environment.

 

[redunka]

According to info from this thread, 3DS carts are MLC:
https://gbatemp.net/threads/nintendo-switch-3ds-cartridge-lifespan.591607/
Not sure if there have been any reports of Switch carts failing so far, but looks like it's a possibility with all those things considered.

 

[Kwyjor]

There's already extensive research into NAND memory durability.

Yes, but I was referring to research into the frequency of cracked solder joints and whether reflowing was generally useful. NAND memory durability isn't going to be much of a problem if that's a thing that's regularly happening.

 

[skawo]

I have not heard of a cart being fixed in that manner aside from seeing it in Voultar's video. Make of that what you will.
Still bears mentioning as a possibility, though.

 

[ghjfdtg]

The heat from reflowing the solder joints may have pushed the cells over the edge and got them readable enough so the game appeared fine. It's not uncommon in professional data recovery on flash media to read the chip out under high and low temperatures to recover more data. His copy may have had cracked solder joints but i doubt this is a common failure at all. The case is pretty robust and prevents most bending.

 

[KWG-08C]

I see this whenevr I try to ooad my savefile on Alpha Sapphire, however, the verification doesn't fail. Do you think it's worth using your app to fix the cartridge or does that error mean the failure is likely produced by something else?

 

[Kwyjor]

I see this whenevr I try to ooad my savefile on Alpha Sapphire, however, the verification doesn't fail. Do you think it's worth using your app to fix the cartridge or does that error mean the failure is likely produced by something else?

Dump your savefile and see if you can read it with pkhex or PKSM.

Also, if you have some sort of cheats or mods enabled, then that could easily be the source of the problem.