How it Works
Texas Instruments
Loading...
RM57
User Manual
140 pgs1.1 Mb0
Table of contents
Loading...

Texas Instruments RM57 User Manual

Safety Manual for RM57x Hercules ARM Safety MCUs

User's Guide
Literature Number: SPNU575A
May 2014–Revised September 2016
Contents
1 Introduction ........................................................................................................................ 8
2 Hercules RM57x Product Overview....................................................................................... 10
2.1 Targeted Applications .................................................................................................. 11
2.2 Product Safety Constraints ............................................................................................ 12
3 Hercules Development Process for Management of Systematic Faults ..................................... 13
3.1 TI Standard MCU Automotive Development Process ............................................................. 14
3.2 TI MCU Automotive Legacy IEC 61508 Development Process.................................................. 15
3.3 Yogitech fRMethodology Development Process ................................................................... 15
3.4 Hercules Enhanced Safety Development Process................................................................. 15
4 Hercules Product Architecture for Management of Random Faults........................................... 18
4.1 Safe Island Philosophy and Architecture Partition to Support Safety Analysis (FMEA/FMEDA) ............ 18
4.2 Identification of Parts/Elements....................................................................................... 19
4.3 Management of Family Variants...................................................................................... 20
4.4 Operating States........................................................................................................ 20
4.5 Management of Errors ................................................................................................. 22
5 System Integrator Recommendations ................................................................................... 23
5.1 System Integrator Activities ........................................................................................... 23
5.2 Hints for Performing Dependent/Common Cause Failure Analysis Including the Hercules MCU ........... 25
5.3 Hints for Improving Independence of Function/Co-Existence of Function When Using the Hercules MCU 25
5.4 Support for System Integrator Activities ............................................................................. 25
6 Brief Description of Elements .............................................................................................. 26
6.1 Power Supply ........................................................................................................... 26
6.2 Power Management Module (PMM) ................................................................................. 26
6.3 Clocks.................................................................................................................... 27
6.4 Reset ..................................................................................................................... 27
6.5 System Control Module................................................................................................ 28
6.6 Error Signaling Module (ESM) ....................................................................................... 29
6.7 CPU Subsystem ........................................................................................................ 29
6.8 Primary Embedded Flash ............................................................................................. 31
6.9 Flash EEPROM Emulation (FEE) .................................................................................... 32
6.10 Primary Embedded SRAM ............................................................................................ 33
6.11 CPU Interconnect Subsystem......................................................................................... 34
6.12 Peripheral Interconnect Subsystem .................................................................................. 35
6.13 Peripheral Central Resource 1 (PCR1).............................................................................. 35
6.14 Peripheral Central Resource 2 (PCR2).............................................................................. 36
6.15 Peripheral Central Resource 3 (PCR3).............................................................................. 36
6.16 EFuse Static Configuration ............................................................................................ 37
6.17 OTP Static Configuration.............................................................................................. 37
6.18 I/O Multiplexing Module (IOMM)...................................................................................... 38
6.19 Vectored Interrupt Module (VIM) ..................................................................................... 38
6.20 Real Time Interrupt (RTI).............................................................................................. 39
2

Table of Contents

SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
6.21 Direct Memory Access (DMA) ........................................................................................ 40
6.22 High-End Timer (N2HET), HET Transfer Unit (HTU) .............................................................. 40
6.23 Multi-Buffered Analog-to-Digital Converter (MibADC) ............................................................. 42
6.24 Enhanced Pulse Width Modulators (ePWM)........................................................................ 42
6.25 Enhanced Capture (eCAP)............................................................................................ 43
6.26 Enhanced Quadrature Encoder Pulse (eQEP) ..................................................................... 44
6.27 Multi Buffered Serial Peripheral Interface (MibSPI)................................................................ 45
6.28 Inter-Integrated Circuit (I2C) .......................................................................................... 46
6.29 Serial Communication Interface (SCI) ............................................................................... 46
6.30 Local Interconnect Network (LIN) .................................................................................... 47
6.31 Controller Area Network (DCAN)..................................................................................... 48
6.32 General-Purpose Input/Output (GIO) ................................................................................ 49
6.33 Ethernet.................................................................................................................. 49
6.34 External Memory Interface (EMIF) ................................................................................... 50
6.35 JTAG Debug, Trace, Calibration, and Test Access................................................................ 51
6.36 Cortex-R5F Central Processing Unit (CPU) Debug and Trace................................................... 51
6.37 Data Modification Module (DMM)..................................................................................... 51
6.38 RAM Trace Port Interface (RTP) ..................................................................................... 51
6.39 Parameter Overlay Module (POM)................................................................................... 52
6.40 Error Profiling Controller (EPC)....................................................................................... 52
6.41 Temperature Sensor ................................................................................................... 53
7 Brief Description of Diagnostics........................................................................................... 54
7.1 1oo2 Software Voting Using Secondary Free Running Counter ................................................. 54
7.2 Bit Error Detection ...................................................................................................... 54
7.3 Bit Multiplexing in FEE Memory Array ............................................................................... 54
7.4 Bit Multiplexing in Flash Memory Array.............................................................................. 54
7.5 Bit Multiplexing in Primary SRAM Memory Array................................................................... 54
7.6 Bit Multiplexing in Peripheral SRAM Memory Array................................................................ 54
7.7 CPU Illegal Operation and Instruction Trapping ................................................................... 55
7.8 Logic Built In Self-Test (LBIST) ...................................................................................... 55
7.9 Logic Built In Self-Test (LBIST) Auto-Coverage.................................................................... 56
7.10 CPU Lockstep Compare .............................................................................................. 56
7.11 VIM Lockstep Compare ............................................................................................... 56
7.12 Lockstep Comparator Self-Test....................................................................................... 56
7.13 CPU Online Profiling Using the Performance Monitoring Unit.................................................... 56
7.14 CPU Memory Protection Unit (MPU)................................................................................. 57
7.15 CRC Auto-coverage.................................................................................................... 57
7.16 CRC in Message........................................................................................................ 57
7.17 DCAN Acknowledge Error Detection................................................................................. 57
7.18 DCAN Form Error Detection .......................................................................................... 57
7.19 DCAN Stuff Error Detection........................................................................................... 57
7.20 DCAN Protocol CRC in Message..................................................................................... 57
7.21 Disable the DMM Pin Interface ....................................................................................... 58
7.22 Disable the RTP Pin Interface ........................................................................................ 58
7.23 Dual Clock Comparator (DCC)........................................................................................ 58
7.24 Autoload Self-Test...................................................................................................... 58
7.25 Efuse Autoload Self-Test Auto-Coverage ........................................................................... 58
7.26 EFuse ECC.............................................................................................................. 58
7.27 EFuse ECC Logic Self-Test........................................................................................... 58
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Contents
3
www.ti.com
7.28 eQEP Quadrature Watchdog.......................................................................................... 58
7.29 eQEP Software Test of Quadrature Watchdog Functionality ..................................................... 59
7.30 Error Trapping - IOMM................................................................................................. 59
7.31 Error Trapping (including Peripheral Slave Error Trapping) - L2/L3 Interconnect.............................. 59
7.32 Ethernet Alignment Error Detection.................................................................................. 59
7.33 Ethernet Physical Layer Fault ........................................................................................ 59
7.34 External Monitoring of Warm Reset (nRST) ........................................................................ 59
7.35 External Monitoring via ECLK......................................................................................... 59
7.36 External Voltage Supervisor........................................................................................... 60
7.37 External Watchdog ..................................................................................................... 60
7.38 FEE Contents Check by Hardware CRC ............................................................................ 60
7.39 FEE Data ECC.......................................................................................................... 60
7.40 FEE Sector Protection ................................................................................................. 60
7.41 Flash Address and Control Bus Parity............................................................................... 61
7.42 Flash Contents Check by Hardware CRC........................................................................... 61
7.43 Flash ECC ............................................................................................................... 61
7.44 Flash Hard Error Cache and Livelock................................................................................ 61
7.45 Flash Sector Protection ................................................................................................ 62
7.46 Flash Wrapper Address ECC ......................................................................................... 62
7.47 Flash Wrapper Diag Mode 5 Test .................................................................................... 62
7.48 Flash Wrapper Diag Mode 7 Test .................................................................................... 62
7.49 Glitch Filtering on nRST and nPORRST ............................................................................ 62
7.50 Hardware CRC Check of External Memory ......................................................................... 62
7.51 Hardware CRC Check of OTP Contents ............................................................................ 62
7.52 Hardware Disable of JTAG Port ...................................................................................... 62
7.53 Information Redundancy Techniques ................................................................................ 63
7.54 Information Redundancy Techniques - CPU Specific ............................................................. 63
7.55 Information Redundancy Techniques - DCAN Specific............................................................ 63
7.56 Information Redundancy Techniques - DMA Specific ............................................................. 63
7.57 Information Redundancy Techniques - N2HET Specific .......................................................... 63
7.58 Internal Voltage Monitor (VMON) .................................................................................... 64
7.59 Internal Watchdog ...................................................................................................... 64
7.60 IOMM Master ID Filtering.............................................................................................. 64
7.61 LIN Checksum Error Detection ....................................................................................... 64
7.62 LIN No-Response Error Detection.................................................................................... 64
7.63 LIN Physical Bus Error Detection..................................................................................... 65
7.64 LIN / SCI Bit Error Detection .......................................................................................... 65
7.65 LIN / SCI Frame Error Detection ..................................................................................... 65
7.66 LIN / SCI Overrun Error Detection.................................................................................... 65
7.67 Locking Mechanism for Control Registers........................................................................... 65
7.68 Lockout of JTAG Access Using AJSM............................................................................... 65
7.69 Low Power Oscillator Clock Detector (LPOCLKDET).............................................................. 65
7.70 Memory Protection Unit (MPU) for Non-CPU Bus Masters ...................................................... 65
7.71 MibADC Calibration .................................................................................................... 66
7.72 MibADC Information Redundancy Techniques..................................................................... 66
7.73 MibADC Input Self-Test................................................................................................ 66
7.74 MibSPI/SPI Data Length Error Detection............................................................................ 66
7.75 MibSPI/SPI Data Overrun Detection................................................................................. 66
4
Contents
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
7.76 MibSPI/SPI Slave Desync Detection................................................................................. 66
7.77 MibSPI/SPI Slave Timeout Detection................................................................................ 66
7.78 Monitoring by Second N2HET ........................................................................................ 67
7.79 Monitoring by eCAP or N2HET ....................................................................................... 67
7.80 Non-Privileged Bus Master Access .................................................................................. 67
7.81 OTP Autoload ECC..................................................................................................... 67
7.82 Parity in Message....................................................................................................... 67
7.83 Periodic Hardware CRC Check of OTP Contents.................................................................. 67
7.84 PCR Access Management: Protection Mode and MasterID Filtering............................................ 67
7.85 Periodic Hardware CRC Check of SRAM Contents................................................................ 68
7.86 Periodic Software Read Back of Static Configuration Registers ................................................ 68
7.87 Peripheral SRAM Parity................................................................................................ 68
7.88 Peripheral Memory ECC............................................................................................... 68
7.89 PLL Slip Detector ....................................................................................................... 68
7.90 Primary SRAM Address and Control Bus Parity.................................................................... 68
7.91 Primary SRAM Data and ECC Storage in Multiple Physical Banks per Logical Address..................... 69
7.92 Primary SRAM Correctable ECC Profiling .......................................................................... 69
7.93 ECC on Cache RAM ................................................................................................... 69
7.94 Primary SRAM Data ECC ............................................................................................. 69
7.95 Primary SRAM Wrapper Redundant Address Decode ............................................................ 69
7.96 Primary SRAM Hard Error Cache and Livelock .................................................................... 70
7.97 Privileged Mode Access and Multi-Bit Enable Keys for Control Registers...................................... 70
7.98 PBIST Check of Primary or Module SRAM ......................................................................... 70
7.99 PBIST Auto-coverage .................................................................................................. 71
7.100 Power Domain Inactivity Monitor..................................................................................... 71
7.101 PBIST Test of Parity Bit Memory..................................................................................... 71
7.102 PBIST Test of ECC Bit Memory...................................................................................... 71
7.103 Lockstep PSCON....................................................................................................... 71
7.104 Redundant Address Decode Self-Test .............................................................................. 71
7.105 Redundant Temperature Sensors.................................................................................... 71
7.106 Scrubbing of SRAM to Correct Detected Single Bit Errors ....................................................... 71
7.107 Shadow Registers...................................................................................................... 72
7.108 Software Check of Cause of Last Reset ........................................................................... 72
7.109 Software Read Back of CPU Registers ............................................................................. 72
7.110 Software Read Back of Written Configuration...................................................................... 72
7.111 Software Test of DCC Functionality ................................................................................. 72
7.112 Software Test of DWD Functionality................................................................................. 72
7.113 Software Test of DWWD Functionality .............................................................................. 72
7.114 Software Test of ECC Profiler (EPC) ................................................................................ 72
7.115 Software Test of Error Path Reporting .............................................................................. 72
7.116 Software Test of Flash Sector Protection Logic.................................................................... 72
7.117 Software Test of Function Including Error Tests ................................................................... 73
7.118 Software Test of Function Using I/O Loopback .................................................................... 73
7.119 Software Test of Function Using I/O Checking In GIO Mode .................................................... 73
7.120 Software Test of Function Using I/O Loopback in Transceiver/PHY ........................................... 73
7.121 Software Test of Function Using I/O Loopback Including Error Tests - IOMM Only .......................... 73
7.122 Software Test of Hardware CRC..................................................................................... 73
7.123 Software Test of MPU Functionality ................................................................................. 74
7.124 Software Test of Parity Logic ......................................................................................... 74
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Contents
5
www.ti.com
7.125 Software Test of PBIST ............................................................................................... 74
7.126 Software Test of SRAM Wrapper Address Decode Diagnostic and ECC ...................................... 74
7.127 Software Test for Reset ............................................................................................... 74
7.128 Software Warm Reset Generation................................................................................... 74
7.129 Transmission Redundancy............................................................................................ 74
7.130 Use of CoreSight Debug Logic Key Enable Scheme.............................................................. 74
7.131 Use of DCC as Program Sequence Watchdog..................................................................... 74
7.132 Use of MPUs to Block Access to Memory Mapped Debug....................................................... 75
7.133 Execution of Interconnect Self-Test.................................................................................. 75
7.134 CPU Interconnect Hardware Checker............................................................................... 75
7.135 Timeout Monitoring on The Bus Transaction ....................................................................... 75
7.136 Transaction ECC (Data Lines) ....................................................................................... 75
7.137 Transaction Parity (Address and Control Lines) ................................................................... 76
7.138 Peripheral Interconnect New Memory Protection Unit (NMPU) .................................................. 76
7.139 Software Test of The New Memory Protection Unit (NMPU) Functionality..................................... 76
7.140 Software Test of ECC Logic .......................................................................................... 76
7.141 Multi-Bit Keyed Self-Correctable High-Integrity Bits ............................................................... 76
8 Next Steps in Your Safety Development ................................................................................ 77
Appendix A Summary of Safety Feature Usage.............................................................................. 78
Appendix B Development Interface Agreement ............................................................................ 125
B.1 Appointment of Safety Managers.................................................................................. 125
B.2 Tailoring of the Safety Lifecycle.................................................................................... 125
B.3 Activities Performed by TI .......................................................................................... 127
B.4 Information to be Exchanged....................................................................................... 128
B.5 Parties Responsible for Safety Activities ......................................................................... 128
B.6 Communication of Target Values.................................................................................. 129
B.7 Supporting Processes and Tools.................................................................................. 129
B.8 Supplier Hazard and Risk Assessment........................................................................... 129
B.9 Creation of Functional Safety Concept ........................................................................... 129
Appendix C Revision History ..................................................................................................... 130
6
Contents
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
1 Device Revision Code Identification....................................................................................... 8
2 Hercules Product Architecture Overview................................................................................ 10
3 TI Standard MCU Automotive QM Development Process............................................................ 14
4 Hercules Enhanced Functional Safety Development Process....................................................... 17
5 Partition of Hercules MCU for Safety Analysis ......................................................................... 18
6 Operating States of the Hercules MCU ................................................................................. 21
7 Lockstep Temporal Diversity.............................................................................................. 30
8 Hercules Tailoring of Safety Lifecycle.................................................................................. 126
1 Identification of Parts/Elements .......................................................................................... 19
2 Summary of ESM Error Indication ....................................................................................... 22
3 Key to Summary of Safety Features and Diagnostics................................................................. 78
4 Summary of Safety Features and Diagnostics ........................................................................ 79
5 Activities Performed by TI vs. Performed by SEooC Customer .................................................... 127
6 Product Safety Documentation.......................................................................................... 128
7 Product Functional Documentation to be Considered in Safety-Related Design................................. 128
8 Product Safety Documentation Tools and Formats.................................................................. 129
9 SPNU575A Revisions.................................................................................................... 130
List of Figures
List of Tables
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
List of Figures
7
843BZWTT ##B-#######
RM57L
G1 __
Device Revision Code
User's Guide
SPNU575A–May 2014–Revised September 2016
Safety Manual for RM57x Hercules ARM Safety MCUs

1 Introduction

You, a system and equipment manufacturer or designer, are responsible to ensure that your systems (and any TI hardware or software components incorporated in your systems) meet all applicable safety, regulatory, and system-level performance requirements. All application and safety related information in this document (including application descriptions, suggested safety measures, suggested TI products, and other materials) is provided for reference only. You understand and agree that your use of TI components in safety critical applications is entirely at your risk, and that you (as buyer) agree to defend, indemnify, and hold harmless TI from any and all damages, claims, suits, or expense resulting from such use.
This document is a safety manual for the Texas Instruments Hercules safety critical microcontroller product family. The product family utilizes a common safety architecture that is implemented in multiple application focused products. Product configurations supported by this safety manual include silicon revisions A and B of the following products: (Note that the part numbers listed below are for revision B; other revisions are slightly different. The device revision can be determined by the symbols marked on the top of the device as seen in Figure 1 below this list).
• RM4xx Safety Critical Microcontrollers – RM57L843-ZWT (Orderable Part #: RM57L843BZWTT) – RM57L843-ZWT (Orderable Part #: RM57L843BZWTTR)
SafeTI is a trademark of Texas Instruments. ARM, Cortex are registered trademarks of ARM Limited. Adobe is a trademark of Adobe Systems Incorporated in the United States, and/or other countries. IBM, DOORS are registered trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Microsoft, Excel are registered trademarks of Microsoft Corporation in the United States and/or other countries, or both. All other trademarks are the property of their respective owners.
8
Figure 1. Device Revision Code Identification
This Safety Manual provides information needed by system developers to assist in the creation of a safety critical system using a supported Hercules microcontroller. This document contains:
• An overview of the superset product architecture
• An overview of the development process utilized to reduce systematic failures
• An overview of the safety architecture for management of random failures
• The details of architecture partitions, implemented safety mechanisms
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
The following information is documented in the Safety Analysis Report Summary for RM57x ARM®-Based Safety Critical Microcontrollers (SPNU578) and is not repeated in this document:
• Summary of failure rates of the MCU estimated at the chip level
• Assumptions of use utilized in calculation of safety metrics
• Summary of targeted standard (IEC 61508, ISO 26262, and so forth) safety metrics at the chip level
The following information is documented in the Detailed Safety Analysis Report for RM57x ARM®-Based Safety Critical Microcontrollers (SPNU579) and is not repeated in this document:
• Fault model used to estimate device failure rates suitable to enable calculation of customized failure
• Quantitative FMEA (also known as FMEDA, Failure Modes, Effects, and Diagnostics Analysis) with
The following information is documented in the Safety Report, and will not be repeated in this document:
• Results of assessments of compliance to targeted standards
The user of this document should have a general familiarity with the Hercules product families. For more information, see http://www.ti.com/hercules. This document is intended to be used in conjunction with the pertinent data sheets, technical reference manuals, and other documentation for the products under development.
For information which is beyond the scope of the listed deliverables, please contact your TI sales representative or http://www.ti.com.
Introduction
rates
detail to the sub-module level of the device, suitable to enable calculation based on customized application of diagnostics
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
9
Level Two Hierarchy
Level Three Hierarchy
Level One Hierarchy
Cortex R5F CPU
Cluster
Bus Master
Peripheral
Bus Master
Peripheral
Debug Bus
Master
General
DMA
Level Two
CPU Master
Level Two
CPU Slave
Peripheral Central Resource 1
Peripheral
Peripheral
Peripheral
Peripheral
Peripheral
Peripheral
Bus Master
Peripheral
Peripheral Central Resource n
Peripheral
Peripheral
Peripheral
Peripheral
Peripheral
Peripheral
Low Latency
Peripheral Port
Peripheral InterconnectCPU Interconnect
CRCCRC
Flash External
Memory
Interface
SRAM
Flash Emulated
EEPROM
Hercules RM57x Product Overview

2 Hercules RM57x Product Overview

The RM57x 65 nm Hercules product family is an evolution of the proven TMS570LS Hercules products in the 65 nm manufacturing process. A simplified graphical view of the product superset architecture can be seen in Figure 2. This is a basic representation of the architecture and is not all inclusive. For example, products in the family may scale based on the number of peripherals, number of bus master peripherals, or amount of memory - but the programmer's model remains consistent.
www.ti.com
Figure 2. Hercules Product Architecture Overview
10
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
The Hercules product architecture utilizes the ARM Cortex®-R5F CPU in a cached memory configuration with both instruction and data caches. The Cortex-R5F CPU is implemented with a checker Cortex-R5F CPU in a lockstep configuration. This provides cycle by cycle checking of correct CPU operation while keeping a simple, easy to use, single core programmer's model. The Cortex R5F CPU has a multi­threaded level two bus master interface, which provides access to the level two memory hierarchy, supporting up to seven concurrent CPU accesses in flight. A level two slave interface allows bus masters access to the level one cache memories for test, debug, and fault insertion purposes. A separate low latency peripheral port provides access to peripherals. In addition, a Snoop Control Unit (SCU) module is present to snoop non-CPU bus master accesses for the purpose of I/O cache coherency.
The level two device hierarchy is dominated by two switched central resource interconnect modules (also known as bus matrices or crossbars): CPU Interconnect Subsystem and Peripheral Interconnect Subsystem. These device level interconnect modules allow multiple bus masters to access multiple bus slaves. Prioritization, routing, decode, and arbitration functions are provided. Access to the memory subsystem (Flash, FEE, SRAM, and EMIF) is provided via the CPU Interconnect Subsystem. Peripherals are accessed via the Peripheral Interconnect Subsystem and multiple level three peripheral interconnect segments (PCR1, PCR2, and PCR3). Bus masters to the level two device hierarchy include CPUs, bus master peripherals, debug bus masters, and general purpose direct memory access (DMA) controllers. Bus slaves on the level two hierarchy include the primary Flash memory, primary SRAM, Flash EEPROM emulation memory, and external memory interface (EMIF), one or more peripheral bus segments (PCRs), and Cortex-R5F slave port access..
The level three hierarchy is primarily composed of peripherals. Peripherals are grouped into one or more peripheral bus segments (PCRs), managed by a peripheral central resource. The peripheral central resource provides address decode functionality for bus transactions targeting peripherals.
Hercules RM57x Product Overview

2.1 Targeted Applications

The Hercules MCU family is targeted at general purpose safety applications. Multiple safety applications were analyzed during the concept phase. Example target applications include:
• Automotive braking systems, including anti-lock braking (ABS), anti-lock braking with traction control (ABS+ TC), and electronic stability control (ESC)
• Motor control systems, particularly electronic power steering (EPS) systems and electric vehicle (EV) power train
• General purpose safety computation, such as integrated sensor cluster processing and vehicle strategy generation in an active safety system
• Industrial automation such as programmable logic controllers (PLCs) and programmable automation controllers (PACs) for safety critical process control
In the case of overlapping requirements between target systems, TI has attempted to design the device respecting the most stringent requirements. For example, the fault tolerant time intervals for timer logic in an ESC application are typically on the order of 100 ms. In an EPS application, the fault tolerant time interval is typically on the order of 10 ms. In such case, TI has performed timer subsystem analysis respecting <10 ms fault tolerant time interval.
While TI considered certain applications during the development of these devices, this should not restrict a customer who wishes to implement other systems. With all safety critical components, rationalization of the component safety concept to the system safety concept should be executed by the system integrator.
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
11
Hercules RM57x Product Overview

2.2 Product Safety Constraints

This device is a Type B device, as defined in IEC 61508:2010 This device claims no hardware fault tolerance (HFT = 0), as defined in IEC 61508:2010 For safety components developed according to many safety standards, it is expected that the component
safety manual will provide a list of product safety constraints. For a simple component, or more complex components developed for a single application, this is a reasonable response. However, the Hercules product family is both a complex design and is not developed targeting a single, specific application. Therefore, a single set of product safety constraints cannot govern all viable uses of the product. The Detailed Safety Analysis Report for RM57x ARM®-Based Safety Critical Microcontrollers (SPNU579) provides a reference implementation of the Hercules product in a common system with relevant product safety constraints.
www.ti.com
12
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
Hercules Development Process for Management of Systematic Faults

3 Hercules Development Process for Management of Systematic Faults

For a safety critical development, it is necessary to manage both systematic and random faults. Texas Instruments has created a unique development process for safety critical semiconductors that greatly reduces probability of systematic failure. This process builds on a standard Quality Managed (QM) development process as the foundation for safety critical development. This process is then augmented by a second layer of development activities that are specific to safety critical developments targeting IEC
61508.
In 2007, TI first saw the need to augment this standard development process in order to develop products according to IEC 61508. TI engaged with safety industry leader exida consulting to ensure the development was compliant to the standard. During 2008, a process for safety critical development according to IEC 61508 1st edition was implemented. This process has been executed on multiple microcontroller developments that are currently shipping into safety critical systems. The Hercules family product and safety architectures described in this document began development under the IEC 61508 development flow.
By mid 2009, it became clear that the emerging IEC 61508 2nd edition functional safety standards would require enhanced process flow capabilities. Due to the lack of maturity of these draft standards, it was not possible to implement a development process that ensured compliance before final drafts were available.
In mid 2010, TI started development of a process flow compliant to IEC 61508 2nd edition. TI worked in detail with Yogitech and found that the companies have complementary capabilities. A partnership was established for engineering services and safety consulting services to accelerate new safety-related product development. Yogitech's existing fRMethodology development process and TI's IEC 61508 development process were merged and enhanced to create a new process addressing IEC 61508 2nd edition.
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
13
Business
Opportunity
Prescreen
Program Planning
Create
Validate
Sample
Characterize
Qualify
Ramp Æ Sustain
Design In Team
Sustain
Team
Cross Functional Team
Identify new
product
opportunities
Develop
project plan
IC design and
layout
Characterize
Develop
manufacturing
test
Develop & build marketing collateral
Sample to customers
Qualification
Build initial inventory
Optimize test
flow and yeilds
Manage project risks (market and execution)
Bench & ATE
verification
CP0
Commission
Review
CP1 Design Kickoff Review
CP2
PG Review
CP2.5
Qual Start
Review
CP3
TMS Review
CP4 Safe
Launch Review
Hercules Development Process for Management of Systematic Faults

3.1 TI Standard MCU Automotive Development Process

Texas Instruments has been developing automotive microcontrollers for safety critical and non-safety critical automotive applications for over twenty years. Automotive markets have strong requirements on quality management and high reliability of product. Though not explicitly developed for compliance to a functional safety standard, the TI standard MCU Automotive development process already features many elements necessary to manage systematic faults. This development process can be considered to be Quality Managed (QM), but does not achieve an IEC 61058 Safety Integrity Level (SIL). For up-to-date information on TI quality process certifications, see http://www.ti.com/quality.
The standard process breaks development into phases:
• Business opportunity pre-screen
• Program planning
• Create
• Validate, sample, and characterize
• Qualify
• Ramp to production and sustaining production The standard process is illustrated in Figure 3.
www.ti.com
Figure 3. TI Standard MCU Automotive QM Development Process
14
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
Hercules Development Process for Management of Systematic Faults

3.2 TI MCU Automotive Legacy IEC 61508 Development Process

Texas Instruments developed an initial process for developing safety critical automotive microcontrollers in
2008. This process was developed targeting the IEC 61508 1st edition standard, as augmented with available committee drafts of the 2nd edition. The process is developed as an additional layer of activities that should be carried out in addition to the standard MCU Automotive QM development process. This process as applied on the TMS570LS20216S product development has been assessed suitable for use in IEC 61508 SIL 3 applications by exida Certification S.A. (certificate TI 071227 C001). In July 2012 the development process and the TMS570LS20x/10x product family was assessed to the IEC 61508:2010 standard and certified suitable for use in IEC 61508 SIL 3 applications by exida Certification Services (certificate TI 1204073 C001).
Key new activities in this process included:
• Nomination of a safety manager with ownership of all safety related activities
• Development of a safety plan to track safety related activities
• Generation, application, and validation of safety requirements
• Execution of qualitative (FMEA) and quantitative (FMEDA) safety analysis
• Authoring of safety manual and safety analysis report to support customer development

3.3 Yogitech fRMethodology Development Process

fRMethodology is the “white-box” approach for safety design exploration proprietary of YOGITECH, including:
• fRFMEA, a methodology to perform the FMEA of an integrated circuit in accordance to IEC 61508
• fRFI, a tool to perform fault injection of an integrated circuit based on inputs derived from fRFMEA YOGITECH’s fRMethodology mainly consists of:
• Splitting the component or system in elementary parts (“sensitive zones”)
• Computing their failure rates
• Using those failure rates to compute safety metrics
• Validating the results with fault injection
• Allowing sensitivity analyses of those metrics by changing architectural or technological parameters
• Delivering to the customer numbers to compare different architectures

3.4 Hercules Enhanced Safety Development Process

The Hercules enhanced safety development process is a merger of the existing TI and Yogitech flows for functional safety development. The goal of the process development is to take the best aspects of each flow and collaborate, resulting in the best in class capabilities to reduce systematic faults.
The process flow is targeted for compliance to IEC 61508, and is under a process of continuous improvement to incorporate new features of emerging functional safety standards. These functional safety standards are targeted because TI and Yogitech believe they best represent the state of the art in functional safety development for semiconductors. While not directly targeted at other functional safety standards, it is expected that products developed to industry state-of-the-art can be readily utilized in other functional safety systems.
The resulting flow was subsequently assessed by TUEV SUED for compliance to IEC 61508 and ISO 26262 and further enhanced based on technical findings. The development flow is certified by TUEV SUED under certificate Q4B 13 03 84071 001.
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
15
Hercules Development Process for Management of Systematic Faults
Key elements of the combined process flow are:
• Assumptions on system level design, safety concept, and requirements based on TI's expertise in safety critical systems development
• Combined qualitative and quantitative or similar safety analysis techniques comprehending the sum of silicon failure modes and diagnostic techniques known to both TI and Yogitech
• Fault estimation based on multiple industry standards as well as TI manufacturing data
• Application of Yogitech's state-of-the-art fault injection techniques for validation of claimed diagnostic coverage
• Integration of lessons learned by both companies through multiple safety critical developments to IEC 61508
The Figure 4 is shown below in a simplified graphic.
www.ti.com
16
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Phase 0
Business
Opportunity
Prescreen
Phase 1
Program Planning
Phase 2
Create
Phase 2.5
Validate, Sample,
and
Characterize
Phase 3
Qualify
Phase 4
Ramp/Sustain
Determine if safety
process execution is
necessary
Execute development
interface agreement
(DIA) with lead customers and
suppliers
Define SIL/ASIL
capability
Generate safety plan
Initiate safety case
Analyze system to
generate system level
safety assumptions
and requirements
Develop component
level safety
requirements
Validate component safety requirements
meet system safety
requirements
Implement safety
requirements in design
specification
Validate design
specification meets
component safety
requirements
Confirmation measure
review
Validate safety design
in silicon
Release safety
manual
Release safety analysis report
Characterization of
safety design
Confirmation measure
review
Qualification of safety
design
Release safety case
report
Update safety manual
(if needed)
Update safety analysis
report (if needed)
Confirmation measure
review
Implement plans to
support operation and
production
Update safety case
report (if needed)
Periodic confirmation
measure reviews
Qualitative analysis of
design (FMEA and
FTA)
Develop safety
product preview
Validation of safety
design at RTL level
Quantitative analysis
of design (FMEDA)
Validation of safety
design at gate/layout
level
Confirmation measure
review
Execute safety design
Incorporate findings
into safety design
Incorporate findings
into safety design
www.ti.com
Hercules Development Process for Management of Systematic Faults
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Figure 4. Hercules Enhanced Functional Safety Development Process
Safety Manual for RM57x Hercules ARM Safety MCUs
17
CPU Cache
with ECC
Dual Cortex-R5F CPUs in
Lockstep
CPU Interconnect Subsystem
Peripheral Central
Resource #1
SRAM
With
ECC
Flash
with ECC
& Flash for EEPROM
Emulation
with ECC
CRC2
ESM
CRC1
Lockstep
VIMs
RTI
DCC1
STC1
DCC2
STC2
EFUSE
IOMM
PMM
EPC
SCM
SYS
CCM-
R5F
EMIF
Slave
EMAC Slaves
eQEP
1,2
eCAP
1..6
eTPWM
1..7
SCI3
SCI4
I2C1
I2C2
GIO
DCAN1
DCAN2
DCAN3
DCAN4
MibSPI1
MibSPI2
MibSPI3
MibSPI4
MibSPI5
LIN1/SCI1
LIN2/SCI2
N2HET1
N2HET2
MibADC1
MibADC2
Temp Sensor[1..3]
RTP
POM
Peripheral Central
Resource #2
Peripheral Central
Resource #3
DMA EMAC HTU1
HTU2
DAP DMM
Peripheral Interconnect Subsystem
EMIF
Hercules Product Architecture for Management of Random Faults

4 Hercules Product Architecture for Management of Random Faults

For a safety critical development it is necessary to manage both systematic and random faults. The Hercules product architecture includes many safety mechanisms, which can detect and respond to random faults when used correctly. This section of the document describes the architectural safety concept for the MCU.

4.1 Safe Island Philosophy and Architecture Partition to Support Safety Analysis (FMEA/FMEDA)

The RM4x Hercules processors share a common safety architecture concept called a “safe island” philosophy. The basic concept involves a balance between application of hardware diagnostics and software diagnostics to manage functional safety, while balancing cost concerns. In the “safe island” approach, a core set of elements are allocated continuously operating hardware safety mechanisms. This core set of elements, including power and clock and reset, CPU, Flash memory, SRAM and associated interconnect to Flash and SRAM, is needed to assure any functionally correct execution of software. Once correct operation of these elements is confirmed, software can be executed on these elements in order to provide software-based diagnostics on other device elements, such as peripherals. This concept has been proven viable through multiple generations of safety-critical products in the automotive passenger vehicle space.
Figure 5 illustrates the safe island approach overlaid to a superset configuration of the Hercules product
architecture.
www.ti.com
Figure 5. Partition of Hercules MCU for Safety Analysis
18
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
Figure 5 illustrates three architectural partitions:
• “Safe Island Layer” (RED) – This is the region of logic that is needed for all processing operations. This
logic is protected heavily by on board hardware diagnostics and specific assumptions of use to assure a high level of confidence in safe operation. Once this region is safed, it can be used to provide comprehensive software diagnostics on other design elements.
• “Blended Layer” (BLUE) – This is the region of logic that includes most safety critical peripherals. This
region has less reliance on hardware diagnostics. Software diagnostics and application protocols are overlaid to provide the remainder of needed diagnostic coverage.
• “Offline Layer” (BLACK) – This region of logic has minimal or no integrated hardware diagnostics.
Many features in this layer are used only for debug, test, and calibration functions; they are not active during safety critical operation. Logic in this region could be utilized for safety critical operation assuming appropriate software diagnostics or system level measures are added by the system integrator.

4.2 Identification of Parts/Elements

For the purposes of a safety analysis, each module on this device can be considered to be a part or element. Each part or element has been assigned a three letter unique identifier, which is used uniformly in the Safety Manual, Safety Analysis Report, and FMEDA Documents to identify the element and it's diagnostics. Table 1 lists each element present on this device and the unique identifier for this element. The overall IEC 61508 systematic capability of the MCU is SC3. TI does not make claims of systematic capability for specific IP modules on the device.
Table 1. Identification of Parts/Elements
Hercules Product Architecture for Management of Random Faults
Part / Element Name Unique Identifier
Clock CLK Cortex-R5F Central Processing Unit (CPU) CPU Controller Area Network (DCAN) CAN Cortex-R5F Central Processing Unit (CPU) Debug and Trace DBG CPU Interconnect Subsystem MEM Data Modification Unit DMM Direct Memory Access (DMA) DMA Enhanced Capture (eCAP) CAP EFuse Static Configuration EFU External Memory Interface (EMIF) EMF Enhanced Pulse Width Modulators (ePWM) PWM Enhanced Quadrature Encoder Pulse (eQEP) QEP Error Profiling Controller EPC Error Signaling Module (ESM) ESM Ethernet ETH Flash EEPROM Emulation (FEE) FEE Primary Flash FLA General Purpose Input/Output (GIO) GIO Inter-Integrated Circuit (I2C) IIC Input/Output (I/O) Multiplexing Module (IOMM) IOM Joint Technical Action Group (JTAG) Debug/Trace/Calibration
Access Local Interconnect Network (LIN) LIN Multi-Buffered Analog to Digital Converter (MibADC) ADC Multi-Buffered Serial Peripheral Interface (MibSPI) MSP High-End Timer (N2HET) Including HET Transfer Unit (HTU) HET One Time Programmable (OTP) Flash Static Configuration OTP Peripheral Interconnect Subsystem PER
JTG
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
19
Hercules Product Architecture for Management of Random Faults
Table 1. Identification of Parts/Elements (continued)
Part / Element Name Unique Identifier
Peripheral Central Resource 1 P1T Peripheral Central Resource 2 P2T Peripheral Central Resource 3 P3T Power Management Module (PMM) PMM Parameter Overlay Module POM Power Supply PWR RAM Trace Port RTP Reset RST Real Time Interrupt (RTI) Operating System Timer RTI Serial Communications Interface (SCI) SCI SRAM RAM System Control Module SYS Temperature Sensors TSN Vectored Interrupt Module (VIM) VIM
NOTE: The terms "element" and "part" may have specific meaning and imply specific requirements dependent on the targeted functional safety standard. The terms are used here in a general sense.
TheHercules Architecture Brief Description of Elements section contains a brief description of the elements listed above. For a full functional description of any of these modules, see the device-specific technical reference manual.
www.ti.com

4.3 Management of Family Variants

The Hercules family architecture supports multiple product variants. These products could be implemented as unique silicon designs or they can be shared silicon designs that have elements disabled or not assured by specification, even if present in silicon. Only the elements of the superset architecture that are specifically detailed in the device-specific data sheet and technical reference manual are assured to be present and operate. When developing for the Hercules platform, it is recommended that the safety concept be based on the superset product architecture to enable maximum scalability across family variants. The superset architecture shown in the previous section is valid for all device part numbers noted in the introduction of the safety manual.

4.4 Operating States

The Hercules MCU products have a common architectural definition of operating states. These operating states should be observed by the system developer in their software and system level design concepts. The operating states state machine is shown in Figure 6 and described below.
20
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
SafePowered Off
Power applied
nPORRST held
Cold Boot
nPORRST released
Warm Boot
SYS_nRST released internally
Operational
Proof tests completed
System init completed
nPORRST driven
Power Removed
SYS_nRST driven
nPORRST driven
nPORRST driven
www.ti.com
Hercules Product Architecture for Management of Random Faults
Figure 6. Operating States of the Hercules MCU
• "Powered Off" - This is the initial operating state of the Hercules MCU. No power is applied to either
core or I/O power supply and the device is non-functional. This state can only transition to the safe state, and can only be reached from the safe state.
• "Safe" - In the safe state, the Hercules MCU is powered but non-operational. The nPORRST (power-on
reset, also known as cold reset) is asserted by the system but is not released until power supplies have ramped to a stable state. The internal voltage monitor (VMON) safety mechanism also continues to assert the nPORRST internal to the device if power supplies are not within a minimum operational range. When the product is in the safe state, the CPU and peripherals are non-functional. Output drivers are tri-stated and input/output pins are kept in an input only state.
• "Cold Boot" - In the cold boot state, key analog elements, digital control logic, and debug logic are
initialized for future use. The CPU remains powered but non-operational. When the cold boot process is completed, the SYS_nRST signal is internally released, leading to the warm boot stage. The SYS_nRST signal transition change can be monitored externally on the SYS_nRST I/O pin.
• "Warm Boot" - The warm boot mode resets digital logic and enables the CPU. The CPU begins
executing software from Flash memory and software initialization of the device can begin. There is no hardware interlock to say that warm boot is completed; this is a software decision.
• "Operational" - During the operational mode, the device is capable of supporting safety critical
functionality.
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
21
Hercules Product Architecture for Management of Random Faults

4.5 Management of Errors

When a diagnostic detects a fault, the error must be indicated. The Hercules product architecture provides aggregation of fault indication from internal safety 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. The ESM does not, in and of itself, impact the overall function of the device and serves the limited purpose of fault aggregation and classification. The error classifications in the ESM are summarized in Table 2.
Table 2. Summary of ESM Error Indication
Error Group Interrupt Response Error Pin Response Notes
1 2 Non maskable interrupt generated Error pin activated For errors that are generally of critical severity 3 No interrupt response Error pin activated
The error response is action that is taken by the MCU or system when an error is indicated. There are multiple potential of error response possible for the Hercules product. The system integrator is responsible to determine what error response should be taken and to ensure that this is consistent with the system safety concept.
• CPU abort - This response is implemented directly in the CPU, for diagnostics implemented in the
CPU. During an abort, the program sequence transfers context to an abort handler and software has an opportunity to manage the fault.
• CPU interrupt - This response can be implemented for diagnostics outside the CPU. An interrupt
allows events external to the CPU to generate a program sequence context transfer to an interrupt handler where software has an opportunity to manage the fault.
• Generation of SYS_nRST - This response allows the device to change states to warm boot from
operational state. The SYS_nRST could be generated from an external monitor or internally by the software reset or watchdog. Re-entry to the warm reset state allows possibility for software recovery when recovery in the operational state was not possible.
• Generation of nPORRST - This response allows the device to change state to safe state from cold
boot, warm boot, or operational states. From this state, it is possible to re-enter cold boot to attempt recovery when recovery via warm boot is not possible. It is also possible to move to the powered-down state, if desired, to implement a system level safe state. This response can be generated from the internal voltage monitor, but is primarily driven by monitors external to the MCU.
The ESM provides multiple registers that can be read by the CPU to determine the current status of diagnostics and the state of the nERROR pin. For the severe group 2 errors, a shadow register is provided that is not reset by SYS_nRST. This allows the possibility of warm reset reinitialization to identify that a group 2 error initiated the external reset.
It is possible for the CPU to trigger the nERROR pin response manually to test system behavior or to notify external logic of an internal fault not automatically indicated to ESM. The CPU is responsible to clear indicated errors in the ESM, including clearing of the nERROR pin response.
The EPC is used as a complement to the ESM for error profiling . The primary goal of this module is to provide a unified correctable ECC error (single bit ECC fault) profiling capability and error address cache on ECC failures in system bus memory slaves like Flash, FEE, and SRAM. The secondary goal of this module is to provide an ECC error reporting capability for bus masters, which do not natively have ECC logic built in like the DMA and TUs. The ECC generation and evaluation logic for bus masters such as DMA and the TUs are built into the CPU Interconnect Subsystem.
System level management of the external error response can be simplified through the use of a TI TPS6538x power supply and safety companion device developed for use with the Hercules family.
Programmable interrupt and programmable interrupt priority
Programmable response
www.ti.com
For errors that are generally not of critical severity
For critical errors that are seen by diagnostic implemented in CPU
22
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com

5 System Integrator Recommendations

You, as a system and equipment manufacturer or designer, are responsible to ensure that your systems (and any TI hardware or software components incorporated in your systems) meet all applicable safety, regulatory, and system-level performance requirements. All application and safety related information in this document (including application descriptions, suggested safety measures, suggested TI products, and other materials) is provided for reference only. You understand and agree that your use of TI components in safety critical applications is entirely at your risk, and that you (as buyer) agree to defend, indemnify, and hold TI harmless from any and all damages, claims, suits, or expense resulting from such use.
A brief description of each element on this device and the general assumptions of use are provided in
Section 6.
A list of diagnostic mechanisms for this device and a brief description for each diagnostic are provided in
Section 7.
The effectiveness of the hardware safety mechanisms is noted in the Detailed Safety Analysis Report for RM57x ARM®-Based Safety Critical Microcontrollers (SPNU579).
This information should be used to determine the strategy for utilizing safety mechanisms. The details of each safety mechanism can be found in the device-specific technical reference manual.
Depending on the safety standard and end equipment targeted, it may be necessary to manage not only single point faults, but also latent faults. Many of the safety mechanisms described in this section can be used as primary diagnostics, diagnostics for latent fault, or both. When considering system design for management of latent faults, take care to include failure of execution resources when considering latent faults with software diagnostics, such as failure of CPU and memories.
System Integrator Recommendations

5.1 System Integrator Activities

The system integrator is responsible for carrying out a number of product development activities. These activities carried out may include but are not limited to the following:
• Operational and Environmental Constraints
– Verify that the implementation of the TI component in the system design is compliant to
requirements in TI documentation. This includes but is not limited to the requirements found in technical reference manuals, data sheets, errata documents, safety manuals, and safety analysis reports
– Verify that the system operational lifetime (power-on hours) does not exceed lifetime specifications
for the TI component, as specified in the device data sheet. If the operational lifetime (power-on hours) is not specified in the data sheet, the use case does not match published conditions, or there are questions regarding device lifetime, please contact a TI quality/reliability engineering
representative or http://www.ti.com. – Define system maintenance requirements. The Hercules MCU does not require maintenance. – Define system repair requirements. The Hercules MCU is non-repairable with respect to permanent
faults. A power-on reset of the Hercules MCU may be considered a repair activity for transient
faults per some definitions of system repair requirements. – Define system decommissioning requirements. The Hercules MCU has no specific decommisioning
requirements. – Define system disposal requirements. The Hercules MCU has no specific disposal requirements.
• Avoidance of Systematic Errors – Verify the application of appropriate best practices at all stages of hardware and system
development (including development of hardware and system diagnostics external to the MCU) to avoid systematic failure and to control random failures. This may include but is not limited to compliance to the requirements documented in IEC61508-2;Annex A Tables A.15 through A.18, as well as Annex B Tables B.1 through B.6
– Verify that any software implemented (including software diagnostics) is developed with an
appropriate set of measures to avoid systematic errors
• Safety Concept Definition – Define the supported safety functions and verify that the microcontroller behaves properly to
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
23
System Integrator Recommendations
support execution of the defined safety function. This microcontroller is a generic product, which is capable of supporting a variety of safety functions but does not have fixed support for any specific safety function.
– Define the system-level safe state concept considering safe-state entry, maintenance of safe state,
and safe-state exit as appropriate to the application and verify correct implementation – Define the system-level error-handling concept and verify correct implementation. – Define appropriate overall timing requirements for safety metrics to be calculated for the application – Define appropriate safety metric targets for the application
• Safety Concept Implementation – Select and implement an appropriate set of diagnostics and safety mechanisms from the MCU
safety manual as necessary to satisfy the requirements of the targeted standards and the high level safety concept. Dependent on the results of the system level safety analysis, it may not be necessary to implement all diagnostic measures which TI has identified.
– For the device diagnostics listed as "system" in Table 4, implement the diagnostic in a manner that
meets functional safety requirements of the system, particularly monitoring of the external clock, monitoring of voltage, and MCU state monitoring via external watchdog logic. TI's recommendations are based on analysis of what faults might be detected external to the MCU when considering fault models/failure modes described in IEC 61508 -2 Annex A as to be considered for any claims of high diagnostic coverage, including both permanent and transient failure modes.
– Implement appropriate mechanisms to detect shorts between pins on the device. Tests may include
I/O loopback tests, information redundancy, or system-level mechanisms designed to detect shorts.
– Any end-to-end communications diagnostics implemented should consider the failure modes and
potential mitigating safety measures described in IEC 61784-3:2010 and summarized in IEC 61784­3:2010 in Table 1.
– Ensure that any additional system level hardware or software diagnostics created or implemented
by the system integrator are developed with an appropriate process to avoid systematic errors.
– Define an appropriate diagnostic test interval per diagnostic to be implemented.
• Verification of Safety Concept including Safety Metric Calculation – Verify the behavior of the MCU outputs in the system when the MCU is in a faulted condition. – Evaluate the system design for specific failure modes of functional logic and diagnostic logic which
are detectable based on the specific application usage and the specific diagnostics applied. TI's safety analysis for the MCU considers all fault models noted in IEC 61508-2 Annex A as to be considered for any claims of high diagnostic coverage, including both permanent and transient failure modes. Refer to the Safety Analysis Report for more details.
– Evaluate the system design for specific failure modes of functional logic and diagnostic logic which
are not detectable based on the specific application usage and the specific diagnostics applied. TI's safety analysis for the MCU considers all fault models noted in IEC 61508-2 Annex A as to be considered for any claims of high diagnostic coverage, including both permanent and transient failure modes. Refer to the Safety Analysis Report for more details and ensure that the system design considers system level diagnostics recommended by TI, such as external voltage
supervision, external watchdog, and so forth. – Verify that the implemented diagnostics meet the target diagnostic test interval per diagnostic. – Estimate failure rates and diagnostic coverage per failure mode with respect to specific application
usage. TI provides tools to support this activity in the Safety Analysis Report (SAR). – Verify that environmental and operational constraints are properly modeled in the FMEDA to
provide failure rate estimates. – Verify that appropriate on-chip design elements are selected in the FMEDA for the specific safety
function under analysis. – Verify that targeted safety metrics are calculated and achieved – Verify the diagnostic coverage achieved by the implemented system and software based
diagnostics. – Verify that the safety analysis considers MCU elements which are necessary to support the primary
function, such as clock, power, OTP configuration, and similar. Many times the focus of analysis is
www.ti.com
24
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
System Integrator Recommendations
the functional datapath but the elements necessary to support proper operation should also be
considered. – Execute a co-existence/freedom from interference analysis per the targeted standard to confirm that
implemented functionality can co-exist without interference. – Execute a dependent failure/common cause analysis to consider possible dependent/common
cause failures on the sub-elements of the MCU, including pin level connections.

5.2 Hints for Performing Dependent/Common Cause Failure Analysis Including the Hercules MCU

The following steps may be useful for performing dependent/common cause failure analysis when using the Hercules MCU:
• Consider a relevant list of dependent fault/common cause fault initiators, such as the lists found in the
draft ISO/PAS 19451 document, “Application of ISO 26262 to Semiconductors”
• Verify that the dependent failure analysis considers the impact of the software tasks running on the
MCU, including hardware and software interactions and task/operating system interactions.
• Verify that the dependent failure analysis considers the impact of pin/ball level interactions on the MCU
package, including aspects related to the selected I/O multiplexing

5.3 Hints for Improving Independence of Function/Co-Existence of Function When Using the Hercules MCU

The following steps may be useful for improving independence of function when using the Hercules MCU:
• Verify that unused interrupt channels are disabled in the VIM
• Verify that unused interrupt sources are disabled in the source peripherals
• Hold peripheral chip selects in reset with the PCR if the peripherals are unused
• Leave peripherals in default reset state if not controlled via PCR
• Power down power domains if all logic in power domain is not used
• Disable event triggers if unused
• Power down the ADC cores if MibADCs are unused
• Utilize peripheral bus master memory protection units (MPUs) to only allow access to needed transmit
and receive buffers
• Utilize the CPU MPU to support isolation of separate software tasks running on the CPU
• Utilize privileged access modes as a secondary level of task isolation
• Utilize bus master ID filtering when available to limit allocation of peripherals to bus masters
• When possible, separate critical I/O functions by using non adjacent I/O pins/balls. Consider using the
pin muxing logic to support such separation.
• Power down unused clock sources.
• Disable unused clock domains.
• Power down the flash pump logic if flash memory is not used after boot.

5.4 Support for System Integrator Activities

If you have any questions regarding usage of the TI documentation for system integration, or if you have questions regarding MCU level functional safety standard work products not provided as part of the TI documentation package, please contact TI support. The preferred and fastest method to contact TI support is via the E2E forum at http://e2e.ti.com/support/microcontrollers/hercules/default.aspx.
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
25
Brief Description of Elements

6 Brief Description of Elements

This section contains a brief description of the elements identified on this device in Table 1. For a full functional description of any of these modules, see the device-specific technical reference manual.

6.1 Power Supply

The Hercules device family products require an external device to supply the necessary voltages and currents for proper operation. Separate voltage rails are available for core logic and I/O logic (including multi-buffered analog-to-digital converter (MibADC), Flash pump and oscillator).
The following tests can be applied as diagnostics for this module (to provide diagnostic coverage on a specific function):
• Internal Voltage Monitor (VMON)
• External Voltage Supervisor
• MibADC Converter Calibration
• External Watchdog
6.1.1 Notes
• Management of voltage supervision at system level can be simplified by using a TI TPS6538x power
supply and safety companion device developed for use with the Hercules family.
• Devices can be implemented with multiple power rails that are intended to be ganged together on the
system PCB. For proper operation of power diagnostics, it is recommended to implement one voltage supervisor per ganged rail.
• Common mode failure analysis of the external voltage supervisor may be useful to determine
dependencies in the voltage generation and supervision circuitry
www.ti.com

6.2 Power Management Module (PMM)

The power management module (PMM) is responsible for control of switchable power domains. Dependent on the family variant used, one or more power domains can be implemented. Power domains can be permanently configured at manufacturing time by TI or they can be user programmable. To determine the power domains supported on your MCU, see the device-specific data sheet. For programming information, see the device-specific technical reference manual.
The following tests can be applied as diagnostics for this module (to provide diagnostic coverage on a specific function):
• Internal Voltage Monitor (VMON)
• External Voltage Supervisor
• Lockstep PSCON
• Power Domain Inactivity Monitor
• Privileged Mode Access and Multi-Bit Keys for Control Registers
• Periodic Software Readback of Static Configuration Registers
• Software Readback of Written Configuration The following tests can be applied as a test-for-diagnostic on this module, and could be used to meet
Latent Fault Metric Requirements of ISO26262 (in combination with other diagnostics on the primary function):
• PSCON Lockstep Comparator Self Test
• Internal Watchdog
• External Watchdog
• CPU Lockstep Compare
• Flash Data ECC
• SRAM Data ECC
26
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
6.2.1 Notes
• PSCONs continue to function normally during lockstep compare self-test, but no comparison function is
present.
• When the CPU is in a halting debug state, no comparison of PSCON outputs is performed.

6.3 Clocks

The Hercules device family products are primarily synchronous logic devices and as such require clock signals for proper operation. The clock management logic includes clock sources, clock generation logic including clock multiplication by phase lock loops (PLLs), clock dividers, and clock distribution logic. The registers that are used to program the clock management logic are located in the system control module.
The following tests can be applied as diagnostics for this module (to provide diagnostic coverage on a specific function):
• LPOCLKDET
• PLL Slip Detector
• Dual Clock Comparator (DCC)
• External Monitoring via ECLK
• Internal Watchdog - DWD
• Internal Watchdog - DWWD
• External Watchdog
• Periodic Software Readback of Static Configuration Registers
• Software Readback of Written Configuration The following tests can be applied as test-for-diagnostics on this module to meet Latent Fault Metric
Requirements of ISO26262 (in combination with other diagnostics on the primary function):
• Software Test of DCC Functionality
• Software Test of DWD Functionality
• Software Test of DWWD Functionality
• CPU Lockstep Compare
• Flash Data ECC
• SRAM Data ECC
Brief Description of Elements
6.3.1 Notes
• Management of the external watchdog functionality at system level can be simplified by using a TI
TPS6538x power supply and safety companion device developed for use with the Hercules family.
• User can improve the accuracy of the LPOCLKDET diagnostic via programming the trim values in the
HF LPO. This would require the customer to determine the LPO trim value during their manufacturing test via comparison to a calibrated clock source.
• There are many possible implementations of watchdogs for use in providing clock and CPU
diagnostics. In general, TI advises the use of an external watchdog over an internal watchdog for reasons of reduced common mode failure. TI also advises the use of a program sequence, windowed, or question and answer watchdog as opposed to a single threshold watchdog due to the additional failure modes that can be detected by a more advanced watchdog.
• Driving a high-frequency clock output on the ECLK pin may have EMI implications.

6.4 Reset

The Hercules device family products require an external reset at cold and power-on (nPORRST) to place all asynchronous and synchronous logic into a known state. The power-on reset generates an internal warm reset (nRST) signal to reset the majority of digital logic as part of the boot process. The nRST signal is provided at device level as an I/O pin; it will toggle when asserted internally and can be driven externally to generate a warm reset. For more information on the reset functionality, see the device-specific data sheet.
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
27
Brief Description of Elements
The following tests can be applied as diagnostics for this module (to provide diagnostic coverage on a specific function):
• External Monitoring of Warm Reset (nRST)
• Software Check of Cause of Last Reset
• Software Warm Reset Generation
• Glitch Filtering on Reset Pins
• Use of Status Shadow Registers
• Periodic Software Readback of Static Configuration Registers
• Software Readback of Written Configuration
• Software Test for Reset
• External Watchdog The following tests can be applied as a test-for-diagnostic on this module, and could be used to meet
Latent Fault Metric Requirements of ISO26262 (In combination with other diagnostics on the primary function)
• Internal Watchdog
• CPU Lockstep Compare
• Flash Data ECC
• SRAM Data ECC
6.4.1 Notes
• Management of reset at system level can be simplified by using a TI TPS6538x power supply and
safety companion device developed for use with the Hercules family.
• Internal watchdogs are not a viable option for reset diagnostics as the monitored reset signals interact
with the internal watchdogs.
www.ti.com

6.5 System Control Module

The system control module contains the memory-mapped registers to interface clock, reset, and other system related control and status logic. The system control module is also responsible for generating the synchronization of system resets and delivering the warm system reset nRST.
The following tests can be applied as diagnostics for this module (to provide diagnostic coverage on a specific function):
• Privileged Mode Access and Multi-Bit Enable Keys for Control Registers
• Software Readback of Written Configuration
• Periodic Software Readback of Static Configuration Registers
• Multi-Bit Keyed Self-Correctable High-Integrity Bits The following tests can be applied as test-for-diagnostics on this module to meet Latent Fault Metric
Requirements of ISO26262 (in combination with other diagnostics on the primary function):
• Internal Watchdog
• External Watchdog
• CPU Lockstep Compare
• Flash Data ECC
• SRAM Data ECC
6.5.1 Notes
• Depending on targeted metrics, a user can elect to implement a periodic software test of static
configuration registers in the system control module. Such a test can provide additional diagnostic coverage for disruption by soft error.
• Review the clock and reset sections as these features are closely controlled by the system control
28
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
www.ti.com
module.

6.6 Error Signaling Module (ESM)

The ESM provides unified aggregation and prioritization of on-board hardware diagnostic errors. For more information, see Management of Errors.
The following tests can be applied as diagnostics for this module (to provide diagnostic coverage on a specific function):
• Periodic Software Readback of Static Configuration Registers
• Boot Time Software Test of Error Path Reporting
• Periodic Software Test of Error Path Reporting
• Use of Status Shadow Registers
• Software Readback of Written Configuration The following tests can be applied as test-for-diagnostics on this module to meet Latent Fault Metric
Requirements of ISO26262 (in combination with other diagnostics on the primary function):
• Internal Watchdog
• External Watchdog
• CPU Lockstep Compare
• Flash Data ECC
• SRAM Data ECC
Brief Description of Elements
6.6.1 Notes
• Software testing of the ESM error path can be combined with boot time latent tests of hardware
diagnostics to reduce startup time.
• Testing of ESM error path may result in assertion of the nERROR diagnostic output. System integrator
should ensure that the system can manage or recover gracefully from the nERROR event.

6.7 CPU Subsystem

The Hercules product family relies on the ARM®Cortex-R5F CPU to provide general-purpose processing. The Cortex-R5F is a high performance CPU with embedded safety diagnostics. The R5F is also designed for easy integration into a 1oo1D lockstep configuration. These aspects make the Cortex-R5F an outstanding CPU for functional safety products.
The following tests can be applied as diagnostics for this module (to provide diagnostic coverage on a specific function):
• CPU Lockstep Compare
• Boot Time Execution of LBIST STC
• Periodic Execution of LBIST STC
• Memory Protection Unit (MPU)
• Online Profiling Using PMU
• Illegal Operation and Instruction Trapping
• Periodic Software Readback of Static Configuration Registers
• Software Read Back of CPU Registers
• Boot Time PBIST Check of CPU cache Memories
• Periodic Time PBIST Check of CPU cache Memories
• ECC on Cache Memories
• Hardware Disable of JTAG Port
• Internal Watchdog
• External Watchdog
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Safety Manual for RM57x Hercules ARM Safety MCUs
29
CPU Bus Compare
PD Inactivity
Monitor
VIM Bus Compare
Checker CPU
Inactivity Monitor
CPU1
(Main CPU)
CPU2
(Checker
CPU)
2 cycle delay
VIM1 VIM2
2 cycle delay
Inputs to CPU1
cpu2clk
cpu1clk
Outputs from CPU1 to
the system
Outputs from CPU2 to
the system
Safe values (values
that will force the
ZlŒWh[•}µš‰µš•
to inactive states)
CCM-R5F
Compare errors
ESM
PDx PDy
Brief Description of Elements
The following tests can be applied as a test-for-diagnostic on this module, and could be used to meet Latent Fault Metric Requirements of ISO26262 (in combination with other diagnostics on the primary function):
• Lockstep Compare Self-Test
• LBIST Auto-Coverage
• Software Test of PBIST
• PBIST Auto-Coverage
• Software Readback of Written Configuration (PBIST)
• Flash Data ECC
• Data ECC
6.7.1 Measures to Mitigate Common Mode Failure in CPU Subsystem
The Hercules lockstep CPU subsystem design includes multiple best practices to mitigate common mode failure:
• Physical diversity:
– Physical core hard macros are spaced at least 100 µm apart. – Each CPU is uniquely diversified in terms of the cell placements .
• Temporal diversity:
– Timing delay blocks are inserted to delay the operation of the CPUs by two cycles as shown in
Figure 7.
www.ti.com
Figure 7. Lockstep Temporal Diversity
30
Safety Manual for RM57x Hercules ARM Safety MCUs
SPNU575A–May 2014–Revised September 2016
Submit Documentation Feedback
Loading...
+ 110 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use