Corrupt Seagate V15 ROM

[fzabkar]

I think the only proper thing to do is for your colleague to make restitution to your client. This kind of damage is inexcusable.

[ddrecovery]

I think the only proper thing to do is for your colleague to make restitution to your client. This kind of damage is inexcusable.

In one of your recent posts you said it might be fixable.
I am guessing from this last post that you don't think it is....
And I think we need to get a more fuller story before we start throwing people under the bus.

[fzabkar]

I think the only proper thing to do is for your colleague to make restitution to your client. This kind of damage is inexcusable.

In one of your recent posts you said it might be fixable.
I am guessing from this last post that you don't think it is....
And I think we need to get a more fuller story before we start throwing people under the bus.

It's a man-made fault. That much is indisputable. I could probably fix the SAP. The RAP is tougher because it is a much larger segment and because it is only partially duplicated in the extra space. One could probably make a good attempt by comparing the damaged RAP against the donor, but there is always the risk that an incorrectly repaired critical parameter (eg fly height) may have catastrophic consequences.

I have provided the tools to rotate or shift files by a user specified number of bits. I have also provided the info on where to find the RAP and SAP copies. If you or your friend feel like undertaking this task, then good luck to you.

[ddrecovery]

Yep. We don't give up that easily. Thanks for the help. Much appreciated.

[pepe]

It would be nice if everybody ever touching any pcb for reading rom would read it several times (for compare or at least check checksum which good tools should show) and not write anything back before making sure their read is ok.

:s

[fzabkar]

It would be nice if everybody ever touching any pcb for reading rom would read it several times (for compare or at least check checksum which good tools should show) and not write anything back before making sure their read is ok.

:s

One would think that this would be standard practice. Apparently not. F3RomExplorer is free ...

[Lardman]

Stupid question - might it be worth check with the person who read the ROM that the read file is the same as the rom, I assume the issue could just as easily be on the write as the read operation.

[ddrecovery]

Stupid question - might it be worth check with the person who read the ROM that the read file is the same as the rom, I assume the issue could just as easily be on the write as the read operation.

Not a stupid question at all. Both copies are the same.

[fzabkar]

If clock pulses were lost during writes, then the bits would be shifted in the opposite direction.

[pepe]

write ops are usually verified by the programming tool, so a mistake remains less probably unnoticed...

[fzabkar]

To me, the strange thing about the corruption is that a bit shift doesn't propagate all the way to the end of the ROM. I would have thought that each successive bit shift would accumulate. Instead, I see that the CRC bytes are at the correct location at the end of each broken SAP segment. This tells me that the read data are randomly and periodically resynced. By randomly, I mean that the resyncing doesn't occur on block boundaries but occurs anywhere within the segment. This makes the repair a great deal more difficult.

[Doomer]

To me, the strange thing about the corruption is that a bit shift doesn't propagate all the way to the end of the ROM. I would have thought that each successive bit shift would accumulate. Instead, I see that the CRC bytes are at the correct location at the end of each broken SAP segment. This tells me that the read data are randomly and periodically resynced. By randomly, I mean that the resyncing doesn't occur on block boundaries but occurs anywhere within the segment. This makes the repair a great deal more difficult.

People often use pogo pins to read ROMs, and they are often hand held. One slip of a hand and the ROM is corrupted. Another problem is using incorrect voltage on the programmer.
I've seen this before.

[fzabkar]

To me, the strange thing about the corruption is that a bit shift doesn't propagate all the way to the end of the ROM. I would have thought that each successive bit shift would accumulate. Instead, I see that the CRC bytes are at the correct location at the end of each broken SAP segment. This tells me that the read data are randomly and periodically resynced. By randomly, I mean that the resyncing doesn't occur on block boundaries but occurs anywhere within the segment. This makes the repair a great deal more difficult.

People often use pogo pins to read ROMs, and they are often hand held. One slip of a hand and the ROM is corrupted. Another problem is using incorrect voltage on the programmer.
I've seen this before.

I can't see how that explains my observation about resyncing.

[SWM]

Data exchange with flash via SPI occurs in blocks.
The size of the blocks depends on the algorithm.
With each command, synchronization is restored.

[fzabkar]

Data exchange with flash via SPI occurs in blocks.
The size of the blocks depends on the algorithm.
With each command, synchronization is restored.

That's what I expected. But look at where the resyncing is actually occurring. It's not happening on block boundaries.

[fzabkar]

Data exchange with flash via SPI occurs in blocks.
The size of the blocks depends on the algorithm.
With each command, synchronization is restored.

That's what I expected. But look at where the resyncing is actually occurring. It's not happening on block boundaries.

I was wrong. The resyncing occurs because the two copies are now both shifted by 1 bit. I had mistakenly assumed that both copies were realigned to the actual data.

When I cut the ROM in half and compared both halves, I found that the data were aligned at 0x1000-byte boundaries.

[ddrecovery]

Thanks for working on this everyone, it's much appreciated.
I had a feeling it was something you would love to get your teeth into
While the circumstances could obviously be better, its good for us all to learn.

[fzabkar]

ISTM that the data are shifted in both directions. That is, the data that were written to the ROM differ from the data that were read. I would contact your colleague and ask for their original read dump, assuming they still have it.

Good data

Code:

08 87 11 00 50 87 11 00

Bad data -- left shift 1 bit

Code:

11 0E 22 00 A1 0E 22 00

[ddrecovery]

I have been told the ROM is the original read.

[fzabkar]

What do you get when you read it? If we can't be sure which data are good and which are bad, then the recovery will be even more difficult. I've looked at the RAP and so far most of it seems good, at least as far as bit shifts go.

I'm assuming that any data after a 0x1000-byte boundary is good.