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 — | Experimental device that is not necessarily representative of the final device's electrical specifications and may not use production assembly flow. |
AWR — | Production version of the silicon die that is fully qualified. |
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.
This identifying number contains the following information:
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.
Advisory Number | Advisory Title | AWR6843 |
---|---|---|
ES2.0 | ||
Main Subsystem | ||
MSS#25 | Debugger May Display Unpredictable Data in the Memory Browser Window if a System Reset Occurs | X |
MSS#26 | DMA Requests Lost During Suspend Mode | X |
MSS#27 | MibSPI in Slave Mode in 3- or 4-Pin Communication Transmits Data Incorrectly for Slow SPICLK Frequencies and for Clock Phase = 1 | X |
MSS#28 | A Data Length Error is Generated Repeatedly in Slave Mode When IO Loopback is Enabled | X |
MSS#29 | Spurious RX DMA REQ From a Slave Mode MibSPI | X |
MSS#30 | MibSPI RX RAM RXEMPTY Bit Does Not Get Cleared After Reading | X |
MSS#31 | CPU Abort Generated on a Write to Implemented CRC Space After a Write to Unimplemented CRC Space | X |
MSS#32 | DMMGLBCTRL BUSY Flag Not Set When DMM Starts Receiving A Packet | X |
MSS#33 | MibSPI RAM ECC is Not Read Correctly in DIAG Mode | X |
MSS#34 | HS Device Does Not Reboot Successfully on Warm Reset Getting Triggered by Watchdog Expiry | X |
MSS#36 | DMA Read From an Unimplemented Address Space is not Reported as a BUS Error | X |
MSS#37B | DCC Module Frequency Comparison can Report Erroneous Results | X |
MSS#38A | GPIO Glitch During Power-Up | X |
MSS#39 | The State of the MSS DMA is Left Pending and Uncleared on Any DMA MPU fault | X |
MSS#40 | Any EDMA Transfer that Spans ACCEL_MEM1 +ACCEL_MEM2 Memories of Hardware Accelerator May Result in Data Corruption Without Any Notification of Error From the SoC | X |
MSS#41 | Issuing WARM_RESET can Cause Bootloader Failure Which Results in Failure to Load the Application From Serial Flash | X |
MSS#42A | DSP L2 memory initialisation can reoccur on execution DSP self test (STC) OR DSP Power cycling execution by application. | X |
MSS#43A | Read-data From Internal Registers of PCR Is Not Reliable. Shared PCS Region Protection is Also Not Supported | X |
MSS#44A | SYNC IN input pulse wider than 4usec can cause a FRC lockstep error | X |
MSS#45 | Bootup Failure During the Serial Flash Busy State | X |
MSS#50 | Occasional EDMA self-test failures | X |
MSS#51 | Spurious toggle on nERROR OUT signal during powerup due to undefined state in ESM block. | X |
Analog / Millimeter Wave | ||
ANA#11B | TX, RX Calibrations Sensitive to Large External Interference | X |
Section 6.3 | Second Harmonic (HD2) Present in the Receiver | X |
ANA#13B | Phase Mismatch Variation Across Temperature in TX3/TX1 and TX3/TX2 Combinations are higher than that of TX2/TX1 Combination | X |
ANA#14 | Doppler Spurs Observed for Narrow Chirps | X |
ANA#15 | Excessive TX-RX Coupling or Reflection can Lead to Saturated RX Output | X |
ANA#16 | LVDS Coupling to Clock System | X |
ANA#17A | On-Board Supply Ringing Induced Spur | X |
ANA#18B | Spurs Caused due to Digital Activity Coupling to XTAL | X |
ANA#19 | Bandgap Decoupling Capacitor On-Board | X |
ANA#20 | Occasional Failures Observed During Calibration of the Radar Subsystem | X |
Section 6.4 | Out of Band Radiated Spectral Emission | X |
ANA#22A | Overshoot and Undershoot During Inter-Chirp When Dynamic-Power Saving is Disabled | X |
ANA#27A | Digital Temperature Sensor Readings Differ From Analog Temperature Sensors | X |
Debugger May Display Unpredictable Data in the Memory Browser Window if a System Reset Occurs
AWR6843 ES2.0
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.
Avoid performing debug reads and writes while the device might be in reset.
DMA Requests Lost During Suspend Mode
AWR6843 ES2.0
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:
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.
MibSPI in Slave Mode in 3- or 4-Pin Communication Transmits Data Incorrectly for Slow SPICLK Frequencies and for Clock Phase = 1
AWR6843 ES2.0
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:
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.
A Data Length Error is Generated Repeatedly in Slave Mode When IO Loopback is Enabled
AWR6843 ES2.0
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).
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.
Spurious RX DMA REQ From a Slave Mode MibSPI
AWR6843 ES2.0
A spurious DMA request could be generated even when the SPI slave is not transferring data in the following condition sequence:
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'.
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.