There are many times when errors occur during your testing, and the error can NOT be uncovered via simple means (for example via analyzing a logfile). When these difficult errors do occur, we recommend you take a BAM trace.
Description of the Problem
The testing being done was doing a Purge of SATA drive via the WriteSame command. About 36 minutes into the Purge, the Purge failed. No identifiable reason accounted for the failure – the drive was in perfect condition! The drive had succeeded the Purge Test several times before! So what caused the failure?
How we uncovered the Problem
We took a BAM trace and we could immediately see what caused the failure – it was the PnP Driver issuing a Read command to the drive – any SCT command to a SATA drive can NOT be interrupted in such a way.
Let’s take a look at the BAM trace – in the picture below we see the software issuing a “Get Status” command (i.e. the command “A1 08 0E D5 01 …”)to the SATA drive:
In the picture above, opening up the “Raw Data” tab, and then clicking on Ctr=65519, you can see at byte 14 is the value “FF” – this means “The command is still in progress” (in our case, the SCT WriteSame command was still in progress).
BUT then sometime later, the PnP Driver issued a Read command to the drive, as you can see in the picture below (see Ctr=65528):
In the picture above, right after the “Read (16)” command occurs, the very next “Get Status” command shows the SCT command was aborted. Click on Ctr=65534, and notice now byte 14 of the data is now “08” – this means the SCT command was aborted.
Anytime you encounter an error which can NOT be explained, always take a BAM trace to see what is happening “behind the scenes”. With practice, the BAM trace can become an incredible tool for error diagnosis!