WD 2060-80067 P1, damaged board. ROM & MCU transfer

E

eastcoast

New member
Normally for these, we use an unlocked SATA board, backup SA, fix firmware, lock UA and generate a head map.

Then start a new DE task with USB original board to get data either via USB Stabilizer or USB port on PC3K portable. I know we can now write back unlocked ROM to USB PCB using Ace utility, but I prefer the way I have been doing it as I feel it's safer rather than playing around with customer ROM.

Now this case has a trashed PCB that the customer has been bending on the connector so it ended up breaking traces somewhere in the board possibly under the surface. No obvious shorted components.

As the board was too damaged for a decrypting board or a manually wiring SATA connector, ]it was decided to move MCU and Rom to another board.

This has been attempted a few times, but although it IDs, the drive never actually starts to spin.

Did anyone get a suggestion as to why? We are suspecting the PCB compatibility has to be more than just the same version number as we have noticed variations in the components, but would it have to be matched on more, i.e. other chips?

It does spin with SATA unlock board but all UA sectors are of course encrypted.

We are suspecting that possibly the MCU is toast or has been damaged which means data is lost.

Appreciate any feedback or advice.

Thanks
 
E

eastcoast

New member
Just in a way of update.

Performed another reball to yet another board and this time it worked fine. It was our last-ditch attempt to be honest.

The drive spins with ID, but presents with a Smartware Password prompt when plugged into the USB Stablizer. Unfortunately both passwords from customer don't seem to work. I guess nothing is straightforward anymore.
 
E

eastcoast

New member
Amarbir,

I'm going to PM you . Some of the steps may be wrong and still need verification and I wouldn't want to share the wrong info.

I suspect the user password set on SED or on WD Security has different levels and whatever was set, PC3K could get around, or maybe the drive thought it had a password but none was set. I haven't actually encountered it too much or have always had a password supplied that worked. I'm going to try it on some test drive to see if i can "unlock" it using the same method.

Thanks

Louis
 
Last edited:
You must log in or register to reply here.
Top