SFFS277 November 2023 TMS320F280033 , TMS320F280034 , TMS320F280034-Q1 , TMS320F280036-Q1 , TMS320F280036C-Q1 , TMS320F280037 , TMS320F280037-Q1 , TMS320F280037C , TMS320F280037C-Q1 , TMS320F280038-Q1 , TMS320F280038C-Q1 , TMS320F280039 , TMS320F280039-Q1 , TMS320F280039C , TMS320F280039C-Q1
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) TMS320F28003x MCU.
In case of peripherals like GPIO, X-BAR, ePWM, OTTO, DAC, CMPSS and XINT, hardware redundancy can be implemented by having multichannel parallel outputs (where independent outputs are used for transmitting information, and failure detection is carried out via internal or external comparators) or input comparison or voting (comparison of independent inputs to ensure compliance with a defined tolerance range on time and 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 (for example, 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 ADC, eCAP, HRCAP and eQEP, 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 SDFM, hardware redundancy may be implemented by having multiple channels sample the same input followed by cross check of the output values.
In case of communication peripherals like SPI and SCI, 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 (INC) can be implemented by redundant data storage/transmission by independent processing units for computation followed by comparison of the computed results.
In case of Dual Code Security Module (DCSM), C28x CPU and CLA can be configured to access its resources via independent Zones. Reciprocal comparison can be implemented between CPU and CLA to enable detection of a fault in DCSM module.
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 ePWM module instance. In case of DAC module the comparator can be implemented using an external device.
While implementing hardware redundancy for the ePWM module, it is recommended that ePWM module instance used is part of separate sync chains. This is to avoid common cause failure on sync signal affecting both the ePWM modules in same way.
While implementing hardware redundancy for GPIO module, it is recommended to use nonadjacent GPIO pins from different GPIO groups to avoid common cause failures.