TMS570LS0332: Guadiance for making SIL3 Device using TMS570LS0332 controller

Hi Tarunraj,

Tarunraj Paddiyar said:

1. TÜV certification and SIL3 compliance

I have seen the TÜV certificate/documentation which states that the controller is suitable/certified for SIL3 applications. However, I could not find "SIL3 compliant" explicitly mentioned in the datasheet itself.

Does the TÜV certificate mean that the controller can be used as part of a SIL3 safety-related system? If so, why is this not mentioned directly in the datasheet? Also, what exactly is covered by the controller's SIL3 certification, and what additional requirements would I need to fulfil at the system level to achieve SIL3?

The TÜV certificate for the TMS570LS0332 means the device has been independently assessed and found to be suitable for use as a component within a SIL3 safety-related system per IEC 61508. This is a "hardware element" certification — it does not mean the controller alone constitutes a SIL3 system.

Why it's not in the datasheet:
Datasheets describe electrical/functional characteristics. Safety certifications are documented separately in the Safety Manual (TI document SPNU511) and the TÜV certificate itself.

Tarunraj Paddiyar said:

2. Do we need two controllers for SIL3?

My understanding is that for SIL3 applications, two controllers may be used with the same software/code and their outputs are compared or monitored. If there is a mismatch, a fault is detected and the system goes into a safe state.

If this architecture is required, do both controllers need to be programmed separately? Or is there any mechanism by which programming one controller automatically programs the other?

Also, is there any specific procedure for programming the Hercules/TMS570 controllers, or can they be programmed in the same way as other TI controllers using the normal JTAG/debug/programming interface?

No — the TMS570 is specifically designed so that you do NOT need two separate physical controllers for SIL3.

The TMS570 family implements CPU Lockstep internally:

• It contains two ARM Cortex-R4F cores running the same code in parallel, with their outputs compared every clock cycle by a Compare Module
• Any discrepancy triggers the ESM (Error Signaling Module), which can drive a dedicated error output pin to put the system into a safe state
• This is all on a single chip — it is the hardware mechanism that enables SIL3 without an external redundant controller

Programming:

• You program the device once through a single programming interface — both cores execute the same binary
• You do not need to program them separately; the lockstep architecture is transparent to the programmer
• Programming is done via JTAG (using TI's XDS debug probes with CCS)

Tarunraj Paddiyar said:

3. Software development and programming approach

I understand that I can use HALCoGen to generate the initial configuration/code and then develop the application in Code Composer Studio (CCS).

However, I would like to understand if there are any specific programming practices that need to be followed for a SIL3 application using the TMS570. For example:

• Coding rules or restrictions

• Functions or programming practices that should be avoided

• How faults and diagnostic checks should be handled

• Use of watchdogs, ECC, CPU self-tests, etc.

• Whether there are any specific requirements for memory, interrupts, communication, or peripheral handling

• Any recommended coding standard such as MISRA-C

• How the software should be structured so that it can eventually go through SIL3 verification/assessment

Basically, I would like to understand the difference between simply developing an application on the TMS570 and developing it in a way that can actually be taken through a SIL3 certification process.

Toolchain

• HALCoGen → generates peripheral driver code and startup/configuration. Use it, but treat its output as a starting point — you must verify it meets your safety requirements.
• Code Composer Studio (CCS) → acceptable IDE. For SIL3, your compiler (TI ARM CGT) must be qualified or its use justified per IEC 61508-3 (tool confidence level / T3 tool qualification may be required).

Coding Standards

• MISRA-C:2012 compliance is strongly recommended and often required by assessors for SIL3
• Enforce with a static analysis tool (e.g., PC-lint, LDRA, Polyspace, or Parasoft C/C++test)
• Avoid dynamic memory allocation (malloc/free) — use static allocation only
• Avoid recursion
• Restrict use of function pointers
• All variables should be explicitly typed and initialized

Tarunraj Paddiyar said:

4. Development board

For the development phase, I am planning to order the LAUNCHXL-TMS57004.

Is this development board suitable for getting started with the TMS570/Hercules family and developing the type of application I have in mind? Are there any major limitations of this board compared with the TMS570LS0332 that I should be aware of?

If there are any other development boards, tools, application notes, safety manuals, or example projects that you would recommend for someone starting a SIL3 project with the TMS570LS0332, please let me know.

Is it suitable? Yes, for getting started and learning the Hercules/TMS570 ecosystem. It is a good low-cost entry point.

• The LaunchPad is not a safety-qualified hardware platform — it is for prototyping only
• You cannot use the LaunchPad as your final safety hardware — you must design your own PCB with the TMS570LS0332 and all required external safety components (external watchdog, power monitoring, error output circuitry, etc.)
• The LaunchPad is fine for software development, HALCoGen familiarization, and initial testing

I would also like to mention that these Hercules family of microcontrollers are matured devices, definitely there is no plan to drop these devices, however for new projects we would encourage our customers to use new functional safety microcontrollers from TI like AM26x or F29x etc. If you want more details, then i can loop marketing expert to guide on this.

--
Thanks & regards,
Jagadish.

Thank you for the response Jagadish

Can you please let me know if it is necessary to use the external watchdog for a device to be SIL3 Compliant? 

Hi Tarunraj,

An external watchdog is not automatically mandatory for SIL3 compliance — but whether you need one depends on your architectural constraints analysis, diagnostic coverage calculations, and common-cause failure (CCF) considerations.

An external watchdog may be necessary or strongly recommended in these cases:

a) Common-Cause Failure (CCF) Mitigation

• The internal watchdog shares the same silicon, power supply, and package as the CPU
• A catastrophic failure (e.g., latch-up, overvoltage, EMI event) could disable both the CPU and the internal watchdog simultaneously
• An external watchdog (separate IC, separate power domain) provides independence and protects against these common-cause failures
• IEC 61508 requires analysis of CCF — if your analysis shows unacceptable risk, an external watchdog is the standard mitigation

b) Architectural Constraints per IEC 61508-2 Annex B

IEC 61508-2 defines Hardware Fault Tolerance (HFT) requirements based on the Safe Failure Fraction (SFF)

• If your FMEDA shows that the internal watchdog alone does not provide sufficient diagnostic coverage to reach SFF ≥ 60% (for HFT=1) or ≥ 90% (for HFT=0), you may need an external watchdog to improve your SFF
• The external watchdog adds diagnostic coverage for faults that the internal watchdog cannot detect (e.g., CPU running but stuck in a loop that still services the watchdog correctly)

c) Assessor or Standard Requirements

• Some industry-specific standards (e.g., ISO 26262 for automotive, IEC 62061 for machinery) or your TÜV assessor may have a presumption that an external watchdog is required for SIL3
• Even if not strictly required by the math, it is often considered good practice and may simplify certification

d) Program Flow Monitoring

• An external watchdog can be configured to require a specific sequence of toggles or a question-answer protocol (e.g., the watchdog sends a challenge, the CPU must respond with the correct answer)
• This provides program flow monitoring — detecting if the CPU is executing the wrong code path, even if it's still running and servicing a simple timeout watchdog
• The internal WWDT provides some of this (windowed servicing), but an external watchdog with a challenge-response protocol is stronger

So, its al depends on your system level analysis.

--
Thanks & regards,
Jagadish.