• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 194 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PGA300: Diagnostics

Rammstein
Prodigy 60 points
Part Number: PGA300

Hello,

Briefly we have a PT-100 sensor at the temperature input and get voltage output from 0.250 to 4.75 V in our application.

We would like to implement a sensor break diagnostic and for this we have done the following settings from the GUI.

Diagnostic Enable : 0x1 

AFEDIAG_CFG : 0x7

AFEDIAG BIT MASK : 0x4 ( Only the TINP+ OV).

FAULT VALUE: 5 V

In case of a sensor break,  TINP+ goes to 2.5V and TINP- goes to GND in our curcuit. 

When we break the  sensor for testing, the output goes to the FAULT VALUE as expected  but never get backs to normal value  after we reconnect the sensor.

The only way to reset this condition is to make a power off and on cycle to the circuit.

Is it a normal behavior? We could not find any explanation about this behavior in the datasheet 

We would expect a recover from the error state after we reconnect the sensor while the circuit is operating.

Best Regard,

  • 0
    TI__Guru** 113765 points

    Hi Rammstein,

    I will have to do a little investigation on this.  I will respond back tomorrow.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    TI__Guru** 113765 points

    Hi Rammstein,

    Maybe I'm not totally clear on what you are saying.  Are you saying that the diagnostic fault condition in the AFEDIAG status never clears or the actual data is incorrect?  Have you tried clearing the status bit by writing 0, or disabling and reenabling the diagnostics to clear the condition?

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 60 points

    Hi Bob,

    Our device is a temperature signal converter generating an output signal of 0.250 V to 4.75 V in a response to temperature input of -50 to 150°C. In other words, while the temperature is changing from -50 to 150 C, the output signal changes from 0.250 V to 4.75 V. For this operation, we are using a Pt-100 temperature sensor which is connected to temperature input of the device and is driven by the internal current source of 500 uA. Another important aspect of these type of devices is how the output will behave in case of a sensor fault. In other words, when the Pt-100 sensor is broke or disconnected for some reason, what will be the output signal level? It is very important because the system which operates with the converter must behave in a safe manner when the temperature sensing fails. In order to assert this sensor fail condition, the output is desired to go high to keep the system safe. As I mentioned before, we setup the diagnostic with the following settings,

    Diagnostic Enable : 0x1 

    AFEDIAG_CFG : 0x7

    AFEDIAG BIT MASK : 0x4 ( Only the TINP+ OV).

    FAULT VALUE: 5 V

    Which implies that when the temperature input sees an over voltage condition (this occurs in our device when the Pt-100 is broke or disconnected), INT_OV flag will be set and in a response to that, the output goes to the DAC_FAULT value which is configured to 5 V output. This is the exact behaviour that we want from our device. When we test this condition by disconnecting the Pt-100 sensor, we saw that the output went high as expected. It is perfect BUT after we reconnect the Pt-100 sensor, the output stayed at the high level. We expect the output to return to the normal level after we reconnect the Pt-100 sensor but it did not. We think that the DAC_FAULT is active even if the fault condition is resolved. It resolves only after a power off-on cycle. In normal operating conditon, we dont have OWI , we are using OWI just for the configuration.

    I am sorry that I can not explain it better than that. Hope everything is clear.

    Best Regards,

  • 0 in reply to Rammstein
    TI__Guru** 113765 points

    Hi Rammstein,

    You have explained your use case well.  I will have to try to duplicate the process to understand better why the DAC_FAULT doesn't clear. This will take me a few days to properly setup in my lab.  So expect an additional response by the end of the week.

    Best regards,

    Bob B

  • +1 in reply to Bob Benjamin
    TI__Guru** 113765 points

    Hi Rammstein,

    I was able to set this up rather quickly and I'm able to duplicate the same thing you are seeing.  Unfortunately the fault will not clear on its own and is actually latched requiring the fault be cleared manually.  When a fault is detected, the corresponding bit in AFEDIAG register is set.  Even after the faulty condition is removed, the fault bits remain latched.  To remove the fault, M0 software must read the fault bit and write a logic zero back to the bit.  In addition a system reset clears the fault (as will a power reset).

    All I had to do was to activate the OWI to clear the fault as the M0 went to a reset state.  Obviously a power-cycle would do the same.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 60 points

    Thank you for making it clear for us.