XDS-510/XDS-510WS  Diagnostic  Utility
xds_diag.txt            Version 1.5  1/24/98  17:38:46

         Copyright 1995, 1996 by Texas Instruments Incorporated


INTRODUCTION
------------
There are currently two versions of XDS_DIAG:  
    - For the XDS-510WS on SparcStations running SunOs 4.x or 5.x.
    - For the XDS-510 on PCs running Windows 3.1 or 95.

These programs are intended to help diagnose problems with setting-up
the XDS-510 or XDS-510WS Emulator. They may not be able to solve all
the problems you have, but it can detect a good number of them.  This
program can perform the following actions:

    - Check the XDS-510 or XDS-510WS scan controller and determine
      it's revision.

    - Check the scan configuration file (usually board.dat) and
      display information about the expected devices on the scan path.
      Refer to the Debugger User's Guide for more information about
      the scan configuration setup.

    - Determine the number of devices on the scan path. 

          The scan path consists of one or more JTAG devices which 
          are connected in a serial fashion to the same emulator 
          header of a target system.  XDS_DIAG can determine the
          number of these devices by scanning the JTAG instruction 
          'BYPASS' into all the devices causing each device to
          contribute a single bit to the scan path.  By counting
          the number of bits on the data path, the number of devices
          is determined.

          For more information on JTAG/MPSD, refer to the "JTAG/MPSD
          Emulation Technical Reference" that you should have received
          with your XDS-510.

    - Verify scan path integrity. 

          A large number of scans are done using various patterns. 
          The data received is then compared against the data sent. 
          If bits have been corrupted, this indicates potential
          electrical issues.

    - Determine core revisions for supported TI devices (TMS320C2xx, 
     '4x,'5x,'54x,'c6x,'c8x,370C8,370C16 and 470).

    - Continuously scan a pattern through the scan path, allowing for a
      logic analyzer or oscilloscope to be used to check TDI and TDO of
      target devices.

IMPORTANT NOTES:
----------------

    - This is a generic utility, intended for several different
      processors. Thus, the documentation will often just refer 
      to the "device or the "debugger". It is referring to whatever 
      device/debugger you are trying to use (i.e. TMS320C209 or a
      TMS320C6X etc.).

    - Continuously scanning a pattern can be aborted by turning off
      the emulation hardware. This will introduce an error and the
      program will abort.  Disregard the error message in this 
      case.

    - Scan path linkers and other JTAG devices which control the scan
      path are not supported. Also, this utility will not
      handle scan paths correctly if these devices are present on
      the target system's scan path.

    - If you are running this utility on a PC, it is not necessary
      to run 'EMURST'.  On the Sun, however, it is necessary to run
      'emurst xds510ws.out' before using this utility.


INSTALLATION INSTRUCTIONS FOR WINDOWS
--------------------------------------

Note: if your debugger came with an install utility, XDS_DIAG may 
      have been installed for you.  Check for a program item named
      XDS_DIAG in the same group as your debugger.  

1) Copy "xds_diag.exe" into the run directory for the debugger
   you are setting up (refer to your debugger documentation for
   information on installing the debugger software).

2) Set up a program manager "New Program Item". The Program Item
   properties should be:

        Description:        XDS_DIAG
        Command Line:       XDS_DIAG.EXE <arguments>
        Working Directory:  <Debugger run directory>
        Shortcut key:       None

   Do not run minimized. Pick an icon of your choice.

   The command line arguments should be the same as the ones used to
   invoke your debugger.  These and additional arguments are 
   discussed later in this file.

   If you haven't tried to set up your debugger, read through the
   "Installation Guide" for it and follow the instructions.
   Pay close attention the section on setting up the Debugger 
   Environment. Then read through the first chapter or so of the 
   Debugger's User Guide 


INSTALLATION INSTRUCTIONS FOR SUN
---------------------------------

1) Copy "xds_diag" and "xds510ws.out" into the run directory
   for the debugger you are setting up (refer to your debugger 
   documentation for information on installing the debugger software).

2) Run "emurst [-p port] xds510ws.out" to download "xds510ws.out"
   to the XDS-510WS. Then run "xds_diag <command line arguments>"
   where the command line arguments are those that you would use
   with the debugger you're trying to set-up. See below.


COMMAND LINE ARGUMENTS
----------------------
These are passed on the command line to the program. Most of these are
similar to those used by the debugger and/or EMURST.EXE.

  -p <port>  Identify the I/O port address the XDS-510 is at (see
             the Installation Guide for the XDS-510 or Debugger for
             info on this). Possible port values are:

                -p 0x240    Default for XDS-510 only
                -p 0x280    XDS-510 only
                -p 0x320    XDS-510 only
                -p 0x340    XDS-510 only
                -p 4        Default for XDS-510WS only
                -p [1-7]    XDS-510WS only

             If you do not know which one of these is right, you'll
             need to remove the XDS-510 from your system and check
             it's jumper settings. If you're using an XDS-510WS,
             use the SCSI ID on the front panel of the XDS-510WS.

  -f <file>  Identify a board configuration file instead of
             board.dat.  You can include directory information,
             For example: "-f c:\c2xx\board511.dat"

  -n <name>  Identify the processor to debug. This is used by the
             debugger, but isn't really necessary for this utility.
             If you do specify it, and it's wrong (there's no such
             device in the board configuration file), then this
             utility will tell you that there is an error.

  -v <num>   Perform a scan chain integrity test as part of the
             diagnostics. Use 'num' to specify the number of times to
             run the test. 

  -c         Continuously scan a pattern through the scan chain. This
             will not run the normal diagnostics.  More detail about 
             this option is given later.

  -d <value> Specify a data pattern instead of 0xAAAA to continuously
             scan through the scan chain. More detail about 
             this option is given later.

  -x         Ignore D_OPTIONS.  The environment variable D_OPTIONS is
             used after the command line is parsed.  By using the option
             -x you will ignore D_OPTIONS and only use the command line
             arguments.  It is strongly recommended that you do not use
             D_OPTIONS.  To check and see if D_OPTIONS is set, type
             'SET' at a DOS prompt.  This will display a list of all
             DOS environment variables.


WHAT THE DIAGNOSTIC DOES (IN DETAIL)
------------------------------------
- Attempts to initialize the scan controller. 

      If this fails, you will see a message like:

      *** Scan controller won't open

  This usually indicates a problem like no target power or a bad 
  I/O address specified for the XDS-510 or XDS-510WS. 

- Resets the scan controller, and then retrieves its revision. 

     If this fails, you will see a message like this:
     *** Scan controller failed diagnostics.
     and then some suggestions on what may have caused the problem. 

     If it succeeds, you will see the XDS510 Revision (probably 3) 
     and the TBC revision (probably 2).

     If you have reached this point, the XDS-510 is probably OK.

- Scan a continuous pattern (option -c or -d).

      If you have specified the "continuous cycle" option (-c), 
      the XDS-510 will be scanning the fixed pattern 0xAAAA through the 
      JTAG scan path.  You can specify a pattern other then 
      0xAAAA by using the -d <value> option.

      Why continuously scan a repeating pattern through the JTAG scan
      path? So we can look at it with an oscilloscope (a logic analyzer
      works too).

      Here's what we can check out:

      Refer to the JTAG/MPSD Emulation Technical Reference and the
      diagram for the Target System's Emulator Connector. 

      View TCK and TCK_RET using an oscilloscope. TCK should be a 10MHz
      clock. TCK_RET will also be a clock (usually 10Mhz, since it's
      common to connect TCK_RET to TCK).

      Check TRST- on the emulation header. It should be high. If you
      watch this signal when the utility first starts up (and 
      initializes/resets the scan controller) you'll see it go low 
      (resetting the JTAG TAP) and then high.

      Check TMS. While continuously scanning it should be low. It may go
      high when the scan controller is not scanning (it's reloading).

      Next, look at TDI on the emulation header. If the data pattern is
      0xAAAA, we'll see an alternating 1's and 0's (the rate will be 
      half that of TCK_RET, since one clock the value will be 1 and the
      other will be 0).

      Now check TDO on the emulation header. This should be the same 
      repeating data pattern (delayed by the device).  If it is not,
      then there is a disconnect somewhere in the scan chain! Check the
      TDI and TDO of the first device. If you find that data goes into
      the chip, but never comes out, you've found the disconnect (and 
      the reason why the emulator does not work).

      Once you're in continuous scan mode, the only way to abort it to
      turn target power off (at which point you'll see some scan 
      controller errors displayed) or to terminate the XDS_DIAG 
      application by using Ctrl-Alt-Del.

- If you did not specify the continuous cycle option, XDS_DIAG will
  then read in the scan configuration file (usually board.dat). 
  It will list the devices on the scan chain, giving their name and
  device type, in a form like this:

    0) cpu_a is a TMS320C6x (class 0x600) <--- TARGET PROCESSOR

  (Ignore the class info - that's for internal debugging)

- If there are no scan path linkers as part of the scan path described
  in the configuration file, XDS_DIAG will now attempt to determine how
  many devices are actually on the scan path. It does this by scanning
  the BYPASS instruction into all JTAG devices (which selects the
  BYPASS data path, which is always 1 bit long). It will display
  the info in the following format (the data shown is what would be
  expected if there is just one device on the scan path):

    Initial IR scan path length: 0x8 (8)
    Initial DR-BYPASS scan path length: 0x1 (1)

  If the information displayed is obviously wrong (the numbers are
  negative or extremely long), then there is probably a problem with
  the JTAG interface. Use the continuous cycle option to determine if
  there are problems with the JTAG interface in some portion of the
  scan chain.

- If the scan integrity check option (-v <num>) was used, XDS_DIAG
  will then scan several different data patterns through the scan
  path, checking if any of the bits are ever corrupted. The following
  message will be displayed:

    *** Testing scan path integrity over time.

  and then listing the number of times the test will be run. A '.'
  will be outputted to the screen after each test. If any bits are
  lost, a message of the form:

    *** Scan chain losing 0.40% data during scans

  (the number of bits lost will vary, depending on how many data was
  lost). It will also display for each word with corrupted bits what
  the data scanned in and scanned out where.

  !! This scan integrity test will find some problems, but certainly
  !! not all. If you suspect that there could be issues with device
  !! or system activity interfering with emulation, run this test
  !! while the device/system is performing those actions which may
  !! interfere.

- If there are no scan path linkers, and the number of devices on
  the scan path (as determined at an earlier stage) match the
  number in the board configuration file, XDS_DIAG will now attempt
  to determine the core ID and other information from each device
  on the scan path that it supports. Supported devices are listed
  below. If the board configuration file info didn't match or you
  didn't specify one, then you'll see the following message:

    No/invalid board configuration file, so we'll
    be trying to determine the system
    configuration.

  Please note this feature is only supported on the Sun.  If you
  run XDS_DIAG on the PC it will not try to create a board.dat.

- The message:

  *** Diagnostics complete

  indicates that XDS_DIAG is complete. You can expand/scroll through
  the window to look at all the results. Select "File | Exit" to
  terminate the application gracefully.


IN CLOSING
----------
We hope that this utility has helped you diagnose any problems with your
debugger.   

