SPRUI78D March 2019 – January 2022 TMS320F28075 , TMS320F28075-Q1 , TMS320F28076 , TMS320F28374D , TMS320F28374S , TMS320F28375D , TMS320F28375S , TMS320F28375S-Q1 , TMS320F28376D , TMS320F28376S , TMS320F28377D , TMS320F28377D-Q1 , TMS320F28377S , TMS320F28377S-Q1 , TMS320F28378D , TMS320F28378S , TMS320F28379D , TMS320F28379D-Q1 , TMS320F28379S
Hardware redundancy techniques can be applied via hardware or as a combination of hardware and software to provide runtime diagnostic. In this implementation, redundant hardware resources are utilized to provide diagnostic coverage for elements within and outside (wiring harness, connectors, transceiver) TMS320F2837xD/S and TMS320F2807x MCU.
In case of peripherals like GPIO, XBAR, PWM, OTTO, DAC, CMPSS, XINT and so forth, hardware redundancy can be implemented by having multi-channel parallel outputs (where independent outputs are used for transmitting information, and failure detection is carried out via internal or external comparators) or input comparison/voting (comparison of independent inputs to ensure compliance with a defined tolerance range (time, value)). In such scenarios, the system can be designed such that the failure of one input/output does not cause the system to go into a dangerous state. While servicing the error conditions (redundancy conditions) as in two redundant sources tripping the PWM, always read-back the status flags and ensure that both sources are active while tripping and thus providing latent fault coverage for the trip logic.
In case of peripherals like SDFM, ADC, ECAP, EQEP and so forth, hardware redundancy may be implemented by having multiple instance of the peripheral sample the same input and simultaneously perform the same operation followed by cross check of the output values.
In case of communication peripherals like DCAN, SPI, SCI, McBSP and so forth hardware redundancy during signal reception can be implemented by having multiple instance of the peripheral receive the same data followed by comparison to ensure data integrity. Hardware redundancy during transmission can be employed by having complete redundant signal path (wiring harness, connectors, transceiver) from the transmitter to receiver or by sampling the transmitted data by a redundant peripheral instance followed by data integrity check.
Hardware Redundancy for device interconnect, External Memory Interface (EMIF) and flash (bank/pump/pre-fetch and data buffer) can be implemented by simultaneous data storage/transmission using two different module instances independently, fetched by independent processing units for computation followed by comparison of the computed results. CPU1 fetching data using first EMIF instance, CPU1.CLA1 fetching data using second EMIF instance and both interdependently processing the inputs and implementing a reciprocal comparison is an example of Hardware Redundancy implementation for EMIF and device interconnect.
While implementing hardware redundancy for ADC and DAC modules, additional care needs to be taken to ensure common cause failures do not impact both instances in same way. Reference voltage sources configured for redundant module instances should be independent. Additionally for ADC SOC trigger sources used for redundant ADC instance should be configured to different PWM module instance. In case of DAC module the comparator can be implemented using an external device.
While implementing hardware redundancy for the PWM module, it is recommended that PWM module instance used is part of separate sync chains. This is to avoid common cause failure on sync signal affecting both the PWM modules in same way.
While implementing hardware redundancy for GPIO module, it is recommended to use GPIO pins from different GPIO groups to avoid common cause failures.