OCZ Vertex 2 240GB SSD for recovery

[hhddrec]

Thanks to you, fzabkar too.

You you'd never alone!

to confirm the NAND array voltage on another board, as you have already suggested. If anyone has a datasheet for the SandForce controller, then that might also tell us whether 2.8V is OK.

I'll try to confirm V, but i have not this ssd in stock here

[hhddrec]

Thanks arvika

Some nands need 2.8V to read properly. I think hhddrec can desolder one chip and check ID in reader - maybe we can find in database something more about this nands.

I'll try to read ID to know maker, model and so on.

[hhddrec]

Thanks BlackST

In a nutshell all these stories end with this conclusion : when it is not an evident problem that cannot be classified as failure i.e. Fuses or alike, no low cost solution... (probably they invented the week because it's never always Sunday ).
@OP , SSDs are extremely difficult to deal with, if you really want to give services in this field to customers, seriously consider investing in equipment and know how .
P.s. Up now, on more than 1000 case, only few were power related and the outcome was bad (damage went beyond to the flash chips), on all the other the SSD were more or less working and the problem was ELSEWHERE. Having other identical devices at hand also helps.

I untherstand you

[hhddrec]

I am with tou Frank

I found numerous studies of multilayer ceramic capacitor (MLCC) failures at low voltages, eg ...
http://downloads.hindawi.com/journals/a ... 147949.pdf

They suggest that typical failure modes are short circuits or low resistance. Leakage currents of several uA are typical in the period prior to total failure.

ISTM that the OCZ design is vulnerable to problems arising from such failures. The high resistances in the feedback paths of the two OFA regulators mean that it doesn't take much leakage in either of the Cff capacitors (C18 and C8) before the output voltage drops significantly. HDDs, OTOH, generally have feedback resistances of the order of 100s of ohms.

In the Vio case, the current through R23 and R22 appears to be around 5uA. AFAICS it would only need around 1uA of leakage in C18 for Vio to fall from 3.3V to 2.8V. If this is indeed what has happened, then I wonder if this is a common problem. In fact I'm wondering whether the Vcore supply has been affected as well.

ceramic capacitors got lot of problems (shorted, low resistance), is very common failure in electronics.

[Randy]

fzabkar, i think that applied IC 3.3 LDO is too weak to hold such a big load, like a NAND array. My opinion is, that NAND array powered either from sata power connector (doubt in that), either from OFA chip.
Also, i agree, that lowering voltage may come from leaking capacitor, or rised resistanse of one of the resistors.
I think, if were was an active reset state, then we would not have seen anything in boot log.

The only way for hhddrec, like i see, is:

1. Find another, good OCZ, similar to faulty, to compare power supply for NAND (and other voltages).
2. On that good OCZ, take complete controller's boot log as a sample.
3. If programmer tool is available, then take a dump from good OCZ U5 chip.
4. If NAND or others power supply is faulty, then try to fix it.
5. If power sourses on a faulty drive is ok, then take a dump from U5 chip on a faulty one and compare it whith a dump from working OCZ to see the difference. Maybe, on a faulty OCZ were will be a explicit trash in U5 chip. We don't know.

Again, it is very low chances to get the data from it. And it's time-consuming. Decision, to do it, or not, depends from hhddrec and from his costumer.

Last edited by Randy on April 10th, 2013, 7:49, edited 1 time in total.

[Randy]

I think measure here. What you think?
see picture

Yes, check voltage on a VCC pin against a ground.

[hhddrec]

I think measure here. What you think?
see picture

Yes, check voltage on a VCC pin against a ground.

Thanks Randy and ather guys another time.

now i am away, but I'll check it,

[fzabkar]

fzabkar, i think that applied IC 3.3 LDO is too weak to hold such a big load, like a NAND array.

I wasn't suggesting that the LDO might be powering the NAND array. I was wondering whether it was possible for the controller's Vio rail and the NAND array's supply to be separate. By doing it that way, OCZ could play with the NAND voltage to achieve some power savings without affecting the controller.

[Randy]

fzabkar, i just misunderstood you. My Russian/English switch is a rusty. :-)
I agree with you, it must be an OFA chip.

[fzabkar]

I think, if were was an active reset state, then we would not have seen anything in boot log.

I assumed that either the SSD had developed a second problem, or that the initial problem had become worse. BTW, the MLCC article I alluded to earlier suggests that heating to 200 degC can sometimes "self-heal" a leaky MLCC. Perhaps resoldering it might be worth a try?

[Doomer]

Seems that healing firmware problem by measuring Vcc is not working

[Randy]

Perhaps resoldering it might be worth a try?

If it will be confirmed, that 2,8V is too low, then it may help.

Seems that healing firmware problem by measuring Vcc is not working

Nobody here tried to "heal" FW with measurements.
Measuring VCC is a part of diagnostics. And after diagnosis, if we become sure, that PCB is OK, at least in powersource part, then we can start thinking about FW "healing".

[Randy]

BlackST, your feelings was not lying.
hhddrec Do it on your own risk. If you feel you skilled enough.
Here is what you need to do. Be ready to spend some time and hold your nerves. Result is not guaranteed.

Preparation:

Find a separate good working PSU for usual desktop computer. 300-350 watt will good. On it's connector for mother board, locate a green wire. Short it with a black wire (near it) with any piece of wire, or metal clip.
Load PSU with any HDD and plug it in to the powerline. Your HDD should spin up and recalibrate. With a multimeter check +5v(red), +12v(yellow) and 3,3v(orange) against a ground wire (any black). They should be ok. Switch it off with it's power switch.
On computer stand, where you doing your hdd repair and data recovery, locate any, free Molex connector, and connect it's ground wire (black) with the same, Molex connector's ground wire (black) on just tested PSU. With any suitable wire. Ensure, that contact is good enough. Be careful not to short anything.
Now we have combined a grounds of bouth PSU by these way.
Connect computer's stand SATA data cable to the hdd, which powered from a separate PSU. Boot computer stand to a DOS and load MHDD.
Switch on separate PSU with it's power switch and wait, until hdd recalibrate.
In mhdd select appropriate port and check with "eid" command, is that drive visible or not. If it visible, then you can run a surface test for a couple of seconds, to make sure, that everything is ok.

Now the Voodoo magic:

Switch off bouth computer stand and separate PSU.
Replace HDD with faulty OCZ drive.
Switch on computer stand again. Load mhdd. Select appropriate port.

1. Switch on a separate PSU with it's power switch.
2. Wait a bit.
3. Give mhdd "eid" command.
4. Does OCZ detected?

If not, switch off separate psu with it's power switch, wait couple of seconds to allow PSU shut down, and go to the step 1.
(You can vary the time on a step 2.)
If yes, then with any cloning software, avaiable to you, make a clone of OCZ drive.

These can take a while, so i warned you. :-)

[BlackST]

Randy, if you asked him to use another psu you would have saved time and words

[Randy]

To exclude misunderstanding, i think it's better to provide step by step information.
And, sometimes things, that seems crazy, help to retrieve user's data.

[hhddrec]

Wellcome GreenWD,

all post here are good welcome.
Including critical posts,
Thanks GreenWD

[GreenWD]

Wellcome GreenWD,

all post here are good welcome.
Including critical posts,
Thanks GreenWD

Your welcomed.
And when you feel tired of all solutions without results, consider outsource to someone who have the pro know how and gear !
Google for a reputable lab near you.
No matter what you say, you will need pro help, and it will not be cheap.

[HaQue]

Hi,
Why don't you attack it a different way.

As you can see, the output of the Terminal after "RCPch SAK0" is gibberish, and this can be something like the baud rate of the terminal not correct or something.

What I did was to wonder what that gibberish text is meant to be, so google for "RCPch SAK0" results in this page:

at http://www.rom.by/forum/umer_OCZ_Vertex_2_40gb

Code:

RCPch SAK0
Failed to read EPA=20038060, using ByteLaneMask=2, ByteLaneTable[0]=1
Failed to read EPA=20038060, using ByteLaneMask=1, ByteLaneTable[1]=0
Failed to read EPA=20038060, using ByteLaneMask=4, ByteLaneTable[2]=2
RCPch SHI
sysclk 150 MHz

then:

Code:

Hello,
@Kollis: How did you get clean output from that drive? I managed to get the output with rubbish:

CLI> PINRST
*** ROM 106 Mar 12 2009 20:29:35 ***
FW_SRC 0 SHA PASS!
*** EEPROM 207 Jan 3 2011 18:36:27 BuildServer:FW_Common_Critical_Fixes:P1_EEPROM_2_0_7_drop-290232 ***
IMFT45 Timing EPch
*** Patch 1.4.1 Mar 10 2011 16:23:47 BuildServer:P1_3_6_0_MP4_7:P1_3_6_0_MP4_7-300475 ***
IMFT45 Timing EPch
RCPch SAK0
ÿÿÿÿÿ\_ýÞýÞýÞø^(_ýÞýÞýÞm—ŒýÞÿÿÿÿìcýÞýÞýÞýÞýÞýÞÂvÄ1ýÞUdP‡
ýÞýÞýÞÿÿÿÕýÞýÞÕýÞýÞ .... and so on.

I'm using following COM settings:
Baud rate: 115200
Data bits: 8
Stop bits: 1
Parity, Flow control: None


then this MAY help you:

Code:

As far as I know this can not be deducted, where encryption is used, I advise you to read the specification of the chip. And get a clean log into the terminal is simple: to close contacts 2-3 on ATMLH008, but what to do next has not yet been found. If there is any information as possible to flash it in this state, please share.

so at http://flash-extractor.com/forum/viewtopic.php?t=5063 is:

Code:

RCPch SAK0
GetRootRecord(): Failed to read Root FID=2, IBA=7!
Micron Timing EPch

at : http://www.ocztechnologyforum.com/forum/showthread.php?110014-Vertex-2-60GB-Dead-got-debug-info-from-serial-header-any-pointers

Code:

RCPch SAK0+Fmgr
*** ERROR REPORT ***

IMPWIRE: 00300000

[PART]
SCHE: 80104404: 00000000
SATA: 81001804: 00000000
BUFR: 82201404: 00000000
FLSH; 83004004: 00000000
SIDX: 84400004: 00000000


PANIC: file=src/root/DirectRdWr.c line=197
PANIC: error=0x80120003 Flash Command received an interrupt
[BOOT MAIN] Root Not Found!
FW_SRC 0 SHA PASS!
*** EEPROM 207 Jan 3 2011 18:36:43 BuildServer:FW_Common_Critical_Fixes:P1_EEPROM_2_0 _7_drop-290232 ***
EPch SHI
sysclk 150 MHz
JTAG En 0
Link ...
up

lol at OCZ answer:

This type of info is not available for public distribution. If the drive is no longer detected the only recourse is a RMA and get the drive replaced. If the drive was opened this is no longer an option though.

seems DR companies arent needed or wanted...

at http://www.domotiga.nl/projects/domotiga/wiki/Blog:

Code:

Found my dead OCZ SSD drive again and connected it to the serial port of my Ubuntu desktop.

This is what I get upon startup when i connect to it at 115200 Baud

RCPch SAK0+Fmgr
*** ERROR REPORT ***

IMPWIRE: 00300000

[PART]
SCHE:    80104404: 00000000
SATA:    81001804: 00000000
BUFR:    82201404: 00000000
FLSH;    83004004: 00000000
SIDX:    84400004: 00000000

PANIC: file=src/root/DirectRdWr.c  line=197
PANIC: error=0x80120003  Flash Command received an interrupt
[BOOT MAIN] Root Not Found!
FW_SRC 0 SHA PASS!
*** EEPROM 207 Jan  3 2011 18:36:43 BuildServer:FW_Common_Critical_Fixes:P1_EEPROM_2_0_7_drop-290232 ***
EPch SHI
sysclk 150 MHz
JTAG En 0
Link ...


Hope that helps in some small way.
HaQue

[fzabkar]

Hope that helps in some small way.HaQue

I had a similar idea but I didn't follow it through. Thanks very much.

I found this thread:
http://forum.ru-board.com/topic.cgi?forum=84&topic=3927
http://translate.google.com/translate?h ... pic%3D3927

I don't think it's a baud rate issue since the early part of the dump is readable. Instead the gibberish looks like 0xFF and 0xFD bytes mainly.

Google's translation isn't the best, but this part looks interesting:

"while if to throw it to my computer then after much deliberation it appears in the BIOS, but SandForce 25gb. Windows does not glruzitsya and indeed no system to boot (although with office site but the Linux boot loader utility can not see the screw.) On hot in windsurfing is defined as the SandForce drive."

It appears that if you try often enough, BIOS might eventually identify the drive correctly. In the above case a 40GB OCZ SSD is incorrectly identified as a 25GB. I'm wondering whether the Vio voltage is low in that case, too. It could be that some NAND chips are OK at the lower voltage while others may not be responding, in which case the controller powers up with a reduced array. As is to be expected, there is no access to the data in this mode.

I suspect that C18 may be the root cause of the problem. In fact I would be tempted to add a 1Mohm resistor in parallel with R22. This would increase the Vio by about 10%, from 2.8V to about 3.1V.

[HaQue]

I seem to have posting issues, so Ill try again.

yes it does seem like a solution is possible. I hope so. I was interested specifically in:

And get a clean log into the terminal is simple: to close contacts 2-3 on ATMLH008

then we may see the log and get a hint on what is borking the drive.

Very interesting discussion, I am keen to follow it to the end solution!