Bug Description

Compiler sometimes generates an internal error of this kind :
 
INTERNAL ERROR: Could not schedule any instruction
 
This usually occurs at higher optimization levels( -o2 and -o3)
and can be worked around by using lower optimization.

Bug Description

Bug Description

Bug Description

Bug Description

_ext intrinsic does not always work correctly when used in
array index.
Actually, any variable used to index into an array of structures
has a good chance of not working in release 2.00.

Bug Description

When using a pointer to access an array of >= 32 words within a
structure the compiler produces an error when using optimisation
level 2.
 
 

Bug Description

New parser reads -d command line options incorrectly when
a command file is needed because of the command length.

Bug Description

The assembly optimizer mistakenly treats all byte memory
accesses as if they were short accesses; this can lead to
a memory bank hit.
 

Bug Description

The compiler ignores the required delay slot between a write to
either ISR or ICR and a read from IFR.
 

Bug Description

When a 'c' file is compiled on a PC and on solaris using v2.0
compiler, the resulting .asm files (PC and solaris versions) are
different. Used the following compiler switches:
cl6x -o3 -oi0 -mh -mi -mx -k 
 
 
 
 

Bug Description

Bug Description

The compiler improperly models the interaction of the pipeline
behaviors of 16x16 multiplies and float/32x32 multiplies.
This is demonstrated by the shorter file ex.sa enclosed.
 

Bug Description

Bug Description

The _nassert() intrinsic does not always pass the given
information to the optimizer.

Bug Description

If the compiler removes a "if" statement by predicating the
instructions contained, any asm() statement inside the "if"
will not be predicated, effectively moving it outside the "if".
Workaround: do not use asm() statements.
 

Bug Description

Bug Description

BUG DESCRIPTION
===============
 

Bug Description

When using optimization levels of -o2 and -o3, the compiler
sometimes generates incorrect assembly code which results in
the erroneous use of X unit.

Bug Description

When the compiler uses conditional instructions, it will work
fine for all other instructions but IDLE. It will execute the
idle instruction even though you cannot make an idle instruction
conditional on the C6x.
 
The compiler should always branch around code inside any "if/then"
statement that contains an idle command.
 
Workaround:
-----------
use a function :
void sleep () {asm("\tidle");}
 

Bug Description

The compiler treats the unsigned short array index expression
as though it were an int.   This bug can happen if you have
an int expression cast to short used to access an array.

Bug Description

The compiler sometimes produces incorrect code when compiled
with optimization level 2.

Bug Description

There is a register live-too-long in the generated loop.
The software pipeliner should detect these problems and move
on to the next iteration interval, but there is a bug in
the representation of the double-precision math instructions
for C67x.  The live-too-long check does not understand that
these instructions read registers in more than one cycle.
 
This problem is restricted to C67x double-precision operations.
 
This bug does exist in the 1.10 and 2.00 compilers, but it
was masked by a large recurrence.  Now that the compiler is
better at aliasing analysis, the bug is exposed.  The
workaround is to turn off software pipelineing.

Bug Description

The compiler will ignore loop-carried memory dependences from a
read to a write (ANTI).   This means that any loop which has
code of the following form could be pipelined incorrectly.
This is more likely to show up in short loops.  The workaround
is to disable software pipelining with "-mu."
 
for(...)
{
   a[i-1] = ...
   ... = a[i];
}

Bug Description

The elements in a global array of pointers declared in C are
initialized to offset values from the start of $bss rather than
physical addresses.

Bug Description

The TI C6xtools C cross-compiler hosted on HP-UX core dumps
(in the routine 'addfile' according to adb on HP-UX)
processing the path of an input C source file.  The core dump
occurs whenever the total path length of an input file
(excluding the root file name) equals or exceeds 32 characters
including the leading and trailing slashes.  It does not
matter how many subdirectories are involved just the total
path lenth.
 
This does not happen on the pc and solaris versions.

Bug Description

The strtod function produces incorrect results.
(use this example below showing that "end" contains "mpty"
instead of "empty")
 
#include 
#include 
 void main()
{
    char *end;
    double x;
     x = strtod(".23empty", &end);
    printf("x = %f, end = %s\n", x, end);
}
 
strtod was not using or returning in the string pointer parts of
strings that looked like exponents but weren't.

Bug Description

In some cases the compiler is not able to parallelize mpysp
operations. This only occurs with -o2 & -o3,  works with -o1.
Example code:
 
#include 
 
void main()
{
  float a,b,a2,b2;
  int i;
 
  a = 10.0;
  b = 20.0;
 
  for (i=0;i<10;i++)
  {
        a = a + 1.0;
        b = b + 1.0;
  }
 
  a2 = a*a;
  b2 = b*b;
 
  printf("Result = %f %f \n", a2,b2);
}
 

Bug Description

Incorrect addresses are being generated by the assembler,
resulting in the upper bits being lost.
 
MVKH    .S1    peri.timer0,A0  ; peri.timer == 0x1800000
 
Instruction is assembled with peri.timer = 0x800000
 

Bug Description

The compiler is conditionally incrementing the address used
to store to lsf.  This increment should be unconditional;
only the store itself should be conditional.
 

Bug Description

The compiler completely ignored every parallel instruction
during branch removal.  Typically, parallel instructions rarely
reach this stage, except when the user puts parallel
instructions directly into the serial assembly code.

Bug Description

The compiler sometimes gives an "INTERNAL ERROR : register allocation
failed" message. This happens when a loop counter variable is
stored into an array location indexed by the loop counter itself.
 
 
 
 

Bug Description

In software pipelined loops which mix access sizes to memory,
some of the loop transformations performed can cause non-
aligned offsets to be generated for address increments.
 
 
 

Bug Description

Declaring a static inline function with a static local is
illegal.  The C parser warning has been changed to a fatal
error.

Bug Description

Problem: Incorrect for loop execution in version 2.00
 
Description: Version 2.00 of the C compiler may execute for
loop incorrectly. Code that worked in version 1.10 may not work
in version 2.00.
 
Workaround:
By changing the loop index variable, it is possible to avoid
this problem.
 
This code executes incorrectly:
     for(k = 0; k <= 79; k+=2)
        {
        drp[k] = drp[40+k];
        drp[k+1] = drp[41+k];
     }
 
This code works:
     for(k = 0; k <= 79; k++)
        {
        drp[k] = drp[40+k];
     }

Bug Description

Bug Description

Very large trip counts are treated as signed numbers by software
pipelining.  The iteration count of a loop will be incorrect.  In the
following example the loop trip will be set to -2 rather than
4294967294.
 
   int a[0xfffffffe];
 
   void main()
   {
      int i;
 
      for (i = 0; i < 0xfffffffe; i++)
         a[i] = 0;
   }

Bug Description

As suggested, this is caused by exactly the same bug that is
reported in SDSsq04205 (q.v.)

Bug Description

Bug Description

The compiler does not correctly handle the CMPxxU instructions
with an icon.  It generates instructions assuming a 5 bit
sign extended immediate value.  The assembler then happily
assembles it.
 

Bug Description

There is a problem with premature license expiration in the free
C6x evaluation tools.
 
 
 

Bug Description

BUG DESCRIPTION
===============
 
Compiler generates code in the loop with too large an offset from the
data page, causing the assembler to fail due to "Offset too large"
errors.
 

Bug Description

Under certain conditions, the compiler could load a value
into a register within a conditional section of the code,
and assume that the register is still alive when it leaves
that basic block.

Bug Description

If an IF statement contains a large number of OR's ( "||" ) ,
the code generator may fail with a stack overflow.

Bug Description

The following error message is produced by the Assembler:
"test.asm", ERROR! at line 157: [E0800] Erroneous use of X unit
                  ADDAW    .D1      SP,A4,A0    ;|17|
 
Example of code that produces the error:
 
int count = 0;
int x(void)
{
   return count++;
}
 
int y(void)
{
   return count+=10;
}
 
main(void)
{
   int a[2];
   a[x()] += y();
}

Bug Description

When the shell command line length exceeds 100 characters,
including arguments from a command file, any -D arguments
could be corrupted.
Workaround: keep command lines short, or invoke the assembler
separately.
 
 

Bug Description

The assembler is not swapping the two words of the .double value
as it should be for the lddw instruction.  The bytes within the
words are being swapped correctly, though.
 
 

Bug Description

When the assembler chooses to put a "SUB reg,cst,reg" on the
D unit, it will get reversed unless the user put .D as the
functional unit spec.
The workaround is to always specify the unit on the SUB
instruction; the compiler always does this, so it is not an
issue for the compiler.

Bug Description

BUG DESCRIPTION
===============
 

Bug Description

When ZERO A0:A1 is assembled, the assembler gives an error
message about an illegal pair, and then segfaults
 

Bug Description

BUG DESCRIPTION
===============
assembler crashes/succeeds based on existence/removal of ; comment
 
Example: If you remove, add to or shorten the following comment
near the top of the file, you can make the assembler
succeed or fail.
 
;; INPUT hello.cdb alkjfdlakjdflakjsfdlkajdfljasdfljasdklfjaldjfalsjdfaljdfkjdflajdflakjdflkajdflkjsdflajdfljasfldjkasdfjalkdfjasdfjsdfj
 
 

Bug Description

When using -g, the line number symbols get inserted incorrectly
near fetch patckets that are aligned on the proper boundary
using parallel NOPs.
 

Bug Description

BUG DESCRIPTION
===============

Bug Description

The .align directive will cause the section size to be a
minimum of the specified alignment.

Bug Description

When code containing an idle instruction within a .proc/.endproc
section is passed to the assembly optimizer, it generates the
following error on a PC:
 
>cl6x code.sa
{code.sa}
TMS320C6x Assembly Preprocessor  Version 2.00
Copyright (c) 1996-1998 Texas Instruments Incorporated
   "code.sa":  ==> idle1
TMS320C6x ANSI C Codegen         Version 2.00
Copyright (c) 1996-1998 Texas Instruments Incorporated
   "code.sa":  ==> idle1 
The instruction at 004565c2 referenced memory at 377c2007
The memory could not be read from>> cannot run cg6x
 
and on Sparc:
 
>cl6x code.sa
{code.sa}
TMS320C6x Assembly Preprocessor  Version 2.00
Copyright (c) 1996-1998 Texas Instruments Incorporated
   "code.sa":  ==> idle1
TMS320C6x ANSI C Codegen         Version 2.00
Copyright (c) 1996-1998 Texas Instruments Incorporated
   "code.sa":  ==> idle1 
>> abnormal termination of cg6x

Bug Description

The assembly optimizer will sometimes ignore that a register
is live across a .proc/.endproc region.  For example:
 
fft .proc  a6
 
    
 
    .endproc a6
 
In the above example, the assembly optimizer is killing a6,
but a6 is specified as live across the proc region.

Bug Description

When a subsection is specified within a serial assembly file, as shown,
and the file is passed through the codegen tools, the final assembly
generates the error "E0003: Cluttered identifier operand encountered".
 
        .sect ".text:psa"
myfunc: .cproc value, shift
        SHL .S2 value,shift,value
        .return value
        .endproc

Bug Description

The ADDAD instruction when used in a linear assembly file is
assembled to a ADDAW instruction.  For example:
 
        .global test
 
test:        .cproc
        .reg base, ptr, offset
 
        mvk     0x80004300, base
        mvkh    0x80004300, base
        mvk     0x1, offset
        addad   base, offset, ptr  ; expect ptr = 0x80004308
 
        .return ptr
        .endproc
 
here:   b       here
        nop 5
 
is assembled to be:
 
        .line   4
           MVK     .S1     0x80004300,A0 ; |6|
        .line   5
           MVKH    .S1     0x80004300,A0 ; |7|
        .line   6
           MVK     .S1     0x1,A3       ; |8|
        .line   7
           ADDAW   .D1     A0,A3,A4     ; |9|
        .line   10
           B       .S1     L3           ; |12|
           NOP             5

Bug Description

Bug Description

BUG DESCRIPTION
===============
 
MPY instructions are being treated as though they take exactly
4 cycles, by the assembly optimizer, and only in
C67x mode (-mv6700).  This can lead to hardware conflicts
and incorrect code.
 
 

Bug Description

This is related to the fix for SDSsq04389.  The assembly
optimizer mistakenly treated SUB scst5,src2,dst as though
it were allowed on the D unit.
 
Workaround: put functional units on all SUB instructions.
 
A shorter test case:
fn:     .proc   A5, A6, A7
        SUB             4, A5, A1
        SUB             4, A6, A2
        SUB             4, A7, A3
        .endproc        A1, A2, A3

Bug Description

Enhancement request for static inlining of linear assembly
functions in C code, to avoid function call overhead.
 

Bug Description

The register allocation was incorrect, because of a bug in
the software pipeliner.   Any time the compiler inserts moves
into the kernel (for various reasons), it can generate
incorrect code.  The workaround is to turn off software
pipelining for this loop.

Bug Description

The .loop/.endloop in a linear assembly function does not work
correctly. No code is emitted for the function.
 
Example code to reproduce:
test:   .proc   A1, A2, A3
          .reg    Aptr, A, Bptr, B, Cptr, C
          mv      A1, Aptr
          mv      A2, Bptr
          mv      A3, Cptr
          .eval   0,x
          .loop
          ldh     *Aptr++, A
          ldh     *Bptr++, B
          add     A, B, C
          sth     C, *Cptr++
          .eval   x+1, x
          .break  x=6
          .endloop
          .endproc

Bug Description

The linker is unable to process file names that have been
included, if the filename is in a quoted  string,
i.e. "main.obj".
 
Work around:
------------
Manually remove the double quote characters (") around the .obj
and .lib files within the linker command file and then run lnk500.
 
Download PC patch
Download Solaris patch
 
 

Bug Description

If you create a new memory window (using both the PC and Sparc
versions of the emulator)
 
   mem 0x1000,,window2
 
and then try to change the address displayed in window2 using
the address field of the window, it will not change the address
of window2, but it will change the address of the original
memory window.
 
If you close the original window and then change the address in
window2, the original window will reappear.
 
This problem also occurs on the simulator.
 

Bug Description

The emulator fails to connect with the target DSP right after the target board is powered up.
 
A dialog box containing the following error message appears.
 
        "Functional Error"
        "INT Error -1"
        "Cannot initialize target."
        "Check I/O."
        "Check cabling and target power."
 

Bug Description

v2.00 emulator debugger has problems loading files when
using a 133 MHz Windows NT machine. The error is usually
a "Memory Access Error - Check Memory Map". If the host
is a 200 MHz Windows NT machine, this problem is likely to
manifest itself more often.

Bug Description

 
Problem: (v2.0 emulator and rev 2.1 silicon)
'reset' from debugger window does not disable the cache in
right order.
 
because of this there will be problems while reloading the code
after reset, especially when the cache mode is enabled.
 
 

Bug Description

The emulator reset command fails when a breakpoint point exists
at address 0x0.
 
The command window shows the following error message:
"Cannot reset the processor".
 

Bug Description

The emulator debugger hangs when trying to perform a memory fill
command with odd start address and length of 1.
e.g. fill 0x80000001,1,0x0
 

Bug Description

Under Windows NT, a user who is not in the "administrators" group
cannot reset the emulator. They will get the following error :
 
XDS510 RESET FOR WINDOWS NT
Version 3.00
Copyright (c) 1995-1997 by Texas Instruments Incorporated
 
XDS510 DRIVER FOR NT IS NOT ACCESSABLE.

Bug Description

The debugger watch window sometimes displays values of variables
incorrectly.
 

Bug Description

Using ver 2.03 of the emulator debugger in conjunction with
ver 2.11 of the code generation tools, gives memory access errors
when loading code. On subsequent loads, it gives the same
error but at different addresses.
 
Download PC patch
Download the Readme file
 

Bug Description

EVM Debugger will sometimes hang when sending messages over
the PCI bus.

Bug Description

Attempting to read DRAM by invoking evm6x_hpi_read sometimes
makes the PC hang.

Bug Description

When profiling on the C6x EVM Debugger or the C6x XDS-510
Emulator Debugger, the Debugger may give an error similar to:
 
Profiling...
Fatal Error: Cannot start target processor
Stop Point = 00002684 Func1, at line 152, "code.out"
Run Cycles = -243   Profile Cycles = -243    Hits = 99
 

Bug Description

BUG DESCRIPTION
===============
On using C6x EVM for the first time, if the following message
pops up: "The file EVM6x.INF in EVM6X could not be found,
  Insert EVM6X into drive below, click OK", then follow the following
procedure:
 
Insert the EVM into a PCI slot, power up
Just inserted board for the first time, booting the computer
and PlugNPlay has detected the board.
 
Problem sequence:
 
"New Hardware Found"
...
Found TI EVM Driver
"Copying Files dialog"
"Insert Disk labelled 'EVM6x",     <------- Problem beginning
hit OK
"Copying files.." pops up briefly then
"The file EVM6x.INF in EVM6X could not be found,
  Insert EVM6X into drive below, click OK", the text box which
  appears has D:\cab5 in it.  If this is not replaced by e:
  (the location of the CDROM) then you can't install the driver.
 

Bug Description

BUG DESCRIPTION
===============
 
Insert the EVM into a PCI slot, power up
Just inserted board for the first time, booting the computer
and PlugNPlay has detected the board.
 
Insert the card,
"New Hardware Found"  PCI CoProcessor...
Hit Next

 
The user is presented with a grey OK button and can not procede.
 
The user should have inserted the CDROM, then hit Next.

Bug Description

BUG DESCRIPTION
===============
 
In Windows Device Manager (Start->Settings->Control
Panel->System->Device Manager->Other PCI->EVM 6x,
Properties, Driver tab) asking for the driver information
shows
Provider:   Not available
           Date:         3-31-1998
           Version:    Not available
 
Additionally, when you hit the resources tab, it takes
about 10 minutes to come up with the values
(on a Pentium 90).  Most users think the system is froze
and there is something wrong with the driver.

Bug Description

BUG DESCRIPTION
===============
 
on NT.
 
CCS is running, program will not Debug->go main.  try
start->texas instruments dsp->Reset EVM. No avail (try 3 times).  Go to dos box, hunt endlessly for the directory of evm install, run evm6xrst.exe  Error can't reset Jtag.
 
Exit CCS, run evm6xrst.exe, reset OK.
Run CCS
run evm6xrst, reset OK

Bug Description

BUG DESCRIPTION
===============
 
When installing the EVM6x software, there may be problems installing
the necessary drivers.
 
If the EVM6x is installed in a clean machine (only windows 95
osr2 installed), and V1.1 EVM6x CDROM is inserted, Windows might
be unable to find the drivers.
 
If you use 'Browse' to find the drivers, the OK button remains
greyed out.

Bug Description

The hex6x -order M (MS) and -order L (LS) switches have no
effect on the code generated.  Identical files are generated.

Bug Description

The printf() routine is not zero-padding floating point
numbers, such as "%06.2f".  Additionally, trying to print the
NULL character to a stream does not work (nothing is printed).
 

Bug Description

RTS functions readmsg() and writemsg() declare their
pointers to the CIOBUF as
"register unsigned char * volatile p".  This declares the
pointers themselves as being volatile, rather than the data
being pointed to.  The result is inefficient and potentially
incorrect code in the heart of the CIO mechanism.
(The CIOBUF itself *is* volatile, since the host will be
reading it and writing to it independently of the target.)
 
These should be declared as
"register volatile unsigned char *p" in writemsg(), or
"register const volatile unsigned char *p" in readmsg().
(The CIOBUF is not modified by readmsg, therefore the
pointer may be to const data, providing even greater
efficiency.)
 
On a side note:  The pointer arguments to writemsg(),
"unsigned char *parm" and "char *data", may be marked
const, since these should never overlap CIOBUF, and
writemsg() never writes through these pointers.  Marking
these as 'const' improves the performance of writemsg()
considerably.

Bug Description

In the runtime sources, fwrite() calls memchr() to find a newline
in the buffer being written on every fwrite() call, regardless of
whether the stream is line-buffered or not.  This call wastes a
considerable number of cycles on large fwrite()'s.

Bug Description

In the v. 2.00 rts.src, there is defect involving stack pointer
initialization:
 
If a user enters in a value for the stack size that is not divisible
by 8, there is not enough bytes between the first stack location
and the end of stack to hold a double. This could be pretty dangerous.
For example, if one used "-stack 0x4ffc" in the linker command
file, the stack will start at address 0x????4ff8 and the variables
in .bss begin at 0x????4ffc.  So if a doubleword is stored as the
first thing on the stack, it will overwrite the start
of the variables.
 
 

Bug Description

BUG DESCRIPTION
===============
 
The files ceil.c, ceilf.c, floor.c, and floorf.c do not have the
line "#undef _INLINE" in them.
Because of this, when the user tries to use the library build
utility "mk6x" to rebuild the RTS library with the -x or -ox
options, the compile fails.  Anything inlined in "math.h" needs
to have the "#undef _INLINE" in the corresponding source files.
 
 

Bug Description

There's a bug in the RTS CIO routines in which a read() or
write()larger than 256 characters can overflow CIO's internal
communication buffer and crash the program unexpectedly.
 
Note that this bug also causes a problem for "load6x":
It reports receiving a "corrupt CIO message":
 
(Note: This bug is the same as SDSsq04392)

Bug Description

The documentation for the MC command is incorrect on p 12-31
in the C Source Debugger User Manual, SPRU188D.  It should say:
 
Syntax
 
mc port address, page, length, filename, {READ | WRITE}
 
The documentation leaves out the {READ | WRITE} parameter.
 
Also, the MC command is only supported in the simulator, but it
does not appear in either of the simulator *.hlp files.  It
only appears (correctly) in the emulator *.hlp file.

Bug Description

The CPU and Instruction Set Reference Guide ( SPRU189C) does not
explicitly state that, for certain instructions, if internal
program RAM is used as either a source or destination, the
operation result is undefined.

Bug Description

A remote entity accessing a TMS320C6xxx through the host port
interface attempting to read internal program ram will have
undefined results. This is not documented in the host port
interface description( Pg 5-1 to 5-26) of the
TMS320C62x/C67x Peripherals Reference Guide( spru190b ).

Bug Description

Assembly optimizer is requiring functional units for parallel
instructions within a section of code.
 
When using parallel instructions, this error is produced:
*** ERROR!   line 7: E0800: Illegal parallel instruction
                            (functional units conflict)
 
Workaround: Enter at least on of the functional units, the code
            will then compile completely.
 
The documentation needs to be corrected to inform users that parallel
bars are illegal in serial assembly.

Bug Description

The TMS320C62xx CPU and Instrcution Set (SPRU189B) Guide,
page 2-9, documents the CSR's control and status bits.
The fields mentioned are EN, PWRD, PCC, and DCC. This Guide
refers to the TMS320C62xx Peripherals Reference Guide for more
info, but when you reference the Peripherals Guide, SPRU190B,
there is info about all fields except the DCC field.
 

Bug Description

The table listed on page A-10 of the C6x Assembly Language
Tools Guide is wrong.  The last 3 entries are wrong.
They are listed as :
 
        R_C60LO16       0053h
        R_C60HI16       0054h
        R_C60SECT       0055h
 
 
They should be :
 
        R_C60LO16       0054h
        R_C60HI16       0055h
        R_C60SECT       0056h
 

Bug Description

Page 8-27 in the PDF version of the C6x C Compiler Manual
SPRU187C should not be included.
 
This page is not in the hardcopy of the manual.

Bug Description

In the "Optimizing C Compiler User's Guide", spru187c, there is an
incorrect statement regarding bit fields.
 
 
On page 7-22, the documentation states:
 
    "Note that the 'C6x C compiler operates on bit fields defined as
     unsigned ints.  Signed int bit field definitions are prohibited."
 
 
However, the documentation on Page 7-3 specifically states that a "bit
field defined as an integer is signed," which directly conflicts with
the prohibition on page 7-22.  Also, the example on page 8-12 shows a
bit-field structure with signed bit fields.
 
So, it appears that the statement on page 7-22 is both incorrect and
unnecessary.

Bug Description

The TMS320C6x Optimizing C Compiler User's Guide (SPRU187C)
contains conflicting descriptions of the stack pointer.
 
In section 8.1.2 C System Stack, it states "B15 is the stack
pointer (SP), which points to the current top of the stack (the
lowest address used)."
 
The SP as used by the C compiler points to the next unused
location on the stack.
 
The description of SP initialization states "At system
initialization, SP is set to a designated address for the top of
the stack. This address is the first location past the end of the
.stack section."
 
The correct description of SP initialization is that the SP
is set to the first 8-byte aligned address BEFORE the end
(highest numerical address) of the .stack section.

Bug Description

The Simulator, Rls 2.00, is not simulating the SBSRAM cycles the same as the hardware.
It seems to double the cycles of a loop and ignore the alignment of fetch packets.

Bug Description

Customer using Sim6x version 2.x
 
When the Sim6x.cfg file is modified to change Bootsrc from
NONE to DMA, it generates the error:
 
    init error -1, Can't Initilize Target, Check Power and I/O
 
In command window:
 
    Configure error invalid bootsrc DMA
 
This worked in version 1.x simulator.
 

Bug Description

Linking the .cinit section to internal program ram and running it
on V 2.00 of the simulator, the simulator will allow you to pull data
from the .cinit tables in program ram and load them into .bss.
The simulator should not allow data accesses into internal
program memory.
 
 

Bug Description

Run on version 2.00 sim62x:
 
                MVK     0xd4e1da11,A0
                MVKH    0xd4e1da11,A0
 
                MVK     0xdc51b261,A1
                MVKH    0xdc51b261,A1
 
                SHL     A0,A1,A2
                SSHL    A0,A1,A3
 
Expected result for A3 is: 0xa9c3b422, SAT bit not set
sim62x result is: 0x00000000, SAT bit not set
 

Bug Description

Simulating external interrupts (pins int4-int7), in C62xx
simulator v2.00 does not work:
 
If the following interrupt timing file is connected to the int4
pin using the pinc command:
 
     300 (+500) rpt EOS;
 
and C I/O is used, the simulator correctly recognizes the first
interrupt generated, but the interrupts generated after the
first one are not recognized by the simulator.
 

Bug Description

M unit conflict is generated by the simulator when using
2 MPYHSLU instructions in a row with only 1 cycle between
them.
 

Bug Description

In the 67x simulator disassembly window, the instruction
  ADDAD.D1  A4, A3, A0
is executed correctly, but decoded and displayed as
  ADDAD.D1  A4, B3, A0
The associated hex value is 0x000c9e40.
 
 The problem is easily reproduced by entering the opcode in a
memory window and disassembling that opcode. At any address in
the memory window, enter 0x000c9e40. Then disassemble this
address and you will see it decoded as
        ADDAD.D1        A4, B3, A0 .
 This is wrong and can be seen by putting some values in
registers A4, A3, and B3, and executing this instruction. You
will see the addition performed using A4 and A3, not A4 & B3 as
the disassembly says.
 If you decode the 0x000c9e40 opcode by hand you will also see
the error.
 
 

Bug Description

The C6200B01 Compile4 Netmodel does not load correctly into
ModelSim (MGC QuickHDL Replacement).

Bug Description

The simulator sometimes locks up when trying to simulate SDRAM
timing.

Bug Description

When using EMIF, the simulator gives an error about access to
reserved memory, when .text and .cinit sections are placed in
different memory locations.

Bug Description

The stand-alone simulator, load62x does not properly prioritize
reads ahead of writes when the two are in parallel. So when you
have a STW||LDW instruction, load62x results in an incorrect
result.
 
This has been fixed in the 3.00 Alpha simulator

Bug Description

Sometimes there are problems assigning values to bit fields in a
structure.  The structure, which contains several unsigned fields
one bit long, does not seem to respond to statements which assign
values to it.  For example, the statement
outgoing_indicator.febe = 0x1 does not assign 1 to the bit field.
It remains 0, the initial value.
 

Bug Description

The simulator watch window sometimes displays values of variables
incorrectly.
 

Bug Description

 
 when in the simulator, if you disconnect a pin (using pind command) and reconnect
it again (using pinc command), it does not work (no interrupt is
generated).

Bug Description

BUG DESCRIPTION
===============
The SMPY instruction of C6x does not work correctly in
v2.01 Simulator. The lower 16-bits of the result are correct
while the top 16 bits are either 0000 or FFFF.
The previous version v2.00 Simulator works correctly for SMPY.

Bug Description

BUG DESCRIPTION
===============
 
The simulator does not correctly update the results of mpysp
and mpydp operations after a call to the rand() function.

Bug Description

The simulator sometimes does not perform DMA transfer from
external memory to internal data memory correctly.

Bug Description

If you create a new memory window (using both the PC and Sparc
versions of sim62x and sim62xfast)
 
   mem 0x1000,,window2
 
and then try to change the address displayed in window2 using
the address field of the window, it will not change the address
of window2, but it will change the address of the original
memory window.
 
If you close the original window and then change the address in
window2, the original window will reappear.
 
This problem also occurs on the emulator.
 

Bug Description

If you link C code with the "-cr" linker option, the simulator
or emulator will not initialize global variables to the
proper values.
 
The alignment of .cinit records changed from 4 bytes in tools
revision 1.10 to 8 bytes in tools revision 2.00.  This change
was accounted for in the compiler boot routine handling of
global variable initialization, but the corresponding change
was not made in the loader portion of the emulator and simulator.
 
The workaround is to link with "-c" instead of "-cr".
 

Bug Description

When 2 or more XDS510WS's are linked in a series, the last
XDS510WS is not being seen by the workstation.
 

Bug Description

I/O does not always work correctly on the debugger simulator.
The debugger prints out an extra space between characters that
get printed using the HOSTwrite() function.

Bug Description

The PC simulator and emulator (v2.01) as well as the EVM debugger
(v1.10) crashes when profiling a file when the directory name is
longer than 63 characters (including the drive letter).
 
For example, the directory:
 
V:\directory0\directory1\directory2\directory3\directory4\direc>
 
is fine but the directory:
 
V:\directory0\directory1\directory2\directory3\directory4\direct>
 
dies with a message similar to:
 
sim6x.exe - Application Error
 
The instruction at "0x00450022" referenced memory at "0x00000009".
The memory could not be "written".
 
sim6x.exe - Application Error
 
The instruction at "0x6c0031c3" referenced memory at "0x00000008".
The memory could not be "read".
 
The file runs correctly when not profiling.
 
This occurs on both the EVAL tools and the full release.

Bug Description

The debugger does not display long variables in hex format correctly.
Also long values which are elements of an array are not displayed
correctly through a wa or disp command.
 
For example :
 
1) If you have a long declaration:
  long w = 15;
then it is not possible to display w in hex format.
 
The command 'wa w,,x' results in w = 15.
Using the Setup->Watch menu gives the same result.
 
It is also not possible to change the standard display format
by "setf long, x".
 
2) long values which are elements of an array are not displayed
correctly through a wa-/disp-instruction:
 
If you have a long-array declaration:
  long LL[5];
and the array is initialized, then using 'wa LL' or 'wa (long *)LL',
does not display the correct values in the simulator.
 

Bug Description

Loading code that is built for the 6701 into the Code Composer
Emulator , results in an "invalid coff file" error.
 
This problem only exists under CC EVM/emulator driver version 2.03.
 
It does not exist under TI debugger release 2.03.
 
Download PC patch