5.1 Make it Safe! SafeTI(TM) Design Packages

[MUSIC PLAYING] Hi. I'm Anthony Vaughan with the Texas Instruments product marketing team for Hercules Safety Microcontrollers. Today I'm going to give you an in-depth look at TI's SafeTI design packages for functional safety. TI has created a great web resource around SafeTI, so I encourage you to visit our website at ti.com/safeti.
As part of this video, we will cover many functional safety topics and details about SafeTI. We will start out by taking a look at a few safety critical applications that can take advantage of SafeTI. Then we will take a brief look at functional safety before going into SafeTI. After that, we will cover safety certification and documentation provided for products that are part of SafeTI. Next, we will talk about software, design packages, and development kits that are available.
The last portion of this video will feature a hands-on lab that you can follow along with. In this lab, we will observe the behavior as we force an MCU clock monitor fault on a Hercules safety MCU USB development stick. If you'd like to complete the lab, you will need a Hercules TMS570LS31 USB development stick, a 1K ohm pull-down resistor, Code Composer Studio 5.3, and HALCoGen version 3. You can get more information about the hardware and software used in this lab from the tools and software section on the website, ti.com/hercules.
I would like to start by identifying many of the industries that require functional safety. These include automotive, aerospace, railway, industrial, and medical. Some specific automotive applications that require a high level of functional safety include braking, or electronic stability control, airbag, hybrid and electric vehicles, advanced driver assistance systems, active suspension, electric power steering, and chassis domain control.
Aerospace/avionics, autopilot, flight control, anti-skid control, and communication gateways all require functional safety. In addition, locomotive communication gateways, signaling systems, and the traction drive motors also require safety. Some applications in the industrial space, including motor control, manufacturing, robotics, industrial automation, programmable logic controllers, sensor and communication gateways, as well as wind and solar power products. There are also many critical care medical devices that require a high level of safety, including infusion pumps, oxygen concentrators, respirators, and anesthesia machines.
TI has been supplying semiconductor components into many of these industries for a number of years. TI's microcontrollers have been going into automotive airbag and anti-lock braking systems for over 20 years. Since there are so many industries that require functional safety, there are a number of international safety standards that have been created. One of the most widely known standard is IEC 61508. This is a general functional safety standard that can be used across many industries. Many of the other functional safety standards that apply to specific industries will reference sections in the IEC 61508 standard. Another very important safety standard is the ISO 26262 standard for the automotive industry.
One concept that's common across many of the functional safety standards is that all systems will have a quantifiable failure rate. It is impossible to build and deploy a system that will have an absolute zero failure rate. Another fundamental concept is that for every system, there is a tolerable failure rate. This failure rate will vary by application and is directly related to the level of injury to people or the environment that would be caused in the event of a system malfunction.
Because the level of damage that can be done by a system will vary by application, most functional safety standards defined categories called safety integrity levels, or SILs. For example, the level of harm that an automatic power window system in an automobile can cause in the event of a malfunction is far less than the level of harm that a malfunction of the air bag system could cause. Because of this, the power windows system would be classified at a lower safety integrity level than the airbag system.
The number of safety integrity levels and the naming convention for these levels will vary from standard to standard. For example, the DO-254 standard used by the aircraft industry defines five different design assurance levels, where design level A requires the highest level of safety, and level E requires the least. The IEC 61508 standard defines four levels, where SIL one requires the least amount of safety, and level four requires the most.
To understand why functional safety standards dictate numerous system aspects, it helps to understand the types of failures to which semiconductor electronics are susceptible. In general, failures can be classified into two main categories-- systematic and random. Systematic failures generally result from problems with the chip design, software bugs, or the manufacturing process. Systematic failures can usually be mitigated by a continuous process improvement. A fairly straightforward example of a systematic failure in electronic system is a suboptimal solder reflow profile used in printed circuit board assembly, resulting in circuit continuity failures.
Random failures may be more difficult to fathom since these failures usually result from random defects or events that are inherent to a process usage condition or the operating environment. An example of a random failure in an electronic system is an embedded processor malfunction caused by an alpha or a neutron particle bombarding a RAM bit, causing it to flip state. In daily life, a rock hitting and breaking the windshield of a vehicle is a prime example of a random failure.
The rate of random failures cannot generally be reduced, but risk mitigation measures can be taken to detect and respond to these assaults appropriately when they do occur. Detecting and taking appropriate action when a random failure occurs is one of the core focuses of Hercules safety MCUs and a number of the other semiconductor products that are included in the SafeTI portfolio.
One common misconception is that if a system is highly reliable, it is also functionally safe. While most functionally safe systems need to be reliable, this is not enough to guarantee that it will be safe. Usually high quality and reliability will go a long way to reduce the number of systematic failures. These measures usually do very little to mitigate random failures. The fundamental way a quality or a reliability engineer approaches a problem is different than the way a functional safety engineer would approach a problem.
For example, when faced with a potential system over-temperature fault that causes wiring to melt resulting in a system failure, a reliability engineer would probably approach the problem by designing the system with high temperature wiring, while a functional safety engineer would most likely approach the problem by designing the system to detect the over-temperature condition and place the system into a safe state before the wiring could melt.
Another common misconception is that safety and security are the same thing. The fundamental concept of safety deals with avoiding external system manipulation that could cause a failure. A secure system is capable of resisting or preventing tampering from the outside world, while a functionally safe system is capable of detecting faults and prevents the system from causing harm to the outside world. Safety should be a concern when a system is developed, but is a concept that is totally different than safety.
SafeTI design packages combine a number of embedded processing and analog semiconductor components in TI's portfolio to give developers [INAUDIBLE] to use when creating functionally safe systems. Products in the SafeTI portfolio provide developers standards specific bundles for their safety products. SafeTI provides products from the embedded processing portfolio and combines them with analog products specifically designed to work together in a safety system. When you see devices that are in SafeTI approved, you get components that are produced from a quality manufacturing process-- like TS 16949-- and follow a dedicated safety development process.
SafeTI devices were designed from the beginning to have functional safety enabled hardware to support standards based safety integrity levels. Where applicable, SafeTI devices come with optimized software libraries and tools. SafeTI documentation is provided for each product. This includes a safety manual that details the product's safety architecture and recommended usage. It also includes a safety analysis report with a detailed FMEDA so that you can tailor your analysis for your specific use case. Additionally, SafeTI products come with safety reports to show compliance to targeted standards.
SafeTI design packages are available for four areas. SafeTI 61508 demonstrates compliance to the IEC 61508 functional safety standard and supports SIL 1 through SIL 3 for end equipment in areas such as industrial, medical, railway, and others. SafeTI 26262 satisfies component level compliance to ISO 26262 from ASIL-A to ACIL-D for the passenger vehicle market. SafeTI 6730 ensures component level compliance to IEC 6730 from Class A to Class C for household appliances.
And finally, TI offers SafeTI QM products. Not all and equipment safety standards require that every component be developed for functional safety. In those cases, SafeTI QM products could be considered. SafeTI QM products are developed under a rigorous quality managed process and come with a safety manual and safety analysis report to help in safety system analysis.
Our goal with SafeTI is to provide TI customers with a complete safety package that includes both analog and embedded processing solutions. We want to help developers meet their safety requirements to make their system certification faster and easier.
I am now going to go over some of the key architectural features in TI's Hercules ARM Cortex-R4F based safety MCUs that make them well-suited for use and functional safety systems. These microcontrollers employ a safety concept known as the safe island strategy. This concept is based on continually operating hardware safety mechanisms, monitoring the CPU, flash memory, SRAM, power, and clocks in order to support functionally correct software execution.
One key aspect of the safe island concept is the dual core lockstep ARM Cortex-R4 CPU architecture. This architecture provides a high level of diagnostic coverage implemented in hardware so that developers do not have to write complex software-based checking algorithms. With this approach, a checker core is wired to take the same input as the functional core. A compare module compares the outputs of the two cores on a cycle by cycle basis and signals any miscompare.
To address the possibility of common mode failure, several design strategies are implemented. Temporal diversity of the cores is induced so that the cores operate two cycles out-of-phase. Physical design diversity is implemented by flipping and rotating of the checker CPU with respect to the functional CPU. Guard rings also provide an additional layer of physical separation between the primary and checker core.
As effective as a lockstep CPU implementation can be, it cannot detect a failure until the CPU is in use. The Hercules architecture employs a logic built-in self-test controller, or LBIST STC diagnostic, which provides high diagnostic coverage on the CPU at a transistor level. The LBIST test engine uses the same design for test, or DFT, structures that are used to test the microcontroller during the manufacturing process. LBSIT testing requires far less execution time than a comparable software-based diagnostic approach and reduces the memory overhead to store software diagnostics.
The Hercules LBIST allows the hardware test to be executed all together during startup or in periodic time slices during normal operation. This feature can be very useful in applications that have very long on times. For example, some industrial control products will run for several months at a time without a power cycle and will periodically run an LBSIST test sequence on the CPUs during the application.
Similar to the LBIST, the Hercules architecture also incorporates a built in self-test controller for all SRAMs. The programmable SRAM BIST, or PBIST, is highly configurable and incorporates many test algorithms that can provide a high level of diagnostic coverage. Like LBIST, it can be run at startup or periodically during the application.
The integrity of both the flash memory and SRAM contents of Hercules MCUs is protected by error correcting code, or ECC technology. ECC encodes data in a way that enables detection of corruption and also allows correction of single bit errors so that system operation can continue uninterrupted. In the unlikely event of two-bit errors occurring in the same block of memory, a failure event is triggered to alert the system that memory has been corrupted.
In many microcontroller architectures, the ECC controller is integrated into the memory block. However, the Hercules Cortex-R4 based architecture integrates the ECC controller directly in the ARM Cortex-R4 CPU. This provides two primary advantages. The first is performance. Since the ECC controller is integrated into the CPU, it can check the integrity of the data quickly without the need to reduce CPU frequency or with the addition of wait states. The second advantage is that bit errors that can occur in the CPU to memory interconnect buses can also be detected. Because of the tight coupling of the ECC controller logic and the CPU, there is virtually no processor overhead incurred for the safety mechanism.
In addition, the ECC logic in the CPU is checked by both the lock step and the LBIST CPU safety mechanisms. Hardware safety mechanisms are also allocated to peripherals for the management of random faults that are not easily captured by software. Examples include parity on peripheral SRAMs, I/O loopback capabilities to check the input-output pass from peripherals to pins, PBIST to peripheral memories, memory protection units on bus master peripherals, and limitation of control of critical configuration registers based on CPU privilege levels.
Beyond the safety architecture provided by Hercules MCUs, a large part of SafeTI design packages is the safety documentation that's available. One document is the device safety manual. It provides details about the safety features in the device and gives users TI's recommendation on how and when to use these features. Other documents available under non-disclosure agreement, or NDA, include the safety analysis report summary and the safety analysis report. These documents provide information about failure modes and failure and time rates, or fit rates, for the device. The final document is the safety case report that provides details about compliance to the applicable safety standards.
The SafeTI development process has also been certified by TUV SUD, an internationally recognized and accredited assessor of quality, safety, and security standards. The development process for both SafeTI 61508 and SafeTI 26262 have been certified. This demonstrates TI's commitment to developing semiconductors that are compliant to IEC 61508 and ISO 26262.
Here's an example of a SafeTI design package. This example pairs a Hercules Safety MCU with the TPS65381 Safety Companion Power Management IC, or PMIC. These two devices have been designed from the ground up to work together in a safety critical application. The TPS65381 is capable of providing the core and I/O voltages for the Hercules MCUs. This device also has many integrated hardware safety features, like LBIST to test the IC's digital logic, ABIST, for the analog circuitry, an oscillator monitor, and an over-temperature monitor.
It also implements a question-answer type watchdog that can be used in conjunction with the Hercules MCU via the SPI port. The TPS device can also monitor the error output pin on the Hercules MCU. And in the event of a highly critical error in the microcontroller, it can assert a power on reset or even power down the MCU. More information about the TPS65381 is available from the web page link shown at the bottom of this screen. Other examples of safety design packages can be found at ti.com/safeti.
In summary, safety designers can count on SafeTI. TI's 20-plus years of designing solutions for the safety market enables us to provide safety developers embedded processors and analog solutions that work together, functional safety integrated into hardware, tools and software prepared for safety, and comprehensive safety documentation. All of these components enable faster and easier safety certification for our customers.
Now it's time for the hands-on lab portion of this video. In this exercise, I will demonstrate the integrated clock monitor functional safety feature on a Hercules MCU. As part of this exercise, we will use HALCoGen, a tool that generates startup and peripheral driver code for Hercules MCUs to create a program that uses the microcontrollers real time interrupt, or RTI, module to blink an LED on the board.
Then we will configure the error signaling module to respond to a clock monitor error. We will then take the code that HALCoGen generates for us and import it into Code Composer Studio where we were write a little code to finish the device configuration. Then we will build up our code and deploy it to the MCU. Finally, we will disrupt the external crystal on the MCU and observe the response.
To complete this lab, you'll need a Windows-based PC, a Hercules development kit or a Hercules USB stick, and a pull down resistor. You will also need HALCoGen and Code Composer Studio. If you need a Hercules MCU USB development stick, you can order one from the first website shown below. If you need HALCoGen, you may download it for free from the second link.
To start the HALCoGen application, go to the Windows or Start menu and select Programs, Texas Instruments, Hercules, HALCoGen. To start a new HALCoGen project, select File, New Project. Once the new project window has opened, the device family and specific device information must be entered. Then the name of the project can be entered along with the location for all of the generated code to be stored.
I will not walk you through this lab. The first step is to create a new HALCoGen project project by selecting File, New, Project. Then select the family, TMS570LS31X. Then choose the TMDX570LS31 USB in the device field. Then type ESM into the name field to define a project name. I will leave the Tools area set to the default of Texas Instruments tools since we will be using TI's Code Composer Studio. However, this field can be set to ARM tools, IAR tools, or Green Hills tools in order to generate code specifically for those tool sets.
After the HALCoGen project is configured, we need to navigate to the Driver Enable tab and select the RTI and GIO drivers. These drivers will be used to blink our LED. Then we will need to go to the Vim channel 0 through 31 tab. In this tab, we need to enable Vim channel 2 and map it as an FIQ. This will enable the interrupt of our real time interrupt compare zero channel. Then we will go to the RTI tab and select the RTI one compare sub-tab. In this section, we will enter a value of 1,000 milliseconds into the compare zero period. This will configure the RTI to generate an interrupt once every 1,000 milliseconds, or once every second.
The next step is to configure the error signaling module. To do this, go to the ESM tab and select the ESM channel 0 through 31 sub-tab. Then enable channel 11, which is the clock monitor channel. The final configuration is in the clock source tab. In this tab, ensure that the LPO high frequency is set to 10 megahertz. The last step in HALCoGen is to generate code by selecting File, Generate Code.
I will now walk you through the procedure of importing this project into Code Composer Studio. To launch Code Composer Studio, go to Start, Texas Instruments, Code Composer Studio v5, Code Composer Studio v5. As CCs starts, it will ask you to enter a workspace. Make sure you specify the same directory that was specified when creating the HALCoGen project. Then we will need to create a new CCs project.
In Code Composer Studio, select File, New, CCS project. In the new project window, we type in the name of our project, which is ESM. This name needs to match the name that we created in HALCoGen. Next, we select the family, ARM, variant, Cortex-R, then TMS570LS3137 and a connection type of Texas Instruments XDS100v2 USB emulator. In the Project Templates and Examples, select the empty project option, then click Finish.
Next, right click on the project name in the Project Explorer and choose Properties. We now need to include the header file directory into our project. To do this, select the Build, ARM Compiler, Include Options. Then click on the green Add button. Then click on the Workspace button in the Add Directory path window. In the folder selection window, we need to select the folder name to include. Then click OK.
The next step is to expand our project source folder in the Project Explorer then find the file named sys_main.c and double click on it. This will open the file that contains our main function in an editor window. Then we find the comments labeled, user code begin 0 in this file. One important thing to note is that we will always put our code in between these user code begin and user code end comments. This will enable us to take a project and reconfigure it with HALCoGen. HALCoGen will never modify any code that is placed between these user code comments.
In the user code begin zero section, we're going to add three header files. We will include rti.h, het.h, and esm.h. The next step is to scroll down to the main function in the file and locate the user code begin three section. Then we call the function to initialize the real time interrupt, or RTI, module in our MCU. Then we call the error signaling module, or ESM, initialization function. The next step is to set the high end timer or head port pins as outputs. Then when enable our RTI compare zero interrupt and enable our FIQ.
The final step is to start the RTI counter, and then enter an endless loop with a while one statement. The next step is to open up the notification.c file. Then scroll down to the RTI notification function. Next, delete the while one statement then insert code that will toggle the state of our high end timer LED every time we receive an RTI interrupt. That is all the code that we need to enter into Code Composer.
The next step is to compile and load our project into the microcontroller. To do this, go to Run and select Debug. This will compile, link, and program our application into the device's flash memory. After the device has been programmed, we can start executing our application by pressing the power on reset button on the MCU. We can see the high end timer LED blinking on the board now that our application is running.
The next step is to disrupt the external crystal on the backside of the USB stick. I will do this with a wire and a 1 kiloohm resistor. As we do this, pay attention to the red error LED and the speed at which the white high end timer LED toggles. We will see that the MCU's ESM detects the clock monitor fault and reports it via the read error LED and that the frequency of the high end timer LED slows considerably since the application is now being driven from the slower 10 megahertz internal low power oscillator.
That completes the lab portion of this video. If you would like more information about SafeTI design packages for functional safety, please visit the website ti.com/safeti. If you are interested in more instructional videos for Hercules Safety Microcontrollers, go to ti.com/herculestraining. I hope that you have found this video useful. Thank you for watching.