05-16-2010, 07:09 AM
Its certainly possible the chip is damaged, especially if you are soldering directly to the legs of the chip (heat damage). If you are doing it from the via's its most likely a bad/poor connection. The crossed data wire shouldnt have killed the chip.
Failing that, the infectus isnt really a very good programmer, you will find the chip will probably work ok in a proper dedicated programmer.
05-16-2010, 09:52 AM
Thanks for your replies.
As Bad_Ad84 already pointed out, changing the identifier in the config file will not work.
Yes, I've tried to disconnect/reconnect, close/reopen, etc..
However, I'm now randomly (mostly not) able to identify it in all programs I've tried, but anything i read/write to the NAND is corrupt.
If i try to dump the first block with Infectus NAND Flasher 1.03 then i get ECC warnings and the dump is mostly corrupted (much of it is correct though) and if i try to dump the same area again, most of the content of the dump is just 0xFF 0xCA ... etc.
I've measured all points with a DMM and everything is correct and nothing is shorted to each other.
I have no clue where to go on from now on.. :/
Anyone got any idea on what i can try now?
05-16-2010, 09:54 AM
I assume this is a samsung nand chip not hynix, right?
05-16-2010, 10:02 AM
Sorry, i didn't notice your previous post.
I'm soldering to the via's, not directly to the NAND.
I've also tried to re-solder everything but that did not help.
Yes, it's a Samsung. I was already aware that the samsung's can be a little annoying to work with but i took the chance.
Last edited by Spzx0; 05-16-2010 at 10:04 AM.
05-16-2010, 10:04 AM
I never got samsungs to work with the infectus, only hynix.
I since binned the infectus and upgraded my programmer to one that supports nand
05-19-2010, 07:27 AM
This thing annoyed me a lot, so I've done some testing to see if anything changes in various scenarios.
And indeed it does.
The Q wire length seems to have A LOT to do with the samsung's (as already pointed out by OP over @gbatemp).
Too long or too short wire will only return junk.
Now i get MUCH less data corruption than i previous had. However, i still get data corruption..
Some of the corruption looks like it can be caused by a bug in the software.
E.g. If the software is supposed to write: .... 0x87 0x1D 0xC2 0xFF 0x00 ....
Instead it will write: .... 0x87 0x1D 0xC2 0xFF 0xFF 0x00 ....
Notice the double 0xFF's that get written.
This will cause every byte in some areas to be "pushed" one byte ahead, causing corruption.
Tested with "Infectus NAND Flasher 1.03" and "Xavbox 22.214.171.124 ?".
Both produce exact same result.
It would be nice if you could tell us approx length of the Q wire you use and post some pictures of how you've set stuff up.
Possible also small details, if any.
I think it would be very interesting to see if we're able to come up with a simple solution for us people with "unwritable samsung's".
05-19-2010, 12:28 PM
This is the Infectus ground bounce. Well documented on how to prevent this, even in this very thread
Originally Posted by Spzx0
(use multiple ground wires..)
1 User Says Thank You allsystemsgo For This Useful Post
05-19-2010, 01:38 PM
Last edited by Spzx0; 05-19-2010 at 01:56 PM.
05-19-2010, 08:42 PM
could i use the WAD2NAND OSX intalling this files(EULA-NUS-v2.wad,IOS30-64-v1040.wad,Region Select-NUS-v1.wad,System Menu-NUS-v258.wad) to nand.bin on my MAC, and then reflash it to bricked wii,does it work?
sorry for my English.
05-19-2010, 11:53 PM
Long Q wire is supposed to help fix it too, but as I said above i never got it to work, even with rigging the infectus upto a tsop48 socket and doing it all out of system.
Not that is matters now, right tool for the job and all that.