Thanks Randy


Good suggestions



yes the best analisys, thanks Frank



I think measure here. What you think?

see picture

Thanks to you, fzabkar too.

You you'd never alone!



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

Thanks arvika



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

Thanks BlackST




I untherstand you

I am with tou Frank


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

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.

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,

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.

_________________
A backup a day keeps DR away.

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

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?

_________________
A backup a day keeps DR away.

Seems that healing firmware problem by measuring Vcc is not working

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

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

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".

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. :-)

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

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.

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.

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

then:

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:



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


lol at OCZ answer: seems DR companies arent needed or wanted...

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


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.

_________________
A backup a day keeps DR away.