chk2xx.txt

lf2407自检源代码

               TMS320C2xx SELFCHECK PROGRAM APPLICATIONS BRIEF

                                 Version 1.0





                              DAVID M. ALTER
                          MEMBER TECHNICAL STAFF
                          SEMICONDUCTOR DIVISION
                             TEXAS INSTRUMENTS






































1.0 INTRODUCTION

    This program is designed to verify the operation of DSP devices in the
Texas Instruments TMS320C2xx family (including TMS320C24x) by checking for
proper operation of the CPU core and RAM.  On-chip peripherals are not
tested since doing so would be target system dependent.  It is important to
note that this program only provides a confidence check.  It is not as
comprehensive as the tests done at production, which thoroughly check the
devices logic, performance, and electrical parameters.  While every attempt
has been made to provide a compact selfcheck program that will exercise as
much of the device as is possible, this program is not capable of detecting
many potential faults.

    In this document, both TMS320C2xx and C2xx refer to any member of the
'2xx DSP family (e.g. C203, C204, C205, C209, C240, F206, F207, F240, ect.).
Also, TMS320C24x refers to the subset of '2xx DSPs belonging to the '24x
family (e.g. C240, F240, ect.).


1.1 SCOPE OF THE SELFCHECK

    This C-callable program utilizes nearly every C2xx instruction in every
applicable addressing mode (i.e. immediate, direct, and indirect).  These
instruction tests effectively check much of the DSPs circuit paths.  In
addition, each auxiliary register, on-chip RAM blocks B0, B1, and B2, the
hardware stack, status registers ST0 and ST1, and the scaling shifters are
checked.  Certain blocks of additional on-chip and external RAM can be
optionally tested.


1.2 SYSTEM REQUIREMENTS

    To use this code, you will need the following tools:

              TMS320C1x/C2x/C2xx/C5x Assembly Language Tools
              TMS320C2xx Simulator or XDS510 Emulator
              A suitable host PC to support the above tools

If you intend to call the selfcheck from a C-language program, you will
additionally need:

              TMS320C2x/C2xx/C5x Optimizing C Compiler


2.0 PROGRAM FILES

    The following files are included in this archival:

     ALU.ASM      ------  arithmetic operations module
     BASIC.ASM    ------  basic operations module
     BRNCH.ASM    ------  branch instructions module
     CHK2XX.ASM   ------  program control shell
     CHK2XX.TXT   ------  this text file
     CTRL.ASM     ------  control instructions module
     DATA.ASM     ------  data memory operations module
     MAKECHK.BAT  ------  DOS batch file to assemble and link the code
     MEMMAP.H     ------  include file containing constant definitions
     MULT.ASM     ------  multiplier operations module
     OPTIONS.H    ------  include file containing user setable options
     RAM.ASM      ------  RAM check module
     READ.ME      ------  readme text file
     SHFT.ASM     ------  scaling shifter operations module
     USER.C       ------  sample C program that calls the selfcheck program
     USER.CMD     ------  sample linker command file for use with USER.C


2.1 HOW TO CALL THE SELFCHECK PROGRAM

    The selfcheck program is designed to be C-callable, although it can also
be easily called from assembly code.  The files USER.C and USER.CMD are
provided as examples of a selfcheck calling C program and its linker command
file.  If the selfcheck passes, it will use the accumulator to return a pass
code to the calling routine.  If the selfcheck fails, it will either use the
accumulator to return an error code to the calling routine, or it can
optionally lockout the calling routine.  The use of the accumulator to pass
the return argument is the standard convention for the TMS320C2xx C
language.  Assembly code users should simply expect to find the returned
value in the accumulator.

If calling the selfcheck from C code, use a statement of the form

                          errorcode = chk2xx();

where errorcode has been declared as an unsigned integer.  The C language
function prototype for the selfcheck routine is:

                          extern unsigned chk2xx(void);

If calling the selfcheck from assembly code, use the following instruction:

                          CALL    _chk2xx

The leading underbar in _chk2xx above is not a typo, and must be included.


2.2 ASSEMBLING AND LINKING THE CODE

    The file MAKECHK.BAT is a DOS batch file that will assemble and link the
various program modules for you.  It assumes that the selfcheck program is
being called from the C program USER.C, and uses the linker command file
USER.CMD.  It requires the program files to be in the current directory, and
the directory containing the TMS320C1x/C2x/C2xx/C5x Assembly Language Tools
to either be in the current directory or be listed in the DOS path.  The
MAKECHK.BAT batch file is as follows:

         dspa chk2xx -v2xx -l -x
         dspa basic  -v2xx -l -x
         dspa data   -v2xx -l -x
         dspa ctrl   -v2xx -l -x
         dspa brnch  -v2xx -l -x
         dspa alu    -v2xx -l -x
         dspa mult   -v2xx -l -x
         dspa ram    -v2xx -l -x
         dspa shft   -v2xx -l -x
         dspcl -c -v2xx user.c
         dsplnk user.cmd -c -l rts2xx.lib -o user.out -m user.map


    The dspa commands invoke the TMS320C1x/C2x/C2xx/C5x assembler.  The
first parameter is the name of the source file to be assembled.  The .ASM
extension is assumed by the assembler.  The -v2xx parameter tells the
assembler to generate TMS320C2XX object code, as opposed to TMS320C1x,
TMS320C2x, or TMS320C5x code.  The -l parameter (lower case L) generates a
listing file (.LST) file, and the -x parameter generates symbol cross
references in the listing file.

    The dspcl command invokes the TMS320C2x/C2xx/C5x Optimizing C Compiler
to compile the C-program USER.C.  The -v2xx parameter again tells the
assembler to generate TMS320C2XX object code, and the -c parameter disables
linking.  The last command, dsplnk, invokes the TMS320C1x/C2x/C2xx/C5x
linker.  The first parameter "user.cmd" is the name of the linker command
file.  This file lists the names of the object files to be linked, as well
as the desired memory mapping.  The -c parameter says to use the ROM
initialization model, and the "-l rts2xx.lib" links the program with the
required C-environment initialization routines (rts2xx.lib is a library file
that comes with the C Compiler).  The "-o user.out" specifies the name for
the executable file, and the "-m user.map" specifies the name for the output
map file.

You should replace USER.C and USER.CMD with your own custom routines as
necessary.  If you instead wish to call the selfcheck from assembly code,
say the files YOURFILE.ASM and YOURFILE.CMD, also modify the last two lines
of MAKECHK.BAT so that YOURFILE is assembled and linked.  For example:

         dspa chk2xx -v2xx -l -x
         dspa basic  -v2xx -l -x
         dspa data   -v2xx -l -x
         dspa ctrl   -v2xx -l -x
         dspa brnch  -v2xx -l -x
         dspa alu    -v2xx -l -x
         dspa mult   -v2xx -l -x
         dspa ram    -v2xx -l -x
         dspa shft   -v2xx -l -x
         dspa YOURFILE -v2xx -l -x
         dsplnk YOURFILE.CMD -o YOURFILE.OUT -m YOURFILE.MAP


2.3 HOW TO ALLOCATE MEMORY FOR THE LINKER

    The selfcheck program destructively overwrites all RAM locations that it
either tests or uses.  These include on-chip blocks B0, B1, and B2, and all
optionally tested on-chip and external blocks.  The only exceptions to this
are data memory locations 6Fh through 77h, which are located in block B2 and
just happen to be preserved by the coding employed.  For this reason, no
programs should be loaded nor any data sections initialized in tested RAM
prior to running the selfcheck program.  They will be lost!  Here are
several suggestions for allocating and running the selfcheck:

1) Link and run all code from external RAM (or ROM), and do not exercise the
external RAM test option on the used portion.

2) TMS320C209 users can run the program from its on-chip SARAM block.  Do
not exercise the option to test this block.  

3) Users of TMS320C2xx devices that contain sufficient on-chip SARAM can run
the program from this block (similar to the TMS320C209).

4) If running the selfcheck as auxiliary support for some other primary
application program, one option is to run the selfcheck using one of the
above three linker methods before bootloading the code and initializing the
data for your primary application.  This will require you to modify your
bootloader.


3.0 WHAT IS TESTED

    The selfcheck program is designed to verify the operation of DSP
devices in the Texas Instruments TMS320C2xx family by checking for proper
operation of the CPU core and on-chip RAM blocks B0, B1, and B2.  Certain
blocks of additional on-chip and external RAM can be optionally tested. The
code was written using nearly every instruction in every addressing mode
(e.g. immediate, direct, and indirect addressing).  The only instructions
not tested are IDLE, IN, INTR, NMI, OUT, and TRAP.  The code is designed to
check for proper instruction execution rather than merely using the
instruction.  For example, the conditional branch instruction BCND has been
implemented to both branch and not branch in the code.  The instruction
tests effectively check much of the DSPs circuit paths.  In addition, each
auxiliary register, the on-chip RAM, the hardware stack, status registers
ST0 and ST1, and the scaling shifters are checked.  Verification of the
selfcheck program integrity in RAM can also be optionally performed.

    No on-chip peripherals are tested since doing so would be target system
dependent.  These include, but are not limited to, any serial ports, timers,
and general purpose input/output pins.  If the selfcheck is executed from
off-chip, the external interface and wait state generator will be exercised
for the program space.


3.1 HOW IT IS TESTED

    The selfcheck program tests the CPU by exercising a component of the CPU
and then verifying the correct result.  When an incorrect result occurs, the
program loads an unsigned error code into the accumulator, aborts further
selfcheck execution, and then either returns to the calling program or
optionally locks it out.

    A non-destructive hardware stack check is performed in the module CTRL.
The entire stack is saved to data memory prior to it being tested.  Data
values are then pushed onto all eight stack levels, and popped and sum-
checked to verify correct operation.  At the completion of the stack check,
the original stack is restored.

    RAM is tested using a checkerboard pattern.  This test sets every other