WD usb to sata new model of pcb

[positivebit]

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

Attachments

[loki]

Couldnt you use any ground point?

Or

[positivebit]

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

[hddguy]

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

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

[positivebit]

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.

[hddguy]

Did you transfer ROM?

ROM determines family not PCB code.

[positivebit]

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!

[hddguy]

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

[fzabkar]

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

Invalid data size (262144). Expected (524288)

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?

[fzabkar]

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

[hddguy]

@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

[positivebit]

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

[hddguy]

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)

[fzabkar]

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

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.

[hddguy]

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

[hddguy]

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.

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

[unknown]

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

It is not a matter.

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)

Completely correct.

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

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.

[fzabkar]

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.

Code:

echo f 100 80FF FF > 32K_FF.dbg
echo rcx >> 32K_FF.dbg
echo 8000 >> 32K_FF.dbg
echo n 32K.bin >> 32K_FF.dbg
echo w 100 >> 32K_FF.dbg
echo q >> 32K_FF.dbg
debug < 32K_FF.dbg
del 32K_FF.dbg
copy /b 32k.bin + 32k.bin 64k.bin
copy /b 64k.bin + 64k.bin 128k.bin
copy /b 128k.bin + 128k.bin FF_256K.bin
for %%i in (32 64 128) do del %%ik.bin
copy /b rom_256K.bin + FF_256K.bin rom_512K.bin


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?

[positivebit]

@ hddguy

Thanx for pointing!

@ Frank

Suggestion clever.


All data recovered, customer will be happy

[ciccillover]

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