checked. maybe the struct doesn't reflect good data.

I can read SA with H0 H1 H2..so there must be only 3Heads

The drive came formatted so I did a HDTune scan under windows and it shows fine.

Hello i've WDC WD20EARS-00MVWB0_25.12E hard drive which burned the 12V TVS diode after power surge.
I replaced it and now the drive turns on again but bios detects it after a lot of seconds waiting, windows does not detect it.
MHDD sector scan stops every few seconds (and the busy light turns on), after few seconds the busy light turns off and sector scan runs again, then stops again after few seconds, and so on...

I tried to clone it but is very slow, stop and go every second.

I used Sediv and WDR 4.0 to do some test and P-list translators regen with WDR 4.0, but i get error 3C1D=FMT_ERR_FIELD-LIST_WRT_FAIL
The situation is still the same.
I tried also to reset G-list (which had 41 reallocated sectors) and smart, but nothing has changed.

I did some backups of loader and pcb firmware, and some modules but i don't know how to do internal firmware backup with WDR, does someone know how to backup the internal firmware?





SeDIV Backup


WDR 4.0 Backup


Hope somebody can help me to recover my data, thanks.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

I think the problem is due to pramp, because i alredy tried another pcb and did the firmware transfer with eeprom programmer, and it's the same...
Thank you.



Because it's not the first time i fix a WD with burned TVS diode, when it burns usually also translator get broken (due to a bad power supply), in fact the cloning on this drives is very slow and in some area it's impossible.
After rebuilding translator i got a good cloning speed in the past, but not this time

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Read all?
Where is this option, i can't see it

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

ok i will wait you to show me the pics.
Where can i find WDR 6.0?
i have only versio 4.0

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

I didn't know that version 6.0 was a pirated software...

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

it is possible to depop heads with WDR 4.0?
How can i do it?
Do you think may help depoping heads to get some data back?

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

@ michael ...please let my topic away. go make your own one.

now news.

got the programmer today. just for fun..the item arrived in town on 31 march..so I waited 5 days for 5km.

now..

found the problem. see the bricked rom and the original attached. there's a missing block of 512bytes 0x200. 3.0 missed one sector during flash!

don't know if there's a bug in the 3.0 or perhaps the windows trying to detect the device exactly during the device flashing. that's why it is better to "hide" the drive behind a box. windows won't know about the drive because this is handled by the box.

to remember..the problem was on the donor's pcb, which was bricked during playing with 3.0 while depoping one head.
after flashing a good rom and I was surprised that the donor drive acted like the dead one...changed the PCB from the old drive to the donor and nothing changed (last time I did that..the drive started..so i knew that should work). still dead..I mean..clicking 5 times..not finding SA!. then I said..that's it..the preamp has gone on this drive too. but after putting back its own pcb..I observed that I didn't tighten enough the screws. so I paid a little more attention when screwing and the drive started nicely. this is another possibility for a drive to appear as dead and clicking like not finding the SA.

with the programmer along, I did first test with my flash_write function. It was written some time ago but never tested I can say that after the write, the pcb doesn't reboot. so I can read again the flash and compare with the one I flashed..to check if match.

see the log:


and finally I attach an image with the programmer. the soic8 clip it's a little difficult to be placed on rom chip, and has the wires soldered in a way not compatible with my ST 25P10 so I had to use some wires to reorder where the pins go.

I've already put that in one function. Imagine that if it's not done automatically..You'd have to dump the rom..open a hexeditor..search the dir where the dump lies..search the original..compare..see the result

why do md5 hash since I compare byte by byte..the write_from buffer with the buffer holding the flash read after a successful write.

here I do exactly that, I mean..download the flash and compare it with what I wrote.


any good programmer's software has this option...to automatically check the flash after write.

@Louis

What's the situation with H1 ?

H1 of the donor..still dead

however, having now 2 hdd to plug into controller I have learned how to send commands to any of them. I implement functions but I test them and fix them as I have the occasion.



here's the donor and the other old model I purchased this week.

Here we go.

Now I'm speaking about donor's dead H1, or why I say it's dead.

why it's dead? attached a zipped file

I managed to read sector 1 and 2 at the beggining of the SA (cyl -1) with defective Head 1... resulting 2 files:
->dump_head1_cyl-1_sec1.bin
->dump_head1_cyl-1_sec2.bin

to obtain the mod_01 (dir module)..you should stick together the first 0x200bytes from both files. compare it to the original H0 mod_01.

I copied the files and called again the function. do the same with the files and compare the results.

you'll have H0 mod_01 (the good one), H1 mod_01, and mod_01_copy

each time I read H1 it will return BOGUS data. although there are some bytes that match the good data...those bytes are not FIXED. so.. it's not a defect on the platter. the data is corrupted somewhere between the [head and preamp].

say it's not like that

now you know what this means:

now I try to apply the same method to my dead HD (the one from which I've started this topic), but i get the perm_ovl_not_loaded error. the kernel needs some stuff inside SA to let me exec my function.

so I'm working at load permanent overlay function. my model it's not royl. basically I understand that this load perm overlay..maps the sata module 0x11 to the MCU's ram...it's another method to force loading some modules when they are not available in SA. I tested my implementation on the donor's PCB alone..and it loads its SA dumped mod 11 from a file. when I try the same thing on the dead hdd, I get a complain about "not compatible". obviously I used the donor's mod 0x11.

yeah..the mod 11 holds the zone table described here.

the kernel needs it to know the sectors per track (SPT)..and the lba start/stop for the Zone Zero (SA zone). I have loaded the mod 0x11 to my donor's pcb (not mounted on hdd) and after that I can read the Zone Table.....the kernel doesn't complain with perm_ovl_not_loaded

here's a 10 points question: if the head returns randomly good data...see the previous posts, then how the heck it is able to surf the Servo System...to find its tracks, because this involves reading the disk?

perhaps it tries many times until it finds the servo track...then find data tracks with a lot of work..since it returns a lot of bad bits. let's say..that after some percentage of errors it wouldn't be possible for the head to scroll through the tracks.

somethings not good.

I put my donor into "safe mode"...(all 4 jumpers set since it's a sata model). power up..it identifies as wdc rom..normally because it's in kernel mode, not spinning. then I load perm overlay. it loads it fine because it's saved from its SA. then I spin it up. then I try to access the SA and it does like the dead hdd. clicks and nothing. it seems that mod_11 isn't enough to let me access read the sa. so what else to do?

no..the donor seems to be dead. remember that I had few previously mentioned situations when the donor...acted like the dead drive. and I tighten the PCB screws and finally started. last night... had the same situation after swapping PCB's for testings..and when almost to give up..it started..but this time the trick with screw tightening...didn't worked

today..I've put all the jumpers at the back..and after that...it started to click..and I posted the situation (my last post). the rom it's fine. perhaps the connections of the PCB with the HSA are damaged since I did a lot of PCB swapping.

what's funny is that I load perm overlay then I call read head function..and then it starts spinning and it does exactly like the dead drive (5 times 3 clicks) and at the end returns success but the file it's filled with 0x00

"Are you talking about drive 2, right ?"

YES. that's the drive I'm working now. let's don't talk about flash. the flash operation was just fine and after that the donor worked fine. till I did some pcb swapping between donor-patient..to test some stuff.

more. just did a pcb swap..put the old pcb to the donor..and again dead (I said..give it one last chance). putting back it's pcb it started. so it's something with the screwing...cables f...I don't know..but its getting worse.

now the donor works. of-course with the H1 buggie but I'm afraid these are the final day for it


I want to start it in "safe mode" to test it...then load perm ovl..because I have its mods. then try to read SA, to see if it works.

to enter "safe mode" I inserted the4 jumpers at the back..and after that..it started to click as dead.

now it works but I'm not sure how..because I think I must delete some mods in order to test the perm_ovl thing. now..it starts as WDC ROM..and although I call load_perm_ovl..and then I try to read the SA...it works. but it works also without loading perm ovl... so I believe that the kernel tries to read its mods as soon as I call the Read_module. that's why I say that I must erase the SA and do the test