Compiler

Bug Description

The code generator is incorrectly generating a SUBF3||STF
instruction in which the operands do not match those
required for this parallel instruction.
 

Bug Description

BUG DESCRIPTION
===============
The following ISR does not save AR0 even though
it modifies it.  This is a problem with V4.60 and
V4.70.
 
void *a;
 
typedef struct
{
  int v;
}M;
 
typedef struct
{
   M m;
} dd;
 
dd D[2];
 
/* workaround()
{
} */
 
void c_int01(void)
{
  M t;
/*  workaround(); */
  D[1].m = t;
  a = &D;
}
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
The work-around is to make a function call in the
ISR, forcing all of the registers to be saved (As
shown with the lines that are commented out above).
The other work-around is to not do an assignment
to a structure in an ISR.

Bug Description

When the -g option is used with asm30 or cl30 for assembly files, the
assembler places debug information in the COFF file that makes the C3x
Debugger V5.00 and the C4x Debugger V2.40 fail.

Workaround/Solution

The solution is to not use the -g option with cl30 or asm30 when assembling
assembly source files.

Bug Description

The optimizer does not recognize the -v32 or -v44 option.  This is true
even when the shell, cl30, calls the optimizer, opt30.

Workaround/Solution

The optimizer does not do anything additional for the -v31,
-v32, and -v44 options.  Therefore, the -v32 option will work correctly
even though it displays the warning message.  It is a problem with
the -v44 option since opt30 will use the -v30 option by default
(internally, opt30 should treat -v44 the same as -v40 and treat
-v31 and -v32 the same as -v30).  Since none of the executables
do anything special with the -v44 option (other than treat it
as the -v40 option), the -v40 option should be used instead if opt30
is used.
 
Work-around summary:
For -v32, ignore warning.
FOr -v44, use -v40 instead.

Bug Description

The shell, cl30, will give a "out of memory" error if it is called without
a source file on the command line (for example: cl30 -z c30.cmd).  This is
only a problem with the DOS versions.

Workaround/Solution

WORKAROUND/SOLUTION
===================
Aside from the pathological case of calling cl30 with only options
and no c files (such as "cl30 -o2 -v40 -ma"), the only other time this
problem should occur is when calling the shell to activate the linker,
such as "cl30 -z link.cmd file1.obj file2.obj".  Since all options
after -z in the shell are merely passed on to the linker, the
workaround is to use lnk30 in place of cl30 in these instances.
 
(i.e. "cl30 -z link.cmd file1.obj file2.obj" becomes
      "lnk30 link.cmd file1.obj file2.obj")

Bug Description

BUG DESCRIPTION
===============
The compiler produces incorrect code for the following C code
when the following command line is used:  cl30 -sn bug.c
It does not correctly dereference a struct ptr to a float
member that is casted to a int pointer.
 
typedef struct
{
  float f;
  int i;
} A;
 
/* Here is the bug */
 
bug(A *a, int *ptr)
{
   ptr[1] = *(int *)&a->f;
   /* The bug goes away if -o2 is used */
}
 
The code produces the following:
;>>>>      ptr[1] = *(int *)&a->f;
        LDI     *-FP(2),AR0
        LDI     *-FP(3),AR1
        LDF     *AR0,R0
        STI     R0,*+AR1(1)
 
It should produce this:
;>>>>      ptr[1] = *(int *)&a->f;
        LDI     *-FP(2),AR0
        LDI     *-FP(3),AR1
        LDI     *AR0,R0
        STI     R0,*+AR1(1)

Workaround/Solution

WORKAROUND/SOLUTION
===================
The work-around is to use the -o2 option or one of the following
work-arounds:
 
typedef struct
{
  float f;
  int i;
} A;
 
solution1(A *a, int *ptr)
{
   ptr[0] = a->i;
   ptr[1] = *(int *)a;
   /* This works if f is the first member of the structure */
}
 
solution2(A *a, long *ptr)
{
   int *temp;
   ptr[0] = a->i;
   temp = (int *)(&a->f);
   ptr[1] = *temp;
   /* The temp variable is optimized away when -o2 is used */
}
 

Bug Description

BUG DESCRIPTION
===============
 
The optimizer incorrectly calculated an address while folding a loop.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
The problem is fixed in C3x/4x 5.00B optimizer.

Bug Description

BUG DESCRIPTION
===============
 
The code example exhibits an error when compiling only on the PC version of
the 4.70 copiler.  The following command line was used to reproduce
the error.
 
cl30 -s -v30 -c -mb -d_C30 -x -o2 -on1 -mn -i. -D_C30 cut4.c
 

Copyright (c) 1987-1996  Texas Instruments Incorporated
   "cut4.c"   ==> MeasurementMenu
   "cut4.c"   ==> EditEngravingChannelParam
TMS320C3x/4x ANSI C Optimizer  Version 4.70
Copyright (c) 1987-1996  Texas Instruments Incorporated
   "cut4.c"   ==> MeasurementMenu
   "cut4.c"   ==> EditEngravingChannelParam
TMS320C3x/4x C Code Generator  Version 4.70
Copyright (c) 1987-1996  Texas Instruments Incorporated
   "cut4.c"   ==> MeasurementMenu
>> "cut4.c", line 230: COMPILER ERROR: BAD TREE NODE: 82a09dfc, 32

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
This problem does not occur in the V5.00 beta compiler.

Bug Description

BUG DESCRIPTION
===============
 
Compiler generates incorrect code for floating point structure member.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
This problem has been fixed in Release 5.00B1 of the compiler.

Bug Description

Bug Description

BUG DESCRIPTION
===============
The optimizer may delete function arguments that are never used.  If a
watch is attempted on one of these variables, the Debugger may fail
(core dump on SPARC, GP fault on Windows).  This occurs because the
debugger attempts to dereference a NULL pointer.  This problem is known
to occur in the C3x SPARC Simulator (V2.20), C3x Windows Simulator (V2.20),
C30 Windows EVM Debugger (V5.00), and C3x Windows XDS510 Debugger (V5.00).

Workaround/Solution

WORKAROUND/SOLUTION
===================
The work around is to not do a watch on these variables, to not use the
optimizer when using the Debugger, or to not declare arguments to a
function that are never used (dead arguments).

Bug Description

BUG DESCRIPTION
===============
 
The assembler gives cryptic error message:
 
"filename", line xx:  PORTS MUST BE PREDEFINED FOR THIS INSTRUCTION
 
when R11 is improperly used in a parallel MPYF3 || STF instruction.
 
i.e.      mpfy3 *ar1++(1)%, r6, r11
       || stf   r11, *aro++(1)
 
The proper error message should have been:
 
"filename", line xx: EXTENDED REGISTER R0 - R7 REQUIRED

Workaround/Solution

WORKAROUND/SOLUTION
===================
 Problem has been fixed for next release.

Bug Description

In the V5.00 compiler, for a MPYF3||SUBF3 instruction,
the assembler will incorrectly encode the operands on the
SUBF3 if they take the form indirect,register,register.
It seems the assembler will only encode the operands in
parallel addressing mode 0x01, and will not encode parallel
addressing mode 0x11.
 
Hence,
 
   MPYF3 *AR0,R1,R1
|| SUBF3 *AR1,R3,R2
 
will be incorrectly encoded as 0x858bc0c1.
 

Bug Description

BUG DESCRIPTION
===============
 
The linker core dumps when the fill directive is used.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
There is no known work-around.  Fixed in release 5.00 version of linker.

Bug Description

BUG DESCRIPTION
===============
 
Under some situations after using the -cr (RAM initialization - initialization
by loader) option with the Linker, hex30 will fail to specify to stdout and
the hex30 map file that the .cinit section is being placed in the hex output.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Re-arrange the order of the output sections in the linker command file.
Place the .bss and .cinit sections as the first two input sections (in
the linker command file SECTIONS directive) of a memory block (in the
linker command MEMORY directive).  This is fixed in V5.00.
 
For example:
 
SECTIONS
{
   .stack:  > RAM0
   .cinit:  > RAM1
   .bss:    > RAM1, block 0x10000
   .text:   > RAM1
   .const:  > RAM1
}
 
The above is the fix for the below.
 
SECTIONS
{
   .stack:  > RAM0
   .text:   > RAM1
   .bss:    > RAM1, block 0x10000
   .const:  > RAM1
   .cinit:  > RAM1
}
 
It does not matter if .cinit or .bss is first as long as they are placed
consecutively at the beginning of the same memory block.

Bug Description

BUG DESCRIPTION
===============
 
Hex utility reports an error when -cr option is used.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
The problem does not occur in the version 5.00 of the hex utility.

Bug Description

BUG DESCRIPTION
===============
 
This is a documentation bug in the TMS320C4x Parallel Runtime Support
Library User's Guide. Pg 4-64 describes the function install_int_vector
to be :
 
        void install_int_vector(void *isr, int N);
 
 
This has changed in v4.7. The file prts40.src in v4.7 has it defined as
 
        typedef void (*ISR_FnPtr)(void);
        void  install_int_vector(ISR_FnPtr ISRFnPtr, int N);
 
 
The correct syntax for using it in the customer's code, is
 
        install_int_vector ((ISR_FnPtr) c_int04, 0x04);
 
 
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Follow this syntax for the function install_int_vector :
 
 
        install_int_vector ( (ISR_FnPtr) c_int04, 0x04);

Bug Description

BUG DESCRIPTION
===============
 
This is a documentation bug in the TMS320C4x Parallel Runtime Support
Library User's Guide. Pg 4-64 describes the function install_int_vector
to be :
 
        void install_int_vector(void *isr, int N);
 
 
This has changed in v4.7. The file prts40.src in v4.7 has it defined as
 
        typedef void (*ISR_FnPtr)(void);
        void  install_int_vector(ISR_FnPtr ISRFnPtr, int N);
 
 
The correct syntax for using it in the customer's code, is
 
        install_int_vector ((ISR_FnPtr) c_int04, 0x04);
 
 
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Follow this syntax for the function install_int_vector :
 
 
        install_int_vector ( (ISR_FnPtr) c_int04, 0x04);

Bug Description

BUG DESCRIPTION
===============
The optimizer may delete function arguments that are never used.  If a
watch is attempted on one of these variables, the Debugger may fail
(core dump on SPARC, GP fault on Windows).  This occurs because the
debugger attempts to dereference a NULL pointer.  This problem is known
to occur in the C3x SPARC Simulator (V2.20), C3x Windows Simulator (V2.20),
C30 Windows EVM Debugger (V5.00), and C3x Windows XDS510 Debugger (V5.00).

Workaround/Solution

WORKAROUND/SOLUTION
===================
The work around is to not do a watch on these variables, to not use the
optimizer when using the Debugger, or to not declare arguments to a
function that are never used (dead arguments).

Bug Description

Currently, you can not allocate more than 399K words (63fceh words
allocated as 50 blocks of 1fffh words).  If your allocations are not
multiples of 1fffh, then you will waisted memory.  This is true for the
C3x Windows Simulator V2.20 and the C4x Windows Simulator V1.30.

Workaround/Solution

There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
 
1) The watch command fails for local static variables (like c in the
   sample program).
2) The disp command does not display the values in hex when the following
   command is used (disp s,x).
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Watching static variables was a bug and has been fixed.
 
The display command does not accept a format parameter for structure types.
(See TMWS320C3x C Source Debugger User's Guide, p 11-19.)

Bug Description

BUG DESCRIPTION
===============
The disp command gives incorrect results for structure bit fields.

Workaround/Solution

WORKAROUND/SOLUTION
===================
This is a known problem with the C3x XDS510 PC/SPARC Debugger V5.00 and
the C4x XDS510 PC/SPARC Debugger V2.40.  It will be fixed in the next
official releases.
 
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The OSC (Oscilloscope) application demo that used to ship with the EVM and
is now available on the BBS does not work properly when compiled with V4.60
of the C Compiler/Assembler/Linker.

Workaround/Solution

WORKAROUND/SOLUTION
===================
The linker command file, osc.cmd requires some changes.  The vecs.asm file
should also be changed since the .asect directive is now obsolete.
 
*********************************************************
*   VECS.H                                              *
*                                                       *
*   LINEAR PREDICTIVE CODING: LPC-10 ON THE TMS320C30   *
*                                                       *
*   (C) 1990 TEXAS INSTRUMENTS, HOUSTON                 *
*********************************************************
*   INTERRUPT AND RESET VECTORS                         *
*********************************************************
        .sect ".vecs"   ; interrupt and reset vectors
 
        .ref _c_int00   ; compiler defined C initialization reset
        .ref _c_int05   ; serial port transmit interrupt routine
        .ref _c_int11   ; DMA counter interrupt
        .ref _c_int99   ; unexpected interrupt handler
 
reset:  .word   _c_int00
int0:   .word   _c_int99
int1:   .word   _c_int99
int2:   .word   _c_int99
int3:   .word   _c_int99
xint0:  .word   _c_int05
rint0:  .word   _c_int99
xint1:  .word   _c_int99
rint1:  .word   _c_int99
tint0:  .word   _c_int99
tint1:  .word   _c_int99
dint:   .word   _c_int11
 
/************************************************************************/
/*   OSC.CMD                                                            */
/*                                                                      */
/*   TMS320C30 EVALUATION DEMO PROGRAM LINK COMMAND FILE                */
/*                                                                      */
/*   (C) 1990 TEXAS INSTRUMENTS, HOUSTON                                */
/************************************************************************/
/*   LINK COMMAND FILE FOR LPC10 PROGRAM                                */
/************************************************************************/
/*      cl30 -g vecs.asm c30.c osc_c30.c -z osc.cmd                     */
/************************************************************************/
-c
vecs.obj
c30.obj
osc_c30.obj
-o osc.out
-l rts30.lib
-m osc.map
-stack 0x400
-heap 0x800
-x
-w
 
MEMORY
{
   VECS:   org = 0        len = 0x40       /* RESERVED VECTOR LOCATIONS */
   SRAM:   org = 0x40     len = 0x3FC0     /* PRIMARY BUS SRAM (16K)    */
   RAM :   org = 0x809800 len = 0x800      /* INTERNAL RAM (2K)         */
}
 
SECTIONS
{
   .vecs:    > VECS                      /* RESET/INTERRUPT VECTORS   */
   .text:    > SRAM                      /* CODE                      */
   .cinit:   > SRAM                      /* C INITIALIZATION TABLES   */
   .data:    > SRAM                      /* ASSEMBLY CODE CONSTANTS   */
   .const:   > SRAM                      /* CONSTANTS                 */
   .sysmem:  > SRAM                      /* DYNAMIC MEMORY            */
   .stack:   >  RAM                      /* STACK                     */
   .bss:     >  RAM, block 0x10000       /* C VARIABLES               */
}

Bug Description

BUG DESCRIPTION
===============
 
The emulator did not disassemble immediate operands correctly in certain cases.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
The problem has been fixed.

Bug Description

BUG DESCRIPTION
===============
When loading the symbol table (sload or load) of a large COFF file, V5.00
of the Windows XDS510 and EVM Debuggers give a GP Fault error message.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
The emulator was attempting to allocate more than 64k in one malloc() call.
The bug has been fixed.

Bug Description

BUG DESCRIPTION
===============
The command "run 1" does not work correctly with a RPTS instruction
with V5.00 of the C3x EVM and XDS510 Debuggers.

Workaround/Solution

WORKAROUND/SOLUTION
===================
The workaround is to use the single-step command.
 
This is a known bug in the C3X silicon which incorrectly tells
the emulation system that the RPTS instruction has completed
when in fact it has only finished the first cycle of the
instruction. Hence, attempting to do a "run n" where an RPTS
is in the range of n instructions to be executed will
cause the target system to function correctly.

Bug Description

BUG DESCRIPTION
===============
 
The Scan Manager was incorrectly overwriting controller memory when mixed PGs were present.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Fixed in release 2.50 of emulator.

Bug Description

BUG DESCRIPTION
===============
 
Scan Manager was overwriting controller memory when mixed PGs were present.
Same as DDTS #SDSsq3150.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Fixed in release 2.50 of emulator. Same as DDTS #SDSsq03150.

Bug Description

BUG DESCRIPTION
===============
When loading the symbol table (sload or load) of a large COFF file, V5.00
of the Windows XDS510 and EVM Debuggers give a GP Fault error message.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
The emulator was attempting to allocate more than 64k in one malloc() call.
The bug has been fixed.

Bug Description

BUG DESCRIPTION
===============
The command "run 1" does not work correctly with a RPTS instruction
with V5.00 of the C3x EVM and XDS510 Debuggers.

Workaround/Solution

WORKAROUND/SOLUTION
===================
The workaround is to use the single-step command.
 
This is a known bug in the C3X silicon which incorrectly tells
the emulation system that the RPTS instruction has completed
when in fact it has only finished the first cycle of the
instruction. Hence, attempting to do a "run n" where an RPTS
is in the range of n instructions to be executed will
cause the target system to function correctly.

Bug Description

BUG DESCRIPTION
===============
spru053b TMS320C3x C Source Debugger User's Guide
 
P5-15   mc 0x808048,xdat,WRITE
        mc 0x80804C,rdat,READ
        should read:
        mc 0x808048,rdat,WRITE
        mc 0X80804C,xdat,READ
 
P5-18   pinc myfile,int2
        should read:
        pinc int2,myfile
 
P11-25  Need to add new type field: TX (memory may contain code)
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
See description above.

Bug Description

BUG DESCRIPTION
===============
When using the -x option with asm30 or the -ax option with cl30, a COPY
section with the cross reference information is included in the COFF file.
Although the COPY section is not supposed to be loaded, TI loaders with core
debugger versions older than 3.33 will attempt to load the section (Using
"version+" on the debugger command line will tell you the debugger core
version).  The C3x Simulator V2.20 loader has the problem and the C4x Simulator
V1.30/V1.31 has the problem.  The following loaders do NOT have the problem:
C4x XDS510/XDS510WS Debugger V2.40 and C3x XDS510/XDS510WS Debugger V5.00.

Workaround/Solution

WORKAROUND/SOLUTION
===================
In the linker SECTION directive of the linker command file, tell the
linker to place the .xref section at a specific memory location that will
not disturb the program.  The only other option is to not use the -x option
if you intend to use the faulty loader.

Bug Description

BUG DESCRIPTION
===============
A simulator bug is causing the following code to ignore all interrupts:
 
L2:     BD      L2
        LDI     *+FP(2),R0
        NOP
        STI     R0,*+FP(1)
 
The code should disable interrupts until the delayed branch completes, but
when it branches back to itself it should be checking for new interrupts and
it is not.  If you do not idle in a loop with a delayed branch, the simulator
does not have this problem.

Workaround/Solution

WORKAROUND/SOLUTION
===================
No known work-around.

Bug Description

BUG DESCRIPTION
===============
The 1993 C Source Debugger User's Guide states that when using the file
command, you can use the D_SRC environment variable, -i option or use
command to specify the path (P6-11).  This is misleading.
 
If the -g option is used with the compiler, the COFF file will contain
debugger information.  When this COFF file is loaded into the Simulator,
the Simulator will automatically open the current source file without using
the file command.  In order for the debugger to find the file, one of the
following must occur:
 
        o  The *.c files are in the same directory as the COFF output file
        o  The paths of the *.c files are included in the D_SRC environment
           variable.
        o  The paths of the *.c files are included on the command line with
           the -i option.
        o  The use command can be used to specify the path of the *.c files
           (only one directory at a time).
 
If the file command is used to open a text file, the entire path is always
needed unless the file is in the current directory.
 
The same problem exists in the C4x and C5x C Source Debugger User's Guides.
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
See the description above.

Bug Description

BUG DESCRIPTION
===============
When the FSXOUT bit (SPORT Global Control Register bit 2) is configured
for the FSX to be an input pin (FSXOUT=0), the SPORT does not work properly.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
C3x  simulator does not handle register conflicts in the pipeline after
a parallel store instruction properly.  The simulator takes the old
value of the conflicting register.
 
An example section of asm is given below:
 
    STI      R1,*+FP(2)
    ANDN     R1,R0,R2
    STI1     R2,*+FP(1) ||  STI2R2,*AR0
 
    LDI      @CONST+2,AR1
    LDI      *AR1,R0           ; Sim used old value of AR1 here
 
 
The simulator blows up on the last access - the one that
implements the circular buffer - if the BK register contains 0.
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The Simulator incorrectly handles the following code segment.  When single-
stepping through the program, it seems to do the first store correctly, but
when the next instruction (lb1 r0, r1) is executed, the memory location to
where the store occurred is reset to 0h.
 
_c_init00       ldp data_addr
                ldi 02244h, r0
                ldi @data_addr, ar1
                lb0 r0, r1
                sti r1, *ar1++
                ;nop
                lb1 r0, r1
                sti r1, *ar1++
                br _c_init00
 
 
If a nop is placed after the first sti instruction, the first sti
works correctly.  The second sti always works correctly.
 
This bug only occurs if the code is being executed from internal memory.
It does not seem to matter if the store is made to internal or external
memory.
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The ma command does not seem to work with the "writeonly" type parameter.
 
ma 0x83000000,1,writeonly
fill 0x83000000,1,10
wa *0x83000000
 
The intent of "writeonly" was to allow the Debugger to read and
write that memory, but to fail if an instruction attempted to write to that
memory location.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The ROMEN pseudoregister is not documented.

Workaround/Solution

WORKAROUND/SOLUTION
===================
The ROMEN psuedoregister can be used to switch between microprocessor and
microcomputer mode (the -mm0 and -mm1 switches are not supported as on
the C3x Simulator).  The default is for ROMEN=0x1 (Microcomputer mode).
The Simulator can be changed to Microprocessor mode by typing:
"? ROMEN=0x0".

Bug Description

BUG DESCRIPTION
===============
The RSQRF and the RCPF instructions do not work properly.  The vales
returned are not correct.  In fact, they both return 32-bit results instead
of 16 bit results.
 
RSQRF   4ccccc00h instead of 4d000000h
RCPF    23d70800h instead of 24000000h
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The simulator does not work correctly for the insstruction after the
SET COND bit in the Status register is set.
 
This program does not work properly.  It should branch to START and not
reach END since the SET COND bit is set in the ST register.
 
        .global START
START
        LDI 0, BK
        OR 8000h, ST
        LSH -12,BK,IR0
        BZD START
        NOP
        NOP
        NOP
END     B       END
 
This program works since it seems that the problem is that the new SET COND
is not realized in the instruction following the instruction that sets the
bit:
 
        .global START
START
        LDI 0, BK
        NOP
        OR 8000h, ST
        LSH -12,BK,IR0
        BZD START
        NOP
        NOP
        NOP
END     B       END
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The TOIEEE instruction does not work properly with the following floating
point values: 0, -0.5, -1.0, -0.625, -0.03125.  The answers should be
00000000h, be000000h, be800000h, bc800000h, bc000000h, respectively.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The simulator fails to properly execute DMA autoinitialization when:
  1. the first transfer in an autoinit sequence is complete
  2. the control word pointed to by the link pointer
     has transfer mode set to 11 (DMA stops after transfer
     is complete and does not perform next autoinit until
     CPU restarts by writing ones into START bits of DMA
     control register).
 
If the DMA is operating in split mode with only the primary
channel output FIFO connected to a file, the auxiliary channel
does not autoinitalize and the primary channel does not proceed.
 
With DMA operating in split mode, and both channels autoinitializing
the primary channel goes ahead of auxiliary channel. Is should be
a one-one situation.
 
The primary comm port does not continue after the auxilary comm
port has stopped.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The C4x SPARC and PC Simulators do not handle the DMA rotateing priority
correctly.  When the PRIORITY MODE bit is set to 0 in the DMA channel 0
Control Register, the Simulator uses the fixed priotity mode.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

The sconfig (Load Screen Configuration) command on the Windows V1.30
Simulator causes a GP fault.

Workaround/Solution

Save the configuration to a file called "init.clr".  The Simulator will
automatically load this file when it initializes.

Bug Description

BUG DESCRIPTION
===============
spru053b TMS320C3x C Source Debugger User's Guide
 
P5-15   mc 0x808048,xdat,WRITE
        mc 0x80804C,rdat,READ
        should read:
        mc 0x808048,rdat,WRITE
        mc 0X80804C,xdat,READ
 
P5-18   pinc myfile,int2
        should read:
        pinc int2,myfile
 
P11-25  Need to add new type field: TX (memory may contain code)
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
See description above.

Bug Description

BUG DESCRIPTION
===============
When using the -x option with asm30 or the -ax option with cl30, a COPY
section with the cross reference information is included in the COFF file.
Although the COPY section is not supposed to be loaded, TI loaders with core
debugger versions older than 3.33 will attempt to load the section (Using
"version+" on the debugger command line will tell you the debugger core
version).  The C3x Simulator V2.20 loader has the problem and the C4x Simulator
V1.30/V1.31 has the problem.  The following loaders do NOT have the problem:
C4x XDS510/XDS510WS Debugger V2.40 and C3x XDS510/XDS510WS Debugger V5.00.

Workaround/Solution

WORKAROUND/SOLUTION
===================
In the linker SECTION directive of the linker command file, tell the
linker to place the .xref section at a specific memory location that will
not disturb the program.  The only other option is to not use the -x option
if you intend to use the faulty loader.

Bug Description

BUG DESCRIPTION
===============
A simulator bug is causing the following code to ignore all interrupts:
 
L2:     BD      L2
        LDI     *+FP(2),R0
        NOP
        STI     R0,*+FP(1)
 
The code should disable interrupts until the delayed branch completes, but
when it branches back to itself it should be checking for new interrupts and
it is not.  If you do not idle in a loop with a delayed branch, the simulator
does not have this problem.

Workaround/Solution

WORKAROUND/SOLUTION
===================
No known work-around.

Bug Description

BUG DESCRIPTION
===============
The 1993 C Source Debugger User's Guide states that when using the file
command, you can use the D_SRC environment variable, -i option or use
command to specify the path (P6-11).  This is misleading.
 
If the -g option is used with the compiler, the COFF file will contain
debugger information.  When this COFF file is loaded into the Simulator,
the Simulator will automatically open the current source file without using
the file command.  In order for the debugger to find the file, one of the
following must occur:
 
        o  The *.c files are in the same directory as the COFF output file
        o  The paths of the *.c files are included in the D_SRC environment
           variable.
        o  The paths of the *.c files are included on the command line with
           the -i option.
        o  The use command can be used to specify the path of the *.c files
           (only one directory at a time).
 
If the file command is used to open a text file, the entire path is always
needed unless the file is in the current directory.
 
The same problem exists in the C4x and C5x C Source Debugger User's Guides.
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
See the description above.

Bug Description

BUG DESCRIPTION
===============
When the FSXOUT bit (SPORT Global Control Register bit 2) is configured
for the FSX to be an input pin (FSXOUT=0), the SPORT does not work properly.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
C3x  simulator does not handle register conflicts in the pipeline after
a parallel store instruction properly.  The simulator takes the old
value of the conflicting register.
 
An example section of asm is given below:
 
    STI      R1,*+FP(2)
    ANDN     R1,R0,R2
    STI1     R2,*+FP(1) ||  STI2R2,*AR0
 
    LDI      @CONST+2,AR1
    LDI      *AR1,R0           ; Sim used old value of AR1 here
 
 
The simulator blows up on the last access - the one that
implements the circular buffer - if the BK register contains 0.
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The Simulator incorrectly handles the following code segment.  When single-
stepping through the program, it seems to do the first store correctly, but
when the next instruction (lb1 r0, r1) is executed, the memory location to
where the store occurred is reset to 0h.
 
_c_init00       ldp data_addr
                ldi 02244h, r0
                ldi @data_addr, ar1
                lb0 r0, r1
                sti r1, *ar1++
                ;nop
                lb1 r0, r1
                sti r1, *ar1++
                br _c_init00
 
 
If a nop is placed after the first sti instruction, the first sti
works correctly.  The second sti always works correctly.
 
This bug only occurs if the code is being executed from internal memory.
It does not seem to matter if the store is made to internal or external
memory.
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The ma command does not seem to work with the "writeonly" type parameter.
 
ma 0x83000000,1,writeonly
fill 0x83000000,1,10
wa *0x83000000
 
The intent of "writeonly" was to allow the Debugger to read and
write that memory, but to fail if an instruction attempted to write to that
memory location.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The ROMEN pseudoregister is not documented.

Workaround/Solution

WORKAROUND/SOLUTION
===================
The ROMEN psuedoregister can be used to switch between microprocessor and
microcomputer mode (the -mm0 and -mm1 switches are not supported as on
the C3x Simulator).  The default is for ROMEN=0x1 (Microcomputer mode).
The Simulator can be changed to Microprocessor mode by typing:
"? ROMEN=0x0".

Bug Description

BUG DESCRIPTION
===============
The RSQRF and the RCPF instructions do not work properly.  The vales
returned are not correct.  In fact, they both return 32-bit results instead
of 16 bit results.
 
RSQRF   4ccccc00h instead of 4d000000h
RCPF    23d70800h instead of 24000000h
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The simulator does not work correctly for the insstruction after the
SET COND bit in the Status register is set.
 
This program does not work properly.  It should branch to START and not
reach END since the SET COND bit is set in the ST register.
 
        .global START
START
        LDI 0, BK
        OR 8000h, ST
        LSH -12,BK,IR0
        BZD START
        NOP
        NOP
        NOP
END     B       END
 
This program works since it seems that the problem is that the new SET COND
is not realized in the instruction following the instruction that sets the
bit:
 
        .global START
START
        LDI 0, BK
        NOP
        OR 8000h, ST
        LSH -12,BK,IR0
        BZD START
        NOP
        NOP
        NOP
END     B       END
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The TOIEEE instruction does not work properly with the following floating
point values: 0, -0.5, -1.0, -0.625, -0.03125.  The answers should be
00000000h, be000000h, be800000h, bc800000h, bc000000h, respectively.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The simulator fails to properly execute DMA autoinitialization when:
  1. the first transfer in an autoinit sequence is complete
  2. the control word pointed to by the link pointer
     has transfer mode set to 11 (DMA stops after transfer
     is complete and does not perform next autoinit until
     CPU restarts by writing ones into START bits of DMA
     control register).
 
If the DMA is operating in split mode with only the primary
channel output FIFO connected to a file, the auxiliary channel
does not autoinitalize and the primary channel does not proceed.
 
With DMA operating in split mode, and both channels autoinitializing
the primary channel goes ahead of auxiliary channel. Is should be
a one-one situation.
 
The primary comm port does not continue after the auxilary comm
port has stopped.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.

Bug Description

BUG DESCRIPTION
===============
The C4x SPARC and PC Simulators do not handle the DMA rotateing priority
correctly.  When the PRIORITY MODE bit is set to 0 in the DMA channel 0
Control Register, the Simulator uses the fixed priotity mode.

Workaround/Solution

WORKAROUND/SOLUTION
===================
There is no known work-around.