Safety Microcontrollers: TI Hercules vs Infineon AURIX
Updated: Jul 3, 2019
We have a project which potentially requires the use of a 'Safety Microcontroller'. These are microprocessor devices with integrated program and data memories like any other MCU, with the exception that they also incorporate die-level hardware diagnostic functionality. Basically, they can tell you when they ‘think’ they are 'lying' to you. Whilst this feature doesn’t immediately render the system inherently safe, it does enable the system hardware to take reversionary action if the microprocessor misbehaves. In its most basic form, a system built around a Safety Microcontroller can be made to fail-safe by using the diagnostic output signal to drive the hardware into a predefined safe system state. If similar safety processor instances are combined, then more sophisticated fail-operational architectures can be built, as described in this article. If software-based processes are unavoidable in a hi-reliability application, then Safety MCUs could be the way to go.
There are several candidates on the marketplace currently, however two families stand out from the crown – the TMS570 Hercules range produced by Texas Instruments, and Infineon’s Aurix microcontrollers. I have had some exposure to the Hercules parts already in my career, however, the AURIX devices were new to me, hence I decided to evaluate both. I procured some low-cost development boards for both types in order to see what’s involved in getting a project up and running for each. I haven’t published a parametric comparison of the two parts. This is an easy thing for most people to do by comparing datasheets. Instead I’m more interested in the less tangible, qualitative things. For example, how intuitive the tool-chains are to use, and what levels of support exist when you get stuck. Once you commit to a device selection, you must live with the consequences, so it pays to give these things some thought. Device cost, physical size and availability were also a factor, so I spent a while checking through the manufacturer and distributer websites to confirm the specific part numbers I would end up purchasing for my project. I should stress that I have no affiliation with either of these suppliers.
Whilst the Hercules and AURIX employ different internal architectures, the fundamental safety-critical ‘building blocks’ are quite similar in both types. For example, they both employ ‘1oo1D’ lock-step processor cores. Each processor core is actually two cores coupled with some supervisory circuitry, as shown below:
The diagnostic function is achieved by having two processing cores inside the same integrated circuit – a primary core and a checker core. Both execute the same code simultaneously, by clocking both in lock-step. Dedicated compare hardware inside the device continually checks the registers in both cores for parity offering near instantaneous fault detection. If the two cores disagree, the compare module sets the error pin on the device, which would be used to drive the system into a predefined safe state, by shutting something dangerous down, for example.
To mitigate the effects of common mode failures in the primary and checker CPU cores, temporal diversity is employed (i.e. running the two cores 1.5 or 2 clock cycles out of phase). Physical diversity is also employed by flipping and rotating the checker core with respect to the primary core on the die. TI claim that “the net result is a system that has no documented or reported cases of common mode failure to date”.
Texas Instruments Hercules
The ‘Hercules’ microprocessor range comprises both RM4x and TMS570 families of devices. The two families appear to be fundamentally very similar with dual ARM Cortex-R4 floating-point CPU cores operating in lockstep, up 3 MB of flash memory and up to 256 KB RAM. Both have been designed to permit safety system certification to SIL 3, per IEC 61508. The RM4x family is targeted at industrial automation and medical instrumentation, whilst the TMS570 is targeted at automotive applications, and hence is also AEC-Q100 qualified. From a performance and cost point of view, there is not much between them, with the exception that the TMS570 has a wider operating temperature range of -40°C to +125°C, vs -40°C to +105°C for the RM4x family. The ARM cortex R4 processor core employs an ARMv7-R Harvard architecture optimised for real-time operation, giving 1.67 DMIPS/MHz. The RM4x can be clocked up to 220 MHz (367.4 DMIPS maximum) and the TMS570 can be clocked to 180 MHz (300.6 DMIPS maximum).
Hercules employs what TI call a “safe island” architecture concept. The processor elements within the boundary of the “safe island” are allocated continuously operating safety mechanisms as part of the chip’s BIST (Built-In Self-Test). The “safe island” includes circuitry to monitor and detect faults in power supplies, clock frequency drift, and flash and RAM checking functions using an ECC controller (Error Correcting Code). The idea is that the “safe island” ensures fault detection coverage for core processing functions, allowing trusted code running within the “safe island” to extend the diagnostic coverage to other system functions such as peripherals and external devices. This level of diagnostic coverage is required to be compliant with safety standards, such as IEC 61508. Upon detection of a fault, the device signals the event by asserting a signal on an ‘Error’ pin.
A low-cost ‘Launchpad’ evaluation board was procured from RS Components. This has a TMS570LS04 device fitted. This wasn’t the exactly the required device, but it was good enough to get a feel for using the Hercules family. It is amazing how cheap these little boards are (£18.60 + VAT).
Infineon have produced a very successful range of safety microcontrollers called ‘AURIX’, an acronym for “AUtomotive Realtime Integrated neXt generation architecture”. This product line was clearly developed for high-reliability automotive applications, such as ECUs and follows on from their older AUDO range. In terms of low-cost micros, AURIX is a heavyweight. It combines up to three independent 200 MHz 32-bit processors in a single package, two of which are themselves dual-core lockstep processors. Infineon call this their “TriCore” architecture. From a safety, or high-reliability architecture perspective, this means that it should be possible to build 2oo2D, or 2oo3 (Triplex) systems in a single IC. Not bad for a $20 chip.
After a phone call with the development card company HITEX, I was encouraged to evaluate the HITEX ShieldBuddy development board, which hosts a ‘TC275’ version of the device – This is at the larger end of the product line. Specifically, the part used on this card is the TC275TP-64F200NDC. In addition to the Tri-core processor, it also contains 4MB of flash, 472kB RAM and comes in a monstrous 176-pin LQFP package. For the adventurous, you can buy the chips in a smaller BGA package which may be more realistic for space constrained applications. In the UK, the basic TC275’ chip is available for purchase through Arrow at £15.22 for 100 off, or £19.52 for 1off quantities.
AURIX also supports some impressive connectivity, including Ethernet, Flexray and CAN-FD. CAN-FD is emerging as a successor to the CAN bus standard, specifically responding to the data-rate limitations of CAN. Clearly 1 Mbit/s is considered a bit pedestrian by today’s standards. Not many microcontrollers are offering integrated CAN-FD controllers yet, so this feature does set AURIX apart.
Toolchains - AURIX
Regarding toolchains, there are free-to-use toolchains available for the AURIX. The focus for this appears to be based around a configuration of the Eclipse IDE produced by HIGHTEC, and bundled with a target locked version of their compiler. However, this cannot be used for commercial development. For this you will need the “full version of the Tri-core development platform”. This is a GCC compiler which is distributed in the UK for £3,250 + VAT. Alternatively, there is a version of Tasking-VX compiler (produced by Altium) for the Infineon Tri-Core. This costs €5,635 for a perpetual license. If you want to run an RTOS, both HIGHTEC and ETAS can oblige at £6,000 + VAT and €8,408 respectively. So, if you are serious, AURIX gets expensive quickly. Clearly this is of no concern if you are a Tier 1 automotive supplier, but for independent developers or SMEs, the capital expenditure required in incorporating AURIX into your designs may become prohibitive.
In addition to the production toolchains described above, HITEX have produced a plugin for the popular and free Arduino IDE, which allows you to develop code in the Arduino ‘Processing’ language specifically for the AURIX Shieldbuddy board. Once you set this up, the AURIX card can be used like an Arduino, except you can create routines which execute in parallel on each of its three cores. It works very well and is quite good fun to play with.
The Arduino ecosystem was conceived for the ‘maker’ and student community as a gentle introduction to embedded software. Hence it is deliberately unsophisticated and offers no real debugging capability. It is never going to be practical to develop a serious industrial product with Arduino. For this reason, this seems to be a commercial back-water for HITEX and Infineon. It is unclear why they have done this. Perhaps there could be a niche market for Arduino users looking for a performance upgrade- AURIX offers a huge jump with 460 DMIPS per core, (1380 DMIPS total for the tricore versions), whereas a standard 8-bit Arduino tops-out at 5.2 DMIPS.
If the limitations of the Arduino IDE become prohibitive, HITEX have a debugger plugin for the Eclipse IDE as part of their free toolchain (Eclipse PLS UDE) which allows ‘sketches’ (not programs) written in the Arduino (‘processing’) language to be debugged and loaded into the ShieldBuddy card via the eclipse framework. This appears to provide a comprehensive set of debugging capabilities which are not present in the pure Arduino implementation. Whilst this may sound attractive, I spent three evenings trying to make this work but couldn’t change the build configuration away from the default example. There weer also some compilation errors in the Arduino sketches. Ultimately, I ran out of time with it and moved on to other things. Eclipse is recognised as not being an intuitive IDE to use, so how is the average Arduino user going to get on with this? Probably not very well.
For the serious developer, HIGHTEC (not to be confused with HITEX) have produced another development tool for AURIX, again based on the eclipse framework. This allows a development, debugging and a programming capability for the AURIX hardware using the ‘C’ or ‘C++’ language. Again, some difficulties were encountered in getting the code examples to build correctly. Ultimately, some errors were identified in the HIGHTEC board support package for the ShieldBuddy board. After these errors were rectified, it built properly. All the examples for this board only cover single core operation, so it isn't clear how to produce multicore applications. It seems that this software package is too 'unfinished' to warrant the £3,250 + VAT price tag.
With that, the AURIX ‘Tasking-VX’ toolset was evaluated, produced by Altium (of Altium Designer fame). Tasking VX is also built on the eclipse framework. Some code examples were brought up and running on the AURIX through Tasking-VX very easily. Tasking-VX is a pleasure to use in comparison with the HIGHTEC offering. Altium have clearly put some time into setting up this toolchain. The examples worked, and there is a helpful user-guide for Tricore built into the tool. We obtained an evaluation license for the software from Altium, who were very attentive. Tasking isn’t cheap, but if you want to develop serious production code for the AURIX, this seems like the tool to use.
The tool that is missing from the AURIX line-up is a decent code configurator. This is a PC application which allows you to develop the hardware abstraction layers and low-level libraries by configuring your operational requirements in a user-friendly environment. Infineon do have a software tool called DAVE™. Unfortunately, DAVE™ does not support AURIX. This means that you are relying on any bundled low-level libraries you can get your hands on, or you will need to write your own.
Toolchains – Hercules
The primary out-of-the-box software tool for developing code on the TMS570 is TI’s Code Composer Studio (CCS). Like the free Infineon toolchain, this employs the eclipse IDE framework, but it is quite apparent that the overall workflow has been given much more thought by TI. More specifically, it works. Very well in fact. Also, you can use the free license all the way through to production standard kit. This was a savvy move from TI and is likely to draw in a lot of new business from cash-strapped start-ups.
TI also have a free proprietary code configurator called HALCoGen (HAL Code Generator), which you can use to configure and generate the basic start-up code for your MCU. Through a Graphical User Interface (GUI), you can configure IO ports, PWM peripherals, timers, interrupts and ADCs, etc. If you are starting from scratch, HALCoGen can generate the low level source code to initialise the MCU. You can then get on with adding your own application code without worrying too much about configuring device peripheral registers. After some familiarisation with HALCoGen and CCS, you can quickly set up your application and build a basic ‘Blinky’ application for the Launchpad card. It’s quite easy to learn the basic processes of configuring the device, entering your code, building and debugging with the CCS tool.
A note about technical support
There is very little online content available about the AURIX. If you want to pick up an AURIX and put it into your design, Infineon don’t exactly make that process easy for you. Perhaps deliberately. It feels like Infineon are reluctant for you to you to use the AURIX unless you are a Tier 1 automotive supplier (which is who they designed it for). Perhaps this is an unfair conclusion, but it’s easy to get the impression that you’re going to have a tough time unless you sign up for a training programme. All of the detailed design information for the AURIX such as datasheets and application notes are closed source. You must request them specifically from Infineon by emailing them. When you try to discuss AURIX on the Infineon live online chat, you are politely encouraged to email a specific mailbox instead. Apparently, this device cannot be discussed on their chatline. My email was actioned by Infineon after about four days of waiting around. But once you do get access permissions to their online document vault, your patience is duly rewarded with plenty of good documentation.
Even the schematic for the ShieldBuddy evaluation card is closed-source so don’t expect to get any pointers from that. There’s a HITEX forum for the shieldBuddy board specifically, but this focusses primarily on developing code ‘sketches’ through the Arduino IDE. If you want to develop true ‘C’ programmes for AURIX, there’s not much information publicly available. Given the points above, it is confusing why Hitex produced an Arduino compliant development platform in the first place. Firstly, anyone seriously developing an embedded product isn’t going to start by building it on an Arduino clone. And secondly, the market for Arduino is instead the open source hacker movement, hobbyists and students- the likes of whom won’t be impressed by Infineon’s secrecy about their products. They want a support network and application notes, without having to pay for it. It’s understandable that Infineon want to protect their IP, but why then flirt with the Arduino users by making an Arduino clone?
Working with the TI Hercules family is a much different experience. There is a wealth of support information on the TI website to get you going, and a lively online forum. The tools are free to use and are well documented. There’s not a lot to add about the Hercules ecosystem. It just works, and you can find help when it doesn’t. TI are an open book. It seems that Infineon could learn from TI's example.
Another consideration is end-use. I will admit to having at least one beady-eye on a potential defence and security application for these things, so I thought it wise to enquire about any end-user restrictions. The company-line from the Infineon support engineer was this: “Regrettably we do not support the application of non-HiRel products in military and/or aerospace applications. If you use our non-HiRel products in applications which we do not support, you lose the warranty. And all legal and technical issues which are to be dealt with beyond what has to be done for civil mass market applications or for civil automotive applications would have to be handled by you.”. Being optimistic you might not read this as an outright ‘no’. More of a ‘you’re-on-your-own-with-that’ type of response. Given the same question about their Hercules chips, the response from TI was much less cautious: “Texas Instruments does not provide licensing guidance to other companies. However, we are able to provide the ECCN of our product. If you require assistance regarding license determination; you as the exporter of record will need to obtain guidance from your trade compliance department, legal counsel, or from the Bureau of Industry and Security's Office of Exporter Services in Washington DC. (202) 482-3811”. So, basically TI don’t really care where you put it, as long as you don’t breach US export control laws. You can always rely on the Americans to be open for business.
So which part is best? Well, it depends. To be fair it’s not a straightforward comparison. They are both quite useful, depending on what you are trying to do. It is clear though that both parts could be employed in safety-related applications, if due diligence is observed in building the wider system safety case.
In the event that somebody important at TI or Infineon reads this, I would like to declare where I think they should push their device families in their next generations. Both suppliers need to think about introducing smaller packages for at least some of their parts. There’s a place for safety critical intelligent networked sensors and actuators, which must often be physically small. Ideally it needs to be something that’s under 10 mm x 10 mm without going to super-fine pin pitch. A 100-ball BGA at 0.8 mm pitch would be ideal. Texas instruments should be thinking about what comes next for their safety MCU range. Hercules is getting old now, so an upgraded part is surely due. It would also be useful to see the incorporation of an integrated CAN-FD controller in their MCUs. They are clearly developing products to service CAN-FD, as they have recently released the standalone CAN-FD controller chip (TCAN4550).
Infineon are well known for making incredible parts, but not straightforward to work with in terms of their customer support. Regarding technical support there is no contest between TI and Infineon. TI win every time. Their free tools work very well, they publish everything you need to know to get started online, and there’s a strong community of developers when things start to get difficult. TI’s stuff just works. These factors alone present a powerful argument for the risk conscious developer, even in the face of a technically superior product offering such as the AURIX. The lack of a decent code-configurator is also a major drawback for those new to the AURIX.
More sophisticated product requirements may have pushed me towards the AURIX. However, I reluctantly concluded that I could service the functional requirements of my project with the technically inferior Hercules device in order to spare myself the pain and expense of working with the AURIX. It’s a shame because the AURIX is a formidable processor. If Infineon chose to broaden their horizons by engaging with the wider community, I suspect they could make life very difficult for the likes of Texas Instruments and others.