OCZ Vertex 2 240GB SSD for recovery

[hhddrec]

Onother One:

but if power up SSD wait for a second (red diode ligth for a second and them red diode not ligth for a second too) and just (in that moment when not ligth red diode) short pins 2-3, Green diode is ligthing and Red diode is ligthing, and no BIOS info neither.

Attachments

[hhddrec]

BUT, (and here is the GOOD NEWS!) when i short pins 2-3 and them power up SSD the green diode is ligthing but Red diode not ligthing
them if i not short SSD only green diode continues ligthing. and YES, there is BIOS info.!!!!!

is recognized by BIOS As SandForce!!!!

Attachments

[hhddrec]

BUT, (and here is the GOOD NEWS!) when i short pins 2-3 and them power up SSD the green diode is ligthing but Red diode not ligthing
them if i not short SSD only green diode continues ligthing. and YES, there is BIOS info.!!!!!

is recognized by BIOS As SandForce!!!!

Do you think i can upgrade FW in this situation?

Thaks.

[fzabkar]

AISI, shorting the EEPROM after the controller has powered up is inconclusive, and perhaps pointless. I could be wrong, but AIUI, the controller looks for the EEPROM and then downloads the EEPROM's code into the controllers's internal SDRAM. The controller than transfers control to the SDRAM code. After this happens, the EEPROM is no longer accessed by the controller, so shorting its pins would have no effect.

Instead you need to short the pins before powering up, as you have already discovered. Power-up is the time when the controller is looking for the EEPROM. When the controller doesn't find the EEPROM, it reverts to kernel mode, in which case it would be running on its own internal bootstrap code.

Your test proves that the controller is not being reset by the POWR607 supervisor IC, so the 2.8V supply voltage may not be a problem now, although it may have been a problem in the past.

[hhddrec]

AISI, shorting the EEPROM after the controller has powered up is inconclusive, and perhaps pointless. I could be wrong, but AIUI, the controller looks for the EEPROM and then downloads the EEPROM's code into the controllers's internal SDRAM. The controller than transfers control to the SDRAM code. After this happens, the EEPROM is no longer accessed by the controller, so shorting its pins would have no effect.

Instead you need to short the pins before powering up, as you have already discovered. Power-up is the time when the controller is looking for the EEPROM. When the controller doesn't find the EEPROM, it reverts to kernel mode, in which case it would be running on its own internal bootstrap code.

Your test proves that the controller is not being reset by the POWR607 supervisor IC, so the 2.8V supply voltage may not be a problem now, although it may have been a problem in the past.

THANKS FRANK

and Do you think i can upgrade FW in this situation?

[fzabkar]

I don't know, and I don't know whether it would make any difference. I can only help with electronic faults.

FWIW, I see a lot of "sleep and die" complaints in OCZ's forum, so it does appear that your problem may be a common one.

[hhddrec]

I don't know, and I don't know whether it would make any difference. I can only help with electronic faults.

FWIW, I see a lot of "sleep and die" complaints in OCZ's forum, so it does appear that your problem may be a common one.

Thanks Frank

I tested FW update, but not posible.

[hhddrec]

BUT, (and here is the GOOD NEWS!) when i short pins 2-3 and them power up SSD the green diode is ligthing but Red diode not ligthing
them if i not short SSD only green diode continues ligthing. and YES, there is BIOS info.!!!!!

is recognized by BIOS As SandForce!!!!

In This Status is recognized be Windows too, but i can not access to data

Any new Idead?

Thanks

Attachments

OCZ_WindowsAdministrativeTools.JPG (29.04 KiB) Viewed 8773 times