--------------------------------------------------------------------------------
            Copyright (C) 1997 Texas Instruments Incorporated.
                         All Rights Reserved
--------------------------------------------------------------------------------

                        **************************
                        *                        *
                        *    SDB Release 2.11    *
                        *                        *
                        *        10-03-97        *
                        *                        *
                        *       ERRATA.TXT       *
                        *                        *
                        **************************


This file contains details regarding known problems and bugs with the SDB
2.10 release. TI will work toward fixing any known bugs or try to supply
a work-around. This list will be continously updated, you may contact TI
DSP technical support for the latest list.

Please read:
 - #DISCLAI.TXT
 - README.TXT
 - RELEASE.TXT
 - ERRATA.TXT
 - RPC\SDBRPC.TXT

QUICK REFERENCE

SOFTWARE
S200.1  CAPTURE_MONO8, CAPTURE_QCIF does not work
S200.2  Debugger hangs, does not respond
S200.3  PC Hangs
S200.4  Client/Server apps break with video capture running
S200.5  CAPTURE_512x512 and CAPTURE_CIFK don't completely fill buffer
S200.6  SDBDIAGS does not run properly with rev F boards
S200.7	Host communication bug related to PP i-cache fills.
S210.1	Modified client/server synchronization functions
S210.2  Can not debug RPC server from debugger
S210.3  The external interrupt ISR gets preempted

HARDWARE
H200.1  Host to SDB FIFO Mailbox problem
H200.2  Video capture FIFO 8-byte offset problem
H200.3  Host FIFO offset flags lag by two
H200.4  Static from audio playback

DOCUMENTATION
D200.1  CLIENT_EXEC is not documented
D200.2  CLIENT_STAT Client_ReadBootFifo(ULONG *Dst, ULONG Ct, long Timeout);
D200.3  CLIENT_STAT Client_WriteBootFifo(ULONG *Src, ULONG Ct, long Timeout);
D200.4  void Server_ReadBootFifo(ULONG *Dst, ULONG Ct, long Timeout);
D200.5  void Server_WriteBootFifo(ULONG *Src, ULONG Length);
D200.6  void Server_ReadDataFifo(ULONG *Dst, ULONG Length);
D200.7  void Server_WriteDataFifo(ULONG *Src, ULONG Length);
D200.8	void Capture_SetLuminance(BYTE contrast, BYTE brightness);
D200.9	CLIENT_STAT Client_Done(long Timeout);
D200.10	Figure 6-3. Client/Server Command Flow

*****************************************************************************
                                 Software
*****************************************************************************
S200.1    CAPTURE_MONO8, CAPTURE_QCIF does not work

DESCRIPTION:
Capturing 8-bit Y video (greyscale) at QCIF resolution doesn't work. The 
problem exists because the video capture front end DMA's data to the video
capture FIFO in chunks of 32bytes. It turns out that 8-bit QCIF (176x144),
which has 176 bytes per line, is not divisible by 32. This prevents the
line transfers from completing correctly. This is the only capture mode 
which exibits this behaviour.

WORKAROUND:
None

STATUS:
No plans to fix problem

-----------------------------------------------------------------------------
S200.2    Debugger hangs, does not respond

DESCRIPTION:
There are several things which can cause a debugger to hang. The root of the
problem is the debugger interface via PCI FIFO. The debugger is continously
communicating over the SDB's IO bus via the PCI FIFO mailbox registers to the
test bus controller (JTAG) chip on the board. These IO transfers require 
interaction from the SDB's memory controller. If a C80 program on the SDB
goes off into the weeds, its possible for the memory controller to get hung
up, which prevents debugger communication. A common cause of the memory
controller hanging is when the C80 attempts to read an empty FIFO, it retries
forever.

Whenever the host performs an IO access on the SDB (such as the debugger does),
both FIFO mailboxes are use (inbound and outbound) to complete the transfer.
If your application code writes to a mailbox while the debugger is up, it
could break the debugger because the FIFO mailboxes need to be empty for
IO transfers.

WORKAROUND:
Although there is no workaround for the root of the problem, there is a 
suggested safe way to kill the debugger.
1) Bring up the Windows Task Manager
2) Kill the debugger application
3) Wait until the confirmation dialog box appears then confirm
4) Execute sdbrst.exe, this should kill the debugger
5) Execute sdbrst.exe again

STATUS:
No plans to fix problem

-----------------------------------------------------------------------------
S200.3    PC Hangs

DESCRIPTION:
There are certain situations in which a bus lock condition occurs and the PC
hangs up. There are four events which cause this:
 1) Host tries to write to the FIFO mailbox when it is full
 2) Host tries to read the FIFO mailbox when it is empty
 3) Host tries to write to the FIFO when it is full
 4) Host tries to read from the FIFO when it is empty

A common situation occurs when the host is writing a large chunk of data
to the SDB via the FIFO while at the same time the C80 is packet transfering
the data out of the FIFO into SDB memory. If the C80 faults for some reason
during the transfer (memory overrun for example), the C80 transfer stops but
the host transfer continues. Eventually the host fills the FIFO then tries to
write to a full FIFO.

WORKAROUND:
The best bet is to check FIFO flags before every transfer. The Client API
library has a good deal of this type of checking so its a good idea to 
do all transfers using this API. Keep in mind however, there is no way to
prevent the situation described above when a large transfer breaks midway
other than breaking the transfer up into small chunks smaller than the FIFO
size which is inefficient.

STATUS:
There are currently no plans to fix this problem in hardware.

-----------------------------------------------------------------------------
S200.4    Client/Server apps break with video capture running

DESCRIPTION:
This problem occurs when the host writes a command into the FIFO then the C80
tries to read it out while video XPT's are running. The last word of the 
command does not get read out of the FIFO properly and the C80 tries forever
to read it out. You should not try to transfer data across the PCI FIFO while
video capture is running. This includes client/server commands.

You may get by with sending commands down to the SDB while video capture is
running since the problem is random and only happens sparsely. However, there
is no guaranty the command will work. In no way should large chunks of data
be transfered over the PCI bus while video capture is running because if the
transfer stops in the middle, a PCI bus lock condition could result which
hangs the PC.

WORKAROUND:
Do not use client/server while video capture is running. You may, however,
send a command to the server, which enables video capture, does some processing,
then disables video capture to complete the command. This way, video capture
is never actually running when commands are sent.

STATUS:
Hardware Fix Required

-----------------------------------------------------------------------------
S200.5    CAPTURE_512x512 and CAPTURE_CIFK don't completely fill buffer

DESCRIPTION:
When capturing video at either 512x512 or 352x288 non-interlaced (CIFK), the
buffers are not completely filled with video data. This is not a bug but a
result of the video capture front-end scaler. The video is always captured
at a resolution of 640x480 interlaced. The video scaler hardware then scales
the video down to the desired resolution. It was determined that the two
resolutions of 512x512 and 352x288 NI are common and may be desired by some
applications. The video scaler hardware can only scale down, not up. Because
of this, it is impossible to get 512 lines of video from 480. Likewise, it
is impossible to get 288 lines of non-interlaced video from 240 lines (480/2).
The video capture API still supports 512x512 and 352x288 NI by allocating
buffers to match these settings but only capturing into the first 480 lines
for 512x512 and capturing into the first 240 lines for 352x288 NI. This
results in non-defined lines at the bottom of the capture buffers. 32 lines
are undefined for 512x512 and 48 linies are undefined for 352x288. The 
application may call Capture_FillBuffs() to initialize the entire buffers.
Then, as long as the application does not modify them, the undefined buffer
lines will remain initialized.

WORKAROUND:
None possible

STATUS:
No plans to change current implementation

-----------------------------------------------------------------------------
S200.6    SDBDIAGS does not run properly with rev J boards

DESCRIPTION:
Rev J boards were special boards built specifically for TI internal use. The
diagnostic program (sdbdiags.exe) does not run properly on these boards.
Since none of these boards made it to the outside world, it should not be
a problem.

WORKAROUND:
None

STATUS:
No plans to change current implementation

-----------------------------------------------------------------------------
S200.7	Host communication bug related to PP i-cache fills.

DESCRIPTION: 
It turned out that if the PPs where thrashing their instruction caches
really bad, the client/server protocol would fail. This was due to the
fact that the PP icache fills are higher priority then normal MP transfer
requests. Hence, MP transfers to/from the PCI FIFO were not happening.

WORKAROUND:
None in Release 2.00

STATUS:
Fixed in release 2.10

In release 2.10, all PCI FIFO transfers are now done using XPTs which are 
higher priority than any I-CACHE fills. Using XPTs eliminates the need to
thunk the C80s MP into high priority mode and issuing urgent MP transfers.
The XPT method is the least intrusive to other code.

-----------------------------------------------------------------------------
S210.1	Modified client/server synchronization functions

DESCRIPTION: 
This change was minor and shouln't affect any existing software. The only
change was reversing the checking order in the Client_Sync() and 
Server_Sync() functions. There was a timing race condition in the 2.00
implementation. It was revealed when the C80 performed a write to the
SDB->HOST FIFO mailbox just after calling Server_Sync(). The C80 completed
the Sync function and wrote to the mailbox much faster than the host finished
its sync function. The value in the mailbox messed up the host sync.

WORKAROUND:
None in 2.00

STATUS:
Fixed in release 2.10

-----------------------------------------------------------------------------
S210.2  Can not debug RPC server from debugger

DESCRIPTION: 
A bug creeped into the 2.10 release which prevented the use of the C80
debugger during RPC server debug. RPC programs would work fine when ran
in realtime but wouldn't work when the MP debugger was up. The problem
is that the SDB interrupt control registers are not initialized as they
should be. The library code does not initialize these registers but
the boot loader does. This is why things worke fine for sdbrun or
Client_Boot(...) but not for the debugger.

WORKAROUND:
Two workarounds exist:
A) Download release 2.11

 - OR -

B) Add the following lines to the start of 'main' in every RPC program.
These lines should come before RpcInit(...).

  NOCACHE_USHORT(*(volatile USHORT*)0xE0000180) = 0x0000; /* ENABLE0 */
  NOCACHE_USHORT(*(volatile USHORT*)0xE0000182) = 0x0000; /* ENABLE1 */
  NOCACHE_USHORT(*(volatile USHORT*)0xE0000184) = 0x0000; /* ENABLE2 */
  NOCACHE_USHORT(*(volatile USHORT*)0xE0000188) = 0x0000; /* CLFLAG0 */
  NOCACHE_USHORT(*(volatile USHORT*)0xE000018C) = 0x0000; /* CLFLAG1 */


STATUS:
Fixed in release 2.11

-----------------------------------------------------------------------------
S210.3  The external interrupt ISR gets preempted

DESCRIPTION: 
It is possible that any of the ISR callback handlers can get preempted
by the multitasking executive. This happens when an ISR callback 
sets task priority to 31 to prevent preemption, calls a tasking function
such as TaskSignalSema(), then calls TaskSetPriority() once more to
restore the original context priority. The problem is that if there is
a higher priority task waiting in the queue, preemption occurs upon
calling that last TaskSetPriority() just mentioned. The original ISR
handlers were actual ISR entry points so preemption at the very end of
the ISR was not bad. But then, later on in the library development, it
was decided to use one global common ISR entry point, 'IsrEINT', which
would check to see what was pending and dispatch to the handlers. This
is just fine but now preemption can happen during a handler in which
more handlers may still need to be called. Although this seems like a 
bad thing, it always seemed to work itself out. That is, the preempted
handler was always resumed and completed. Regardless, it has been decided
to set the priority to 31 in the main global ISR and then restore it at
the very end of the main ISR, after all handlers have been called and
completed. At the same time, these items have been removed from the
original handlers. Now, all ISR callback handlers execute at priority
31.

WORKAROUND:
none

STATUS:
Fixed in release 2.11




*****************************************************************************
                                 Hardware
*****************************************************************************
H200.1    Host to SDB FIFO Mailbox problem

DESCRIPTION:
If the host writes to the FIFO mailbox, the C80 is unable to read it out.
This problem is not severe and all of the drivers avoid it.

WORKAROUND:
None

STATUS:
No plans to fix problem

-----------------------------------------------------------------------------
H200.2    Video capture FIFO 8-byte offset problem

DESCRIPTION:
There is a hardware problem with the video capture FIFO which results in the
last 8 bytes of each line of video not getting read out of the FIFO. That
means that the 8 bytes are left in the FIFO and read out at the beginning
of the next line. The figure below illustrates the effects of this.

    +----------------------------------------------------------------+
    |mmmmmmmm000000000000000000000000000000000000000000000.......0000|
    |00000000111111111111111111111111111111111111111111111.......1111|
    |11111111222222222222222222222222222222222222222222222.......2222|
    |22222222333333333333333333333333333333333333333333333.......3333|
    |   .                            .                            .  |
    |   .                            &                            .  |    |   .                            .                            .  |
    |        nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn.......nnnn|
    +----------------------------------------------------------------+

    mmmmmmmm is the last eight bytes of the previous frame

WORKAROUND:
The video capture API works around this problem by allocating capture buffers
8 bytes larger than normal. Captured lines of video are transfered into the 
buffer like normal but when the application calls Capture_GetBuffer(), it 
returns a pointer 8-bytes into the buffer. Since the lines are contiguous,
this is okay. The last 8 bytes of the frame are copied from the last 8 bytes
of the line just above. This workaround is not perfect for interlaced video 
since the lines of video are not adjacent in the buffer as they come in.

STATUS:
A hardware fix is required to remedy this situation. It is being looked
into by TI.

-----------------------------------------------------------------------------
H200.3    Host FIFO offset flags lag by two

DESCRIPTION:
The offset flags of the host interface FIFO lag by two. That is it takes two
writes to an empty FIFO to make the empty flag to go away. The almost full
and almost empty flags exibit the same behaviour. This is the result of a 
two stage latch which follows the FIFO stage in the PCI interface. This
behaviour is only observed in the host to sdb direction.

WORKAROUND:
None

STATUS:
No plans to fix problem

-----------------------------------------------------------------------------
H200.4  Static from audio playback

DESCRIPTION:
Sometimes, when starting DMA audio playback, very loud static is output.
This only happens in 16-bit mode. There is a suspected timing glitch
which causes a single byte to get lost along the way through the audio
FIFO. Losing a byte of a 16-bit sample effectively swaps the endian of
all following samples. The figure below tries to show this.

l is lower byte of 16-bit sample
h is upper byte of 16-bit sample

 normal flow
+-----+-----+-----+-----+...+-----+-----+-----+-----+-----+...
| l h | l h | l h | l h |   | l h | h l | h l | h l | h l |
+-----+-----+-----+-----+...+-----+-----+-----+-----+-----+...
                                   |
                              Byte is lost

After a byte is lost, the lower byte now becomes the upper byte in the
data stream. This is the reason for the loudness of the static, the
lower byte varies from 0 to 255 which is now the upper byte.

It is suspected the problem is related to the fact that the audio
FIFO operates in two modes, DMA mode and passthrough mode. When
in DMA mode, accesses to the FIFO go through the FIFO's memories.
When in passthrough mode, accesses bypass the memories and pass
straight through the device. It turns out that any accesses to the
audio CODEC registers go through the FIFO in passthrough mode.
There is a register in the CODEC which determines if the CODEC
operates in DMA mode or command mode. You might be able to see the 
problem here. If the CODEC is opeating in DMA mode with DMA data going 
through the FIFO, then you try to write to the CODEC to put it
in command mode, the write has to switch the FIFO into passthrough
mode which may cause a glitch in the DMA data already in the FIFO.
The logical solution is to not do any command writes to the
CODEC while it is DMAing data to/from the FIFO. This is not as easy 
as it sounds but the software has attempted it.

There has been an extensive effort to fix this problem in software but
cannot get 100% success. The frequency of the problem has been reduced
however.
                                   
WORKAROUND:
None

STATUS:
Requires hardware fix. No status on harware rework.

*****************************************************************************
                               Documentation
*****************************************************************************
D200.1    CLIENT_EXEC is not documented

A new macro has been added to the HCLIENT.H file to simplify code.

#define CLIENT_EXEC (CLIENT_LOAD | CLIENT_RUN)

It just combines the CLIENT_LOAD and CLIENT_RUN flags. Pass this macro in
the Flags argument of Client_Boot(...);.

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.2    CLIENT_STAT Client_ReadBootFifo(ULONG *Dst, USHORT Ct, long Timeout);

This function was added to the API after the documentation went to print.
Its description is identical to that of Client_ReadDataFifo(...) except that
the data is read from the boot FIFO range (0x6000) and the transfer length
is limited to 0x0800 32-bit words.

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.3    CLIENT_STAT Client_WriteBootFifo(ULONG *Src, USHORT Ct, long Timeout);

This function was added to the API after the documentation went to print.
Its description is identical to that of Client_WriteDataFifo(...) except that
the data is written to the boot FIFO range (0x6000) and the transfer length
is limited to 0x0800 32-bit words.

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.4    void Server_ReadBootFifo(ULONG *Dst, USHORT Ct, long Timeout);

This function was added to the API after the documentation went to print.
Its description is identical to that of Server_ReadDataFifo(...) except that
the transfer length is limited to 0x0800 32-bit words.

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.5    void Server_WriteBootFifo(ULONG *Src, USHORT Length);

This function was added to the API after the documentation went to print.
Its description is identical to that of Server_WriteDataFifo(...) except that
the transfer length is limited to 0x0800 32-bit words.

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.6  void Server_ReadDataFifo(ULONG *Dst, ULONG Length);

This function is prototyped incorrectly in the documentation. The one shown
here is correct. It returns void and the Length argument is a ULONG.

Correct Prototype:
void Server_ReadDataFifo(ULONG *Dst, ULONG Length);

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.7  void Server_WriteDataFifo(ULONG *Src, ULONG Length);

This function is prototyped incorrectly in the documentation. The one shown
here is correct. The Length argument is a ULONG.

Correct Prototype:
void Server_WriteDataFifo(ULONG *Src, ULONG Length);

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.8	void Capture_SetLuminance(BYTE contrast, BYTE brightness);

This function was added to the API after the documentation went to print.
It is used to set the luminance contrast and luminance brightness of the
video decoder chipset. Contrast is any value from 0x00 to 0x7F while 
brightness is any value from 0x00 to 0xFF. Lower values of contrast give
less contrast and lower values of brightness give less brightness.

The default values set via Capture_Init() are:
  contrast   = 0x40
  brightness = 0x80

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.9	CLIENT_STAT Client_Done(long Timeout);

This new function has been added to the client API after the documentation went
to print. This function must be called by a client (host) application when
finished with a command issued to the server before another command can be 
issued to the server. See also the errata D200.10 relating to the client/server
protocol changes.

STATUS:
Will add to next documentation release.

-----------------------------------------------------------------------------
D200.10	Figure 6-3. Client/Server Command Flow

The client/server protocol has changed a bit since the documentation went to
print which renders Figure 6-3 invalid. The new flow charts are given here.
Note that the CmndInProgress flag used in the client API is separate from the
CmndInProgress flag used in the server API.

STATUS:
Will add to next documentation release.


New Figure 6-3. Client/Server Command Flow




Server ISR  (Server API)
-------------------------
   ___                                                   
  <___>                                                  
    |                                                    
   / \  Is CmndInProgress flag set?                      
  <   >--------------------------------+                 
   \ /    yes                          |                 
    |no                                |                 
    |                                  |                 
 +--+--+                               |                 
 |     | Set the CmndInProgress flag   |                 
 +--+--+                               |                 
    |                                  |                 
 +--+--+                               |                 
 |     | Signal server semaphore       |                 
 +--+--+                               |                 
    |                                  |                 
    +<---------------------------------+                 
    |                                         
   ___                                    
  <___>                                   
                                          


Server_GetCmnd()  (Server API)
------------------------------
   ___                                                   
  <___>                                                  
    |                                                    
   / \  Is CmndInProgress flag set?                      
  <   >--------------------------------+                 
   \ /    no                           |                 
    |yes                               |                 
    |                                  |                 
    |                                  |
 +--+--+                               |
 |-----| Server_Sync()                 |
 +--+--+                               |
    |                                  |
 +--+--+                               |
 |     | Read command from FIFO        |
 +--+--+                               |
    |                                  |
 +--+--+                               |
 |-----| Server_Sync()                 |
 +--+--+                               |
    |                                  |                 
    +<---------------------------------+                 
    |                               
   ___                                    
  <___>                                   
                                          


Server_Done()  (Server API)
---------------------------
   ___                                                   
  <___>                                                  
    |                                                    
   / \  Is CmndInProgress flag set?                      
  <   >--------------------------------+                 
   \ /    no                           |                 
    |yes                               |                 
    |                                  |                 
 +--+--+                               |
 |-----| Server_Sync()                 |
 +--+--+                               |
    |                                  |                 
 +--+--+                               |                 
 |     | Clear the CmndInProgress flag |                 
 +--+--+                               |                 
    |                                  |                 
    +<---------------------------------+                 
    |                                         
   ___                                    
  <___>                                   
                                          


Client_IssueCmnd()  (Client API)
--------------------------------
   ___                                                   
  <___>                                                  
    |                                                    
   / \  Is CmndInProgress flag set?                      
  <   >----------------------------------------------+                 
   \ /    yes                                        |    
    |no                                           /-----\  If the application
    |                                             |Exit |  tries to issue 
    |                                             \-----/  another command
 +--+--+                                                   before the first one
 |     | Set the CmndInProgress flag                       is finished, the
 +--+--+                                                   application is exited
    |                                                      to prevent the broken
 +--+--+                                                   protocol sequence
 |     | Trigger PCI interrupt on SDB                      from doing something
 +--+--+                                                   bad.
    |
 +--+--+                                          
 |-----| Client_Sync()                  
 +--+--+                                
    |
 +--+--+                                                 
 |     | Write Command to FIFO
 +--+--+                              
    |
 +--+--+                                          
 |-----| Client_Sync()                  
 +--+--+                                
    |                                                    
   ___                                    
  <___>                                   
                                          


Client_Done()  (new function added to the Client API)
-----------------------------------------------------
   ___                                                   
  <___>                                                  
    |                                                    
   / \  Is CmndInProgress flag set?                      
  <   >--------------------------------+                 
   \ /    no                           |                 
    |yes                               |                 
    |                                  |                 
 +--+--+                               |
 |-----| Client_Sync()                 |
 +--+--+                               |
    |                                  |                 
 +--+--+                               |                 
 |     | Clear the CmndInProgress flag |                 
 +--+--+                               |                 
    |                                  |                 
    +<---------------------------------+                 
    |                                         
   ___                                    
  <___>                                   




*****************************************************************************
                             End of ERRATA.TXT
*****************************************************************************
 

    

