Hacking [Guide] Kafluke's HardMod CBHC Unbrick guide

[Anonyamalious]

So did you get it to recognize then?

No.

--------------------- MERGED ---------------------------

The only thing I can think of is that nandway.py is not compatable with the Toshiba TSOP nand that you have.
I have only ever seen Samsung or Hynix TSOP chips used in the WiiU before. I cannot find a datasheet for the Toshiba chip but obviously the nand size should only be 512MB like the others because it was the correct size when you dumped it with the nand dumper software.

I desoldered and resoldered everything for the third time and still the same thing, guess I'm outta luck...

 

[Leeful]

@Anonyamalious Another thing you could try is the Dual Nand Edition setup with the teensy instead of the Signal Booster Edition setup.
You still use the same NANDway.py and the same commands as before but the wireing connections are different on the teensy side. You also need to program the Dual Nand Edition.hex on the teensy.

I originally tried this setup when I was starting to mess around with the WiiU nand but I found that it produced inconsistant dumps.
This won't matter to you if you are only writing back the FIXED slc.bin that you have because it verifies as it writes (vwrite command) and if it detects a bad block you can just make a note of if and just write back the bad blocks again to save time.

If you want to give it a go just do the INFO command first and see if it detects your nand correctly. If all goes well I'll give you more help on writing back your FIXED slc.bin.

Attached is the new hex you need for the teensy.

 

[Anonyamalious]

@Anonyamalious Another thing you could try is the Dual Nand Edition setup with the teensy instead of the Signal Booster Edition setup.
You still use the same NANDway.py and the same commands as before but the wireing connections are different on the teensy side. You also need to program the Dual Nand Edition.hex on the teensy.

I originally tried this setup when I was starting to mess around with the WiiU nand but I found that it produced inconsistant dumps.
This won't matter to you if you are only writing back the FIXED slc.bin that you have because it verifies as it writes (vwrite command) and if it detects a bad block you can just make a note of if and just write back the bad blocks again to save time.

If you want to give it a go just do the INFO command first and see if it detects your nand correctly. If all goes well I'll give you more help on writing back your FIXED slc.bin.

Attached is the new hex you need for the teensy.
View attachment 92766

Thanks @Leeful , I'll give it a whirl, wish me luck!

 

[Anonyamalious]

@Leeful , I tried those points with the new hex but it's giving the same result and it won't vwrite. I guess now it's safe to say it's nandway is incompatible with the toshiba nand.

Spoiler: Screenshot

 

[Leeful]

@Leeful , I tried those points with the new hex but it's giving the same result and it won't vwrite. I guess now it's safe to say it's nandway is incompatible with the toshiba nand.

I cant think of anything else for you to try.
It won't write to the nand because the nand image has to be the same size as what nandway detects and at the moment it is seeing your nand as 2048MB when it should only be 512MB.

 

[Anonyamalious]

I cant think of anything else for you to try.
It won't write to the nand because the nand image has to be the same size as what nandway detects and at the moment it is seeing your nand as 2048MB when it should only be 512MB.

Do you think there's a possibility it's a valid dump just that there's a bunch of junk taking up space? I doubt developers will do anything to do so much just for one specific model of NAND since that possibility is so rare. Well I'm lucked out.

Thanks so much for you and @Kafluke for helping me through this! I'll check back at this space regularly to see if anything's changed.

 

[CosmoCortney]

for some reason I have troubles to cut the track between these 2 pads. it looks like it's cut but testing it with a multimeter still gives the pass through signal

 

[Leeful]

for some reason I have troubles to cut the track between these 2 pads. it looks like it's cut but testing it with a multimeter still gives the pass through signal

Could you post a clear picture of both sides of your teensy board. It might be a clone/fake one. If it is, it will still work but there is one more track to cut on the other of the pcb to convert it to 3.3v.

 

[CosmoCortney]

Could you post a clear picture of both sides of your teensy board. It might be a clone/fake one. If it is, it will still work but there is one more track to cut on the other of the pcb to convert it to 3.3v.

Looks like I got a fake one. I have a pass through on several points where I think it shouldn't have. Btw, my camera is not the best..

 

[Leeful]

Yes thats a fake one, the same as mine.
The first thing i notice is that you have not soldered on the 3.3v regulator. You need this because the teensy needs to be running at 3.3v, the same as the TSOP nand on the WiiU.
When you have the voltage regulator in place and have cut the other track in the picture below and have joined the 2 big pads on the back your teensy should be running at 3.3v.

The problem with these clone / fake teensy boards is that even with the regulartor attached the 5v line from the USB is still connected to the main circuit and it completely bypasses the regulator. By cutting this other track the 5v line goes straight through the regulator, converting the voltage on the board to 3.3v as it should.

When you have done this check the voltage between the +5v and GND pins on the teensy and it should read 3.3v. (3.2v is fine also)

 

[DeadlyFoez]

How do you identify a fake one?

 

[Leeful]

How do you identify a fake one?

This is a real one.

This is my fake.

As you can tell the pcb layout is different on a fake / Clone.

 

[Leeful]

@Anonyamalious I have just thought of something else you could try.
Dump the first 4096 blocks of the nand which should be your SLC and test the dump with the nandBinCheck and nandCbhcRemover tools. The command to dump would be:
NANDway.py COM3 0 dump slc_test.bin 00 1000

Obviously change the COM part to whatever your teensy com port is. The 00 is the starting offset and the 1000 is the number of blocks to dump (1000 is 4096 in hex, nandway uses hex values)

It would also be best to use the SignalBoosterEdidtion setup again as it is more reliable.

Let me know the results.

 

[CosmoCortney]

Yes thats a fake one, the same as mine.
The first thing i notice is that you have not soldered on the 3.3v regulator. You need this because the teensy needs to be running at 3.3v, the same as the TSOP nand on the WiiU.
When you have the voltage regulator in place and have cut the other track in the picture below and have joined the 2 big pads on the back your teensy should be running at 3.3v.
View attachment 92799
The problem with these clone / fake teensy boards is that even with the regulartor attached the 5v line from the USB is still connected to the main circuit and it completely bypasses the regulator. By cutting this other track the 5v line goes straight through the regulator, converting the voltage on the board to 3.3v as it should.

When you have done this check the voltage between the +5v and GND pins on the teensy and it should read 3.3v. (3.2v is fine also)

Thank you. The 3.3v regulator isn't attached because I have yet not arrived

Just noticed on the pic that it is the 5v power source from USB. Wouldn't it be sufficient if I wire the 3.3v output of my Raspberry Pi on there?

 

[Leeful]

Thank you. The 3.3v regulator isn't attached because I have yet not arrived

Just noticed on the pic that it is the 5v power source from USB. Wouldn't it be sufficient if I wire the 3.3v output of my Raspberry Pi on there?

I dont know if that would work or not because would it still be getting 5v from the USB?

 

[CosmoCortney]

I dont know if that would work or not because would it still be getting 5v from the USB?

the idea was cutting the 5v wire from the usb cable and connecting the 3.3v power source from the raspberry pi on there. But I better scrap this idea since the 3.3v regulator is already ordered.
BTW, I have just cut the other track and the signal still passes through these 2 pads

 

[Leeful]

BTW, I have just cut the other track and the signal still passes through these 2 pads

That should not be a problem when the regulator is connected. At the moment with the new track you cut, the 5v path from the USB only goes straight to the underside of the PCB to one of the outer pads of the regulator and stops there. When the regulator is attached the 5v will pass through the regulator changing to 3.3v and out of the pad on the other side of the regulator completing the circuit to the PCB.

 

[CosmoCortney]

That should not be a problem when the regulator is connected. At the moment with the new track you cut the 5v path from the USB only goes straight to the underside of the PCB to one of the outer pads of the regulator and stops there. When the regulator is attached the 5v will pass through the regulator changing to 3.3v and out of the pad on the other side of the regulator completing the circuit to the PCB.

ok, thanks for clarifying this

 

[Leeful]

View attachment 92796 View attachment 92797

I've just noticed that you have the teensy wired up wrong. That is for the Dual Nand edition setup. You should be using the Signal booster edition like in the guide. It is more reliable.

 

[Anonyamalious]

@Anonyamalious I have just thought of something else you could try.
Dump the first 4096 blocks of the nand which should be your SLC and test the dump with the nandBinCheck and nandCbhcRemover tools. The command to dump would be:
NANDway.py COM3 0 dump slc_test.bin 00 1000

Obviously change the COM part to whatever your teensy com port is. The 00 is the starting offset and the 1000 is the number of blocks to dump (1000 is 4096 in hex, nandway uses hex values)

It would also be best to use the SignalBoosterEdidtion setup again as it is more reliable.

Let me know the results.

@Leeful here is the nandbincheck with the dualnand edition, I'll resolder everything to signalbooster edition if you think it'll yield better results based on the current findings:

Spoiler: Screenshot

How to 'dump without ECC'? slc_test.bin dump size is 540,672KB that's the same size as a fixed bin from nandfixer. My slc.full.img is 524,288KB (without fix)