SWRS246C November   2020  – July 2022 AWR6843AOP

PRODUCTION DATA  

  1. 1 Features
  2. 2 Applications
  3. 3 Description
  4. 4 Functional Block Diagram
  5. 5 Revision History
  6. 6 Device Comparison
    1. 6.1 Related Products
  7. 7 Terminal Configuration and Functions
    1. 7.1 Pin Diagram
    2. 7.2 Signal Descriptions
      1. 7.2.1 Pin Functions - Digital and Analog [ALP Package]
    3. 7.3 Pin Attributes
  8. 8 Specifications
    1. 8.1  Absolute Maximum Ratings
    2. 8.2  ESD Ratings
    3. 8.3  Power-On Hours (POH)
    4. 8.4  Recommended Operating Conditions
    5. 8.5  Power Supply Specifications
    6. 8.6  Power Consumption Summary
    7. 8.7  RF Specification
    8. 8.8  CPU Specifications
    9. 8.9  Thermal Resistance Characteristics for FCBGA Package [ALP0180A]
    10. 8.10 Timing and Switching Characteristics
      1. 8.10.1  Antenna Radiation Patterns
        1. 8.10.1.1 Antenna Radiation Patterns for Receiver
        2. 8.10.1.2 Antenna Radiation Patterns for Transmitter
      2. 8.10.2  Antenna Positions
      3. 8.10.3  Power Supply Sequencing and Reset Timing
      4. 8.10.4  Input Clocks and Oscillators
        1. 8.10.4.1 Clock Specifications
      5. 8.10.5  Multibuffered / Standard Serial Peripheral Interface (MibSPI)
        1. 8.10.5.1 Peripheral Description
        2. 8.10.5.2 MibSPI Transmit and Receive RAM Organization
          1. 8.10.5.2.1 SPI Timing Conditions
          2. 8.10.5.2.2 SPI Controller Mode Switching Parameters (CLOCK PHASE = 0, SPICLK = output, SPISIMO = output, and SPISOMI = input)
          3. 8.10.5.2.3 SPI Controller Mode Switching Parameters (CLOCK PHASE = 1, SPICLK = output, SPISIMO = output, and SPISOMI = input)
        3. 8.10.5.3 SPI Peripheral Mode I/O Timings
          1. 8.10.5.3.1 SPI Peripheral Mode Switching Parameters (SPICLK = input, SPISIMO = input, and SPISOMI = output) (1) (1) (1)
        4. 8.10.5.4 Typical Interface Protocol Diagram (Peripheral Mode)
      6. 8.10.6  LVDS Interface Configuration
        1. 8.10.6.1 LVDS Interface Timings
      7. 8.10.7  General-Purpose Input/Output
        1. 8.10.7.1 Switching Characteristics for Output Timing versus Load Capacitance (CL)
      8. 8.10.8  Controller Area Network - Flexible Data-rate (CAN-FD)
        1. 8.10.8.1 Dynamic Characteristics for the CANx TX and RX Pins
      9. 8.10.9  Serial Communication Interface (SCI)
        1. 8.10.9.1 SCI Timing Requirements
      10. 8.10.10 Inter-Integrated Circuit Interface (I2C)
        1. 8.10.10.1 I2C Timing Requirements
      11. 8.10.11 Quad Serial Peripheral Interface (QSPI)
        1. 8.10.11.1 QSPI Timing Conditions
        2. 8.10.11.2 Timing Requirements for QSPI Input (Read) Timings
        3. 8.10.11.3 QSPI Switching Characteristics
      12. 8.10.12 ETM Trace Interface
        1. 8.10.12.1 ETMTRACE Timing Conditions
        2. 8.10.12.2 ETM TRACE Switching Characteristics
      13. 8.10.13 Data Modification Module (DMM)
        1. 8.10.13.1 DMM Timing Requirements
      14. 8.10.14 JTAG Interface
        1. 8.10.14.1 JTAG Timing Conditions
        2. 8.10.14.2 Timing Requirements for IEEE 1149.1 JTAG
        3. 8.10.14.3 Switching Characteristics Over Recommended Operating Conditions for IEEE 1149.1 JTAG
  9. 9 Detailed Description
    1. 9.1 Overview
    2. 9.2 Functional Block Diagram
    3. 9.3 Subsystems
      1. 9.3.1 RF and Analog Subsystem
        1. 9.3.1.1 Clock Subsystem
        2. 9.3.1.2 Transmit Subsystem
        3. 9.3.1.3 Receive Subsystem
      2. 9.3.2 Processor Subsystem
      3. 9.3.3 Automotive Interface
      4. 9.3.4 Host Interface
      5. 9.3.5 Main Subsystem Cortex-R4F
      6. 9.3.6 DSP Subsystem
      7. 9.3.7 Hardware Accelerator
    4. 9.4 Other Subsystems
      1. 9.4.1 ADC Channels (Service) for User Application
        1. 9.4.1.1 GP-ADC Parameter
  10. 10Monitoring and Diagnostics
    1. 10.1 Monitoring and Diagnostic Mechanisms
      1. 10.1.1 Error Signaling Module
  11. 11Applications, Implementation, and Layout
    1. 11.1 Application Information
    2. 11.2 Reference Schematic
  12. 12Device and Documentation Support
    1. 12.1 Device Nomenclature
    2. 12.2 Tools and Software
    3. 12.3 Documentation Support
    4. 12.4 Support Resources
    5. 12.5 Trademarks
    6. 12.6 Electrostatic Discharge Caution
    7. 12.7 Glossary
  13. 13Mechanical, Packaging, and Orderable Information
    1. 13.1 Packaging Information
    2. 13.2 Tray Information for ALP, 15 × 15 mm

10.1 Monitoring and Diagnostic Mechanisms

Table 10-1 is a list of the main monitoring and diagnostic mechanisms available in the Functional Safety-Compliant devices

Table 10-1 Monitoring and Diagnostic Mechanisms for Functional Safety-Compliant Devices
NO FEATURE DESCRIPTION
1 Boot time LBIST For MSS R4F Core and associated VIM Device architecture supports hardware logic BIST (LBIST) engine self-test Controller (STC). This logic is used to provide a very high diagnostic coverage (>90%) on the MSS R4F CPU core and Vectored Interrupt Module (VIM) at a transistor level.
LBIST for the CPU and VIM need to be triggered by application code before starting the functional safety application. CPU stays there in while loop and does not proceed further if a fault is identified.
2 Boot time PBIST for MSS R4F TCM Memories Main R4F has three Tightly coupled Memories (TCM) memories TCMA, TCMB0 and TCMB1. Device architecture supports a hardware programmable memory BIST (PBIST) engine. This logic is used to provide a very high diagnostic coverage (March-13n) on the implemented MSS R4F TCMs at a transistor level.
PBIST for TCM memories is triggered by Bootloader at the boot time before starting download of application from Flash or peripheral interface. CPU stays there in while loop and does not proceed further if a fault is identified.
3 End to End ECC for MSS R4F TCM Memories TCMs diagnostic is supported by Single error correction double error detection (SECDED) ECC diagnostic. An 8-bit code word is used to store the ECC data as calculated over the 64-bit data bus. ECC evaluation is done by the ECC control logic inside the CPU. This scheme provides end-to-end diagnostics on the transmissions between CPU and TCM. CPU can be configured to have predetermined response (Ignore or Abort generation) to single and double bit error conditions.
4 Main R4F TCM bit multiplexing Logical TCM word and its associated ECC code is split and stored in two physical SRAM banks. This scheme provides an inherent diagnostic mechanism for address decode failures in the physical SRAM banks. Faults in the bank addressing are detected by the CPU as an ECC fault.
Further, bit multiplexing scheme implemented such that the bits accessed to generate a logical (CPU) word are not physically adjacent. This scheme helps to reduce the probability of physical multi-bit faults resulting in logical multi-bit faults; rather they manifest as multiple single bit faults. As the SECDED TCM ECC can correct a single bit fault in a logical word, this scheme improves the usefulness of the TCM ECC diagnostic.
Both these features are hardware features and cannot be enabled or disabled by application software.
5 Clock Monitor Device architecture supports Three Digital Clock Comparators (DCCs) and an internal RCOSC. Dual functionality is provided by these modules – Clock detection and Clock Monitoring.
DCCint is used to check the availability/range of Reference clock at boot otherwise the device is moved into limp mode (Device still boots but on 10MHz RCOSC clock source. This provides debug capability). DCCint is only used by boot loader during boot time. It is disabled once the APLL is enabled and locked.
DCC1 is dedicated for APLL lock detection monitoring, comparing the APLL output divided version with the Reference input clock of the device. Initially (before configuring APLL), DCC1 is used by bootloader to identify the precise frequency of reference input clock against the internal RCOSC clock source. Failure detection for DCC1 would cause the device to go into limp mode.
DCC2 module is one which is available for user software . From the list of clock options given in detailed spec, any two clocks can be compared. One example usage is to compare the CPU clock with the Reference or internal RCOSC clock source. Failure detection is indicated to the MSS R4F CPU via Error Signaling Module (ESM).
7 RTI/WD for MSS R4F Device architecture supports the use of an internal watchdog that is implemented in the real-time interrupt (RTI) module. The internal watchdog has two modes of operation: digital watchdog (DWD) and digital windowed watchdog (DWWD). The modes of operation are mutually exclusive; the designer can elect to use one mode or the other but not both at the same time.
Watchdog can issue either an internal (warm) system reset or a CPU non-mask able interrupt upon detection of a failure.
The Watchdog is enabled by the bootloader in DWD mode at boot time to track the boot process. Once the application code takes up the control, Watchdog can be configured again for mode and timings based on specific customer requirements.
8 MPU for MSS R4F Cortex-R4F CPU includes an MPU. The MPU logic can be used to provide spatial separation of software tasks in the device memory. Cortex-R4F MPU supports 12 regions. It is expected that the operating system controls the MPU and changes the MPU settings based on the needs of each task. A violation of a configured memory protection policy results in a CPU abort.
9 PBIST for Peripheral interface SRAMs - SPIs, CAN-FDs Device architecture supports a hardware programmable memory BIST (PBIST) engine for Peripheral SRAMs as well.
PBIST for peripheral SRAM memories can be triggered by the application. User can elect to run the PBIST on one SRAM or on groups of SRAMs based on the execution time, which can be allocated to the PBIST diagnostic. The PBIST tests are destructive to memory contents, and as such are typically run only at boot time. However, the user has the freedom to initiate the tests at any time if peripheral communication can be hindered.
Any fault detected by the PBIST results in an error indicated in PBIST status registers.
10 ECC for Peripheral interface SRAMs – SPIs, CAN-FDs Peripheral interface SRAMs diagnostic is supported by Single error correction double error detection (SECDED) ECC diagnostic. When a single or double bit error is detected the MSS R4F is notified via ESM (Error Signaling Module). This feature is disabled after reset. Software must configure and enable this feature in the peripheral and ESM module. ECC failure (both single bit corrected and double bit uncorrectable error conditions) is reported to the MSS R4F as an interrupt via ESM module.
11 Configuration registers protection for Main SS peripherals All the Main SS peripherals (SPIs, CAN-FDs, I2C, DMAs, RTI/WD, DCCs, IOMUX etc.) are connected to interconnect via Peripheral Central resource (PCR). This provides two diagnostic mechanisms that can limit access to peripherals. Peripherals can be clock gated per peripheral chip select in the PCR. This can be utilized to disable unused features such that they cannot interfere. In addition, each peripheral chip select can be programmed to limit access based on privilege level of transaction. This feature can be used to limit access to entire peripherals to privileged operating system code only.
These diagnostic mechanisms are disabled after reset. Software must configure and enable these mechanisms. Protection violation also generates an ‘error’ that result in abort to MSS R4F or error response to other peripherals such as DMAs.
12 Cyclic Redundancy Check –Main SS Device architecture supports hardware CRC engine on Main SS implementing the below polynomials.
  • CRC16 CCITT – 0x10
  • CRC32 Ethernet – 0x04C11DB7
  • CRC64
  • CRC 32C – CASTAGNOLI – 0x1EDC6F4
  • CRC32P4 – E2E Profile4 – 0xF4ACFB1
  • CRC-8 – H2F Autosar – 0x2F
  • CRC-8 – VDA CAN-FD – 0x1D
The read operation of the SRAM contents to the CRC can be done by CPU or by DMA. The comparison of results, indication of fault, and fault response are the responsibility of the software managing the test.
13 MPU for DMAs Device architecture supports MPUs on Main SS DMAs. Failure detection by MPU is reported to the MSS R4F CPU core as an interrupt via ESM.
DSPSS’s high performance EDMAs also includes MPUs on both read and writes master ports. EDMA MPUs supports 8 regions. Failure detection by MPU is reported to the DSP core as an interrupt via local ESM.
14 Boot time LBIST For BIST R4F Core and associated VIM Device architecture supports hardware logic BIST (LBIST) even for BIST R4F core and associated VIM module. This logic provides very high diagnostic coverage (>90%) on the BIST R4F CPU core and VIM.
This is triggered by MSS R4F boot loader at boot time and it does not proceed further if the fault is detected.
15 Boot time PBIST for BIST R4F TCM Memories Device architecture supports a hardware programmable memory BIST (PBIST) engine for BIST R4F TCMs which provide a very high diagnostic coverage (March-13n) on the BIST R4F TCMs.
PBIST is triggered by MSS R4F Bootloader at the boot time and it does not proceed further if the fault is detected.
16 End to End ECC for BIST R4F TCM Memories BIST R4F TCMs diagnostic is supported by Single error correction double error detection (SECDED) ECC diagnostic. Single bit error is communicated to the BIST R4FCPU while double bit error is communicated to MSS R4F as an interrupt so that application code becomes aware of this and takes appropriate action.
17 BIST R4F TCM bit multiplexing Logical TCM word and its associated ECC code is split and stored in two physical SRAM banks. This scheme provides an inherent diagnostic mechanism for address decode failures in the physical SRAM banks and helps to reduce the probability of physical multi-bit faults resulting in logical multi-bit faults.
18 RTI/WD for BIST R4F Device architecture supports an internal watchdog for BIST R4F. Timeout condition is reported via an interrupt to MSS R4F and rest is left to application code to either go for SW reset for BIST SS or warm reset for the device to come out of faulty condition.
19 Boot time PBIST for L1P, L1D, L2 and L3 Memories Device architecture supports a hardware programmable memory BIST (PBIST) engine for DSPSS’s L1P, L1D, L2 and L3 memories which provide a very high diagnostic coverage (March-13n).
PBIST is triggered by MSS R4F Bootloader at the boot time and it does not proceed further if the fault is detected.
20 Parity on L1P Device architecture supports Parity diagnostic on DSP’s L1P memory. Parity error is reported to the CPU as an interrupt.
Note:- L1D memory is not covered by parity or ECC and need to be covered by application level diagnostics.
21 ECC on DSP’s L2 Memory Device architecture supports both Parity Single error correction double error detection (SECDED) ECC diagnostic on DSP’s L2 memory. L2 Memory is a unified 256KB of memory used to store program and Data sections for the DSP. A 12-bit code word is used to store the ECC data as calculated over the 256-bit data bus (logical instruction fetch size). The ECC logic for the L2 access is located in the DSP and evaluation is done by the ECC control logic inside the DSP. This scheme provides end-to-end diagnostics on the transmissions between DSP and L2. Byte aligned Parity mechanism is also available on L2 to take care of data section.
22 ECC on Radar Data Cube (L3) Memory L3 memory is used as Radar data section in Device. Device architecture supports Single error correction double error detection (SECDED) ECC diagnostic on L3 memory. An 8-bit code word is used to store the ECC data as calculated over the 64-bit data bus.
Failure detection by ECC logic is reported to the MSS R4F CPU core as an interrupt via ESM.
23 RTI/WD for DSP Core Device architecture supports the use of an internal watchdog for BIST R4F that is implemented in the real-time interrupt (RTI) module – replication of same module as used in Main SS. This module supports same features as that of RTI/WD for Main/BIST R4F.
This watchdog is enabled by customer application code and Timeout condition is reported via an interrupt to MSS R4F and rest is left to application code in MSS R4F to either go for SW reset for DSP SS or warm reset for the device to come out of faulty condition.
24 CRC for DSP Sub-System Device architecture supports dedicated hardware CRC on DSPSS implementing the below polynomials.
  • CRC16 CCITT - 0x10
  • CRC32 Ethernet - 0x04C11DB7
  • CRC64
The read of SRAM contents to the CRC can be done by DSP CPU or by DMA. The comparison of results, indication of fault, and fault response are the responsibility of the software managing the test.
25 MPU for DSP Device architecture supports MPUs for DSP memory accesses (L1D, L1P, and L2). L2 memory supports 64 regions and 16 regions for L1P and L1D each. Failure detection by MPU is reported to the DSP core as an abort.
26 Temperature Sensors Device architecture supports various temperature sensors all across the device (next to power hungry modules such as PAs, DSP etc) which is monitored during the inter-frame period.(1)
27 Tx Power Monitors Device architecture supports power detectors at the Tx output.(2)
28 Error Signaling
Error Output		 When a diagnostic detects a fault, the error must be indicated. The device architecture provides aggregation of fault indication from internal monitoring/diagnostic mechanisms using a peripheral logic known as the Error Signaling Module (ESM). The ESM provides mechanisms to classify errors by severity and to provide programmable error response.
ESM module is configured by customer application code and specific error signals can be enabled or masked to generate an interrupt (Low/High priority) for the MSS R4F CPU.
Device supports Nerror output signal (IO) which can be monitored externally to identify any kind of high severity faults in the design which could not be handled by the R4F.
29 Synthesizer (Chirp) frequency monitor Monitors Synthesizer’s frequency ramp by counting (divided-down) clock cycles and comparing to ideal frequency ramp. Excess frequency errors above a certain threshold, if any, are detected and reported.
30 Ball break detection for TX ports (TX Ball break monitor) Device architecture supports a ball break detection mechanism based on Impedance measurement at the TX output(s) to detect and report any large deviations that can indicate a ball break.
Monitoring is done by TIs code running on BIST R4F and failure is reported to the MSS R4F via Mailbox.
It is completely up to customer SW to decide on the appropriate action based on the message from BIST R4F.
31 RX loopback test Built-in TX to RX loopback to enable detection of failures in the RX path(s), including Gain, inter-RX balance, etc.
32 IF loopback test Built-in IF (square wave) test tone input to monitor IF filter’s frequency response and detect failure.
33 RX saturation detect Provision to detect ADC saturation due to excessive incoming signal level and/or interference.
34 Boot time LBIST for DSP core Device device supports boot time LBIST for the DSP Core. LBIST can be triggered by the MSS R4F application code during boot time.
(1) Monitoring is done by the TI's code running on BIST R4F. There are two modes in which it could be configured to report the temperature sensed via API by customer application.
  1. Report the temperature sensed after every N frames
  2. Report the condition once the temperature crosses programmed threshold.
It is completely up to customer SW to decide on the appropriate action based on the message from BIST R4Fvia Mailbox.
(2) Monitoring is done by the TI's code running on BIST R4F.
There are two modes in which it could be configured to report the detected output power via API by customer application.
  1. Report the power detected after every N frames
  2. Report the condition once the output power degrades by more than configured threshold from the configured.
It is completely up to customer SW to decide on the appropriate action based on the message from BIST R4F.
Note: Refer to the Device Safety Manual or other relevant collaterals for more details on applicability of all diagnostics mechanisms. For Certification details, refer to the device product page.