JAJSLO2C March   2021  – January 2024 AWR1843AOP

PRODUCTION DATA  

  1.   1
  2. 1 特長
  3. 2 アプリケーション
  4. 3 概要
    1. 3.1 機能ブロック図
  5. 4 Device Comparison
    1. 4.1 Related Products
  6. 5 Terminal Configuration and Functions
    1. 5.1 Pin Diagram
    2. 5.2 Pin Attributes
    3. 5.3 Signal Descriptions
      1. 5.3.1 Pin Functions - Digital and Analog [ALP Package]
  7. 6 Specifications
    1. 6.1  Absolute Maximum Ratings
    2. 6.2  ESD Ratings
    3. 6.3  Power-On Hours (POH)
    4. 6.4  Recommended Operating Conditions
    5. 6.5  Power Supply Specifications
    6. 6.6  Power Consumption Summary
    7. 6.7  RF Specification
    8. 6.8  CPU Specifications
    9. 6.9  Thermal Resistance Characteristics for FCBGA Package [ALP0180A]
    10. 6.10 Timing and Switching Characteristics
      1. 6.10.1  Antenna Radiation Patterns
        1. 6.10.1.1 Antenna Radiation Patterns for Receiver
        2. 6.10.1.2 Antenna Radiation Patterns for Transmitter
      2. 6.10.2  Antenna Positions
      3. 6.10.3  Power Supply Sequencing and Reset Timing
      4. 6.10.4  Input Clocks and Oscillators
        1. 6.10.4.1 Clock Specifications
      5. 6.10.5  Multibuffered / Standard Serial Peripheral Interface (MibSPI)
        1. 6.10.5.1 Peripheral Description
        2. 6.10.5.2 MibSPI Transmit and Receive RAM Organization
          1. 6.10.5.2.1 SPI Timing Conditions
          2. 6.10.5.2.2 SPI Controller Mode Switching Parameters (CLOCK PHASE = 0, SPICLK = output, SPISIMO = output, and SPISOMI = input)
          3. 6.10.5.2.3 SPI Controller Mode Switching Parameters (CLOCK PHASE = 1, SPICLK = output, SPISIMO = output, and SPISOMI = input)
        3. 6.10.5.3 SPI Peripheral Mode I/O Timings
          1. 6.10.5.3.1 SPI Peripheral Mode Switching Parameters (SPICLK = input, SPISIMO = input, and SPISOMI = output)
        4. 6.10.5.4 Typical Interface Protocol Diagram (Slave Mode)
      6. 6.10.6  LVDS Interface Configuration
        1. 6.10.6.1 LVDS Interface Timings
      7. 6.10.7  General-Purpose Input/Output
        1. 6.10.7.1 Switching Characteristics for Output Timing versus Load Capacitance (CL) #GUID-4685AB93-A014-47EA-9F05-952FFC28DBFA/T4362547-45 #GUID-4685AB93-A014-47EA-9F05-952FFC28DBFA/T4362547-50
      8. 6.10.8  Controller Area Network Interface (DCAN)
        1. 6.10.8.1 Dynamic Characteristics for the DCANx TX and RX Pins
      9. 6.10.9  Controller Area Network - Flexible Data-rate (CAN-FD)
        1. 6.10.9.1 Dynamic Characteristics for the CANx TX and RX Pins
      10. 6.10.10 Serial Communication Interface (SCI)
        1. 6.10.10.1 SCI Timing Requirements
      11. 6.10.11 Inter-Integrated Circuit Interface (I2C)
        1. 6.10.11.1 I2C Timing Requirements #GUID-64613E7E-5DDF-4B01-8FA0-13739060F368/T4362547-185
      12. 6.10.12 Quad Serial Peripheral Interface (QSPI)
        1. 6.10.12.1 QSPI Timing Conditions
        2. 6.10.12.2 Timing Requirements for QSPI Input (Read) Timings #GUID-6A95C194-2C40-46FE-9793-4574200DA2C4/T4362547-210 #GUID-6A95C194-2C40-46FE-9793-4574200DA2C4/T4362547-209
        3. 6.10.12.3 QSPI Switching Characteristics
      13. 6.10.13 ETM Trace Interface
        1. 6.10.13.1 ETMTRACE Timing Conditions
        2. 6.10.13.2 ETM TRACE Switching Characteristics
      14. 6.10.14 Data Modification Module (DMM)
        1. 6.10.14.1 DMM Timing Requirements
      15. 6.10.15 JTAG Interface
        1. 6.10.15.1 JTAG Timing Conditions
        2. 6.10.15.2 Timing Requirements for IEEE 1149.1 JTAG
        3. 6.10.15.3 Switching Characteristics Over Recommended Operating Conditions for IEEE 1149.1 JTAG
  8. 7 Detailed Description
    1. 7.1 Overview
    2. 7.2 Functional Block Diagram
    3. 7.3 Subsystems
      1. 7.3.1 RF and Analog Subsystem
        1. 7.3.1.1 Clock Subsystem
        2. 7.3.1.2 Transmit Subsystem
        3. 7.3.1.3 Receive Subsystem
      2. 7.3.2 Processor Subsystem
      3. 7.3.3 Automotive Interface
      4. 7.3.4 Main Subsystem Cortex-R4F Memory Map
      5. 7.3.5 DSP Subsystem Memory Map
    4. 7.4 Other Subsystems
      1. 7.4.1 ADC Channels (Service) for User Application
        1. 7.4.1.1 GP-ADC Parameter
  9. 8 Monitoring and Diagnostics
    1. 8.1 Monitoring and Diagnostic Mechanisms
      1. 8.1.1 Error Signaling Module
  10. 9 Applications, Implementation, and Layout
    1. 9.1 Application Information
    2. 9.2 Reference Schematic
  11. 10Device and Documentation Support
    1. 10.1 Device Nomenclature
    2. 10.2 Tools and Software
    3. 10.3 Documentation Support
    4. 10.4 サポート・リソース
    5. 10.5 Trademarks
    6. 10.6 静電気放電に関する注意事項
    7. 10.7 用語集
  12. 11Revision History
  13. 12Mechanical, Packaging, and Orderable Information
    1. 12.1 Packaging Information

8.1 Monitoring and Diagnostic Mechanisms

Below is the list given for the main monitoring and diagnostic mechanisms available in the Functional Safety-Compliant AWR1843AOP device.

Table 8-1 Monitoring and Diagnostic Mechanisms for Functional Safety-Compliant AWR1843AOP device
S NoFeatureDescription
1Boot time LBIST For MSS R4F Core and associated VIMAWR1843AOP 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.
2Boot time PBIST for MSS R4F TCM MemoriesMSS R4F has three Tightly coupled Memories (TCM) memories TCMA, TCMB0 and TCMB1. AWR1843AOP 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.
3End to End ECC for MSS R4F TCM MemoriesTCMs 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.
4MSS R4F TCM bit multiplexingLogical 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.
5Clock MonitorAWR1843AOP 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).
7RTI/WD for MSS R4FAWR1843AOP 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.
8MPU for MSS R4FCortex-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.
9PBIST for Peripheral interface SRAMs - SPIs, CANsAWR1843AOP 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.
10ECC for Peripheral interface SRAMs – SPIs, CANsPeripheral 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.
11Configuration registers protection for MSS peripheralsAll the MSS peripherals (SPIs, CANs, 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 masters such as DMAs.
12Cyclic Redundancy Check –MSSAWR1843AOP architecture supports hardware CRC engine on MSS 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 – 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.
13MPU for DMAsAWR1843AOP architecture supports MPUs on MSS 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.
14Boot time LBIST For BIST R4F Core and associated VIMAWR1843AOP 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.
15Boot time PBIST for BIST R4F TCM MemoriesAWR1843AOP 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.
16End to End ECC for BIST R4F TCM MemoriesBIST 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.
17BIST R4F TCM bit multiplexingLogical 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.
18RTI/WD for BIST R4FDevice 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.
19Boot time PBIST for L1P, L1D, L2 and L3 MemoriesDevice 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.
20Parity on L1PDevice 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.
21ECC on DSP’s L2 MemoryDevice 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.
22ECC on Radar Data Cube (L3) MemoryL3 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.
23RTI/WD for DSP CoreDevice 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 MSS. This module supports same features as that of RTI/WD for MSS/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.
24CRC for DSP Sub-SystemDevice 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.
25MPU for DSPDevice 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.
26Temperature SensorsDevice 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)
27Tx Power MonitorsDevice architecture supports power detectors at the Tx output.(2)
28Error 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.
29Synthesizer (Chirp) frequency monitorMonitors 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.
30Ball 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.
31RX loopback testBuilt-in TX to RX loopback to enable detection of failures in the RX path(s), including Gain/Noise figure, inter-RX balance, etc.
32IF loopback testBuilt-in IF (square wave) test tone input to monitor IF filter’s frequency response and detect failure.
33RX saturation detectProvision to detect ADC saturation due to excessive incoming signal level and/or interference.
34Boot time LBIST for DSP coreDevice 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 folder.