Hi guy i am wondering if somebody can point me in a good direction.

I found tx+/- rx+/- but i coudn't find GND.

THis is a new model of pcb from WD7500

Couldnt you use any ground point?

Or

Hi Loki, i did follow that schema indeed.
but i have got no good result. i am thinking this version of pcb has got something different for tx-rx than usually E71,72,73,75 point...
if u look my pcb is different from that one...

Your PCB has code 771754. You can use SATA PCB from SATA Zephyr model , like WD6400BPVT-22HXZT1 for example. Should have PCB Code 2060-771692-005

thanx, but something is not working.

i used a Zephir-one (what i have in stock is WD5000BPVT-00HXZT1) and drive is clicking.

i also noticed that patient drive is not a Zephir, but a Helios.

Did you transfer ROM?

ROM determines family not PCB code.

i did it, but when i checked, i found that i did not.

anyway i try to write rom again, but i got this message:

Invalid data size (262144). Expected (524288)

yes, becouse Zephir has got 512kb!

You cannot write it, you need transfer ROM chip @ U12

Is that complaint coming from your software or from the target drive?

What would happen if you padded the 256KB image with 0xFF bytes to create a 512KB image?

_________________
A backup a day keeps DR away.

If you are concerned as to the location of the Tx/Rx pairs, then follow the traces between the MCU on your SATA-only PCB all the way to the SATA data connector. Then trace these same MCU pins to the E7x test points on the USB PCB.

I'm assuming that the two boards will be using the same MCU (88i9146-TFJ2).

_________________
A backup a day keeps DR away.

@fzabkar

None of this is required. All that is needed is to physically move the ROM from USB PCB to SATA PCB. Safer, faster and simpler

I am trying this, but in WD PCB usb the U12 is a phisically different from U12 in donor.

Yes, I know. This is not a problem, just make sure it is aligned properly when you place patient ROM on donor PCB (probably you have to change orientation to match SATA PCB)

So are you saying that it doesn't matter that the capacities and part numbers of the two devices are different? If so, then writing the ROM would be much safer and simpler than physically moving it. That's why I suggested padding the contents. In this way the diagnostic software would be kept happy.

_________________
A backup a day keeps DR away.

No, does not matter. I have already met success in swapping ROM from 771754 (USB) to 771692 (SATA) several times

I see your logic, and makes sense, but for me I have never tried padding excess space in ROM because I have not met the need. But I am aware of this as a viable option.

For me transfer ROM from patient to donor is always easier, except cases like Shasta where ROM is internal...

It is not a matter.


Completely correct.

IMO transferring the original ROM from patient to donor is much safer. Even a low-skill technician could do that simply with an eight-legs chip.

If the original board is damaged beyond feasible repair, then a physical transfer would be your only option. Otherwise, if the ROM is readable in-circuit with your software tools, then prudence (standard practice ?) would dictate that you make a backup of its contents. Consequently, if you can backup (ie read) the ROM in-circuit, it stands to reason that you should also be able to write it in-circuit with the same tool. This begs the question, why would anyone, even a highly skilled technician, risk applying a soldering iron to the board? The idea that a physical transfer is somehow safer that a software approach strikes me as absurd, unless the software tool is unreliable. Is that the explanation, ie that your software tools are "unsafe"?

Otherwise, do you have a problem with the procedure for padding the 256KB ROM? Or do you have a concern in regard to the ROM's checksum?

If you have difficulty padding your ROM image, and if you are a Windows user, then cut-and-paste the following code into a BAT file. You will need to edit the last line with your applicable file names.


Alternatively, if you have a concern in regard to the ROM's checksum(s), then surely your expensive software tool will be able to validate the integrity of the code?

_________________
A backup a day keeps DR away.

@ hddguy

Thanx for pointing!

@ Frank

Suggestion clever.


All data recovered, customer will be happy

Would a 771672 (full code 2061-771672-001) from a WD6400BEVT-22A0RT0 do, instead of a 771692?