This document describes the known exceptions to the functional and performance specifications to TI CMOS Radar Devices (AWR6843).

To designate the stages in the product development cycle, TI assigns prefixes to the part numbers of Radar / mmWave sensor devices. Each of the Radar devices has one of the two prefixes: XAx or AWRx (for example: XA6843BGABL). These prefixes represent evolutionary stages of product development from engineering prototypes (XI) through fully qualified production devices (AWR).

Device development evolutionary flow:

XA devices are shipped with the following disclaimer:

"Developmental product is intended for internal evaluation purposes."

Texas Instruments recommends that these devices not to be used in any production system as their expected end –use failure rate is still undefined.

Figure 3-1 shows an example of the AWR6843 Radar Device's package symbolization.

Figure 3-1 Example of Device Part Markings

This identifying number contains the following information:

• Line 1: Device Number
• Line 2: Safety Level and Security Grade
• Line 3: Lot Trace Code
  • YM = Year/Month Code
  • Z = Assembly Site Code
  • LLL = Assembly Lot Code
  • 9 = Primary Site Code
• Line 4:
  • 60 GHZi = AWR6843 (ES1.0) Identifier
  • 678A = AWR6843 (ES2.0) Identifier
  • ABL = Package Identifier
  • G1 = "Green" Package Build (must be underlined)

Usage notes highlight and describe particular situations where the device's behavior may not match presumed or documented behavior. This may include behaviors that affect device performance or functional correctness. These usage notes will be incorporated into future documentation updates for the device (such as the device-specific data sheet), and the behaviors they describe will not be altered in future silicon revisions.

The maximum SPI speed under 3-wire operation was only tested up to 33 MHz. This affects AWR6843 ES2.0.

Revision(s) Affected:

AWR6843 ES2.0

Description:

If a system reset (nRST goes low) occurs while the debugger is performing an access on the system resource using system view, a slave error should be replied to the debugger. If the access was a read, instead the response might indicate that the access completed successfully and return unpredictable data.

This issue occurs under this condition: when a system reset is asserted (nRST low) on a specific cycle, while the debugger is completing an access on the system, using the system view. An example would be, when a debugger, like the CCS-IDE memory browser window, is refreshing content using the system view. This is not an issue for a CPU only reset and, this is not an issue during a power-on-reset (nPORRST) either.

Workaround(s):

Avoid performing debug reads and writes while the device might be in reset.

Revision(s) Affected:

AWR6843 ES2.0

Description:

While the device is halted in suspend mode by the debugger, the DMA is expected to complete the remaining transfers of a block, if the DEBUG MODE bit field of the GCTRL register is configured to '01'. Instead, the DMA does not complete the remaining transfers of a block but, rather stops after two more frames of data are transferred. Subsequent DMA requests from a peripheral to trigger the remaining frames of a block can be lost.

This issue occurs only in the following conditions:

• The device is suspended by a debugger
• A peripheral continues to generate requests while the device is suspended
• The DMA is setup to continue the current block transfer during suspend mode with the DEBUG MODE bit field of the GCTRL register set to '01'
• The request transfer type TTYPE bit in the CHCTRL registers is set to frame trigger ('0')

Workaround(s):

Workaround #1:

Use TTYPE = block transfer ('1'), when the DEBUG MODE bit field is '01' (finish current block transfer)

or

Workaround #2:

Use the DMA DEBUG MODE = '00' (ignore suspend), when using TTYPE = frame transfer ('0') to complete the block transfer, even after suspend/halt is asserted.

Revision(s) Affected:

AWR6843 ES2.0

Description:

The MibSPI module, when configured in multibuffered slave mode with 3-functional pins (CLK, SIMO, SOMI) or 4-functional pins (CLK, SIMO, SOMI, nENA), could transmit incorrect data when all the following conditions are met:

• MibSPI module is configured in multibuffered mode,
• Module is configured to be a slave in the SPI communication,
• SPI communication is configured to be in 3-pin mode or 4-pin mode with nENA,
• Clock phase for SPICLK is 1, and
• SPICLK frequency is MSS_VCLK frequency / 12 or slower

Workaround(s):

The issue can be avoided by setting the CSHOLD bit in the control field of the TX RAM (Multi-Buffer RAM Transmit Data Register). The nCS is not used as a functional signal in this communication; hence, setting the CSHOLD bit does not cause any other effect on the SPI communication.

Revision(s) Affected:

AWR6843 ES2.0

Description:

When a DLEN error is created in Slave mode of the SPI using nSCS pins in IO Loopback Test mode, the SPI module re-transmits the data with the DLEN error instead of aborting the ongoing transfer and stopping. This is only an issue for an IOLPBK mode Slave in Analog Loopback configuration, when the intentional error generation feature is triggered using CTRLDLENERR (IOLPBKTSTCR.16).

Workaround(s):

After the DLEN_ERR interrupt is detected in IOLPBK mode, disable the transfers by clearing the SPIEN (bit 24) in the SPIGCR1 register and then, re-enable the transfers by resetting the SPIEN bit.

Revision(s) Affected:

AWR6843 ES2.0

Description:

A spurious DMA request could be generated even when the SPI slave is not transferring data in the following condition sequence:

• The MIBSPI is configured in standard (non-multibuffered) SPI mode, as a slave
• The DMAREQEN bit (SPIINT0.16) is set to enable DMA requests
• The Chip Select (nSCS) pin is in an active state, but no transfers are active
• The SPI is disabled by clearing the SPIEN (SPIGCR1.24) bit from '1' to '0'

The above sequence triggers a false request pulse on the Receive DMA Request as soon as the SPIEN bit is cleared from '1' to '0'.

Workaround(s):

Whenever disabling the SPI, by clearing the SPIEN bit (SPIGCR1.24), first clear the DMAREQEN bit (SPIINT0.16) to '0', and then, clear the SPIEN bit.