• State Resolved
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 123 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F280039: IEC60730-H: Digital IO

Bo XU
Prodigy 166 points

Part Number: TMS320F280039

Currently, a product needs to comply with the IEC 60730 Class B standard. After downloading the C2000 Safety Automotive Industrial Package 3.01.00 and reviewing the documents "Implementing IEC 60730 UL 1998 Compliance for C2000 Real-Time Microcontrollers" and "Functional Safety Manual for TMS320F28003x Real-Time Microcontrollers", I have several questions regarding GPIO testing as follows:

1)For the 60730-H Section 7.1 Digital I/O testing, in addition to regular GPIOs, do PWM or APWM outputs via OUTPUTXBAR fall under the GPIO category?

2)Regarding the description of method GPIO4 below, I do not fully understand it. For example, if GPIO A is configured as an input/output , GPIO A outputs, and GPIO A is simultaneously read back and compared, does this comply with method GPIO4?

image.png

  • 0
    TI__Expert 6030 points

    Hi Bo,

    How you implement diagnostics depends on what creates the pin signal: if the pin is used as a GPIO (software-driven output), then the GPIO diagnostics apply. If the pin is carrying an ePWM/APWM-generated waveform even if routed out through pinmux / OUTPUTXBAR , then it’s generally more appropriate to treat it as a PWM output and use the ePWM-related diagnostics. Routing a PWM through OUTPUTXBAR doesn’t automatically make it a GPIO for diagnostic purposes; it’s still a PWM-originated digital output.

    The intent of GPIO4 is not the output latch. It is to verify the I/O function via a loopback observation at the input boundary, so you’re validating more of the real signal path than just a register value. Typical way to implement is to drive GPIO_OUT on one pin then physically wire it to a different pin configured as GPIO_IN and  compare expected vs observed input state.

    A single pin can’t truly be an independent input and output at the same time in the sense of two separate pins. While you may be able to read a pin status while driving it, that often collapses into you read back what the output driver is doing, which does not provide the intended diagnostic strength for loopback.

    Best Regards,

    Masoud

  • 0 in reply to Masoud Farhadi
    Prodigy 166 points

    1) For the first question, can I understand it as follows? My system utilizes peripherals such as GPIO, PWM, CAN, etc. From a functional perspective, they all fall under the GPIO category of IEC60730-H Section 7.1. It is necessary to perform corresponding diagnostic functions for different modules to fulfill the requirements of Section 7.1.

    2) For the second question, an I understand it as follows?  GPIOA outputs, GPIOB inputs, and the comparison completes the diagnosis.

  • 0 in reply to Bo XU
    TI__Expert 6030 points

    I'll our functional safety expert to confirm/add more info. here.

    Best Regards,

    Masoud

  • 0 in reply to Masoud Farhadi
    TI__Expert 7335 points
    Bo XU said:
    1) For the first question, can I understand it as follows? My system utilizes peripherals such as GPIO, PWM, CAN, etc. From a functional perspective, they all fall under the GPIO category of IEC60730-H Section 7.1. It is necessary to perform corresponding diagnostic functions for different modules to fulfill the requirements of Section 7.1.

    As IEC60730 Class B ask for Plausibility check only on digital IO, it is recommended to test all IOs being used for safety related function (GPIO/PWM, etc). and CAN fall under communication, and normally covered by end to end safety, like CRC check, etc.

    Bo XU said:
    2) For the second question, an I understand it as follows?  GPIOA outputs, GPIOB inputs, and the comparison completes the diagnosis.

    Let me double confirm, but I believe this is not normally required by IEC60730. Just readback from same GPIO cell should be sufficient. If you have one very critical signal that need full redundancy, then you can implement this.

    You can refer to this app note for more details.

    https://www.ti.com/lit/po/sprt759a/sprt759a.pdf

  • 0 in reply to Han Zhang6
    Prodigy 166 points

    Hello expert, thank you for your reply. The first question is ok. The description of the C2000 Unique ID GPIO4 (as shown in the image from my first question) makes me confused about the 2nd question.


    The system currently being designed is for bidirectional power conversion, and includes three types of functional safety-related digital I/Os. I am unsure whether the current measures I have taken are sufficient to meet the functional safety diagnostic requirements for digital I/Os under IEC 60730 Class B. Could you please evaluate this based on your experience?

    1)Output I/Os: For I/O outputs, is reading back the same I/O status sufficient to meet the requirements?


    2)Input I/Os: For I/O input signals, is cross-verification with communication signals sufficient to meet the requirements?


    3)PWM Signals: Since many PWM signals are used, it is difficult to perform signal comparisons. However, I noticed a description of "Unique ID - PWM11 (ePWM Application Level Safety Mechanism)" in the document "Functional Safety Manual for TMS320F28003x Real-Time Microcontrollers" as follows:

    At the system level, dsp monitors parameters such as voltage, current, and temperature.Is this sufficient to meet the requirements? For PWM signals at the I/O level, are additional diagnostic measures necessary? If additional measures are still required, what is the minimum Unique ID that must be added to meet the diagnostic requirements for digital I/Os under Class B?

  • +1 in reply to Bo XU
    TI__Expert 7335 points
    Bo XU said:
    1)Output I/Os: For I/O outputs, is reading back the same I/O status sufficient to meet the requirements?

    This depends on the design of your system and what is the function / failure mode / hazard of failure of this signal. Reading back from same GPIO will cover a lot of faults, but will not cover the complete signal chain, especially not covering package related fault. If you want whole signal chain coverage, then you will need to route the signal back into another GPIO for readback.

    Bo XU said:

    2)Input I/Os: For I/O input signals, is cross-verification with communication signals sufficient to meet the requirements?

    If your comm protocol have end to end safety coverage (for example, one common implementation is adding a CRC in message), then it will provide sufficient coverage to the signal.

    Bo XU said:
    3)PWM Signals: Since many PWM signals are used, it is difficult to perform signal comparisons. However, I noticed a description of "Unique ID - PWM11 (ePWM Application Level Safety Mechanism)" in the document "Functional Safety Manual for TMS320F28003x Real-Time Microcontrollers" as follows:

    For PWM failure detection, using system level mechanism is normally sufficient in a feedback control system. However, if PWM signal is your only means of achieving safe stage (turn off the power system), this may have risk if the IO or gage driver stuck at on state. You may need to implement some redundant method of achieving safe stage, common way including use GPIO to disable gage driver or gage driver power supply.

    Han

  • 0 in reply to Han Zhang6
    Prodigy 166 points

    谢谢，thank you.