BAM to uncover a problem

STB Suite | The Industry Standard in Peripheral Testing.

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.

 

Summary:

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!