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.

TMP431: TMP431 - SMBus Alarm and ALERT Pin issues

Part Number: TMP431

We are seeing unexpected behavior on the TMP431. The following document was used for functionality description:  SBOS441H –SEPTEMBER 2009–REVISED MARCH 2016

There are two separate issues, as follows:

 1) Every access to the SMBus alarm response address will set the MASK bit in register 0x3/0x9. The scenario is this: device hits one of the alarm limits, ALARM is asserted.  The condition then goes away. An SMBus ARA is issued to dessert ALARM. As soon as the TMP431 receives the ARA, it internally sets MASK in the config register 0x3/0x9 thus no interrupt will ever occur form this device, until the mask is cleared.

Comment - Since there is no mention of this behavior in the above referenced document, we consider this a bug.

 2) The above referenced document states: “Clearing the Status Register bits does not clear the state of the ALERT pin; an SMBus alert response address command must be used to clear the ALERT pin.”

 Comment - This statement is demonstrably false. Provided the condition that triggered the alarm has gone away, a simple read of the status register clears not only the status register bits, but deserts the ALARM signal, in direct contradiction with the quote above.

  • Hi Steven,

    I am not seeing these behaviors.

    Can you please send scopeshots of the I2C interactions for your both your observation.

    Thanks,
    David

  • Hi Steven,

    Thank you for the slides on these two issues. I was able to replicate both these behaviors on my setup. We will update the datasheet as soon as we can to document these behaviors.

    Thanks,
    David
  • Just adding some additional info. See new attached (v2) info. This version adds a new issue – real time misbehavior.

    One of the following statements is true:

    1. TMP431 has unpredictable behavior (at least) with respect to reporting evens through interrupts. It is to be use only in simple non-real time application
    2. TMP431 has a well-defined behavior with respect to interrupts and is suitable for real time applications, but is has inaccurate documentation. In this case we need detailed timing diagrams, necessary delays if any, interaction between threshold setting and alarm clearing, methods to clear alarm and in which states this can be done etc.

    TMP431_Debug-v2.pptx

  • Hi Steven,

    A conversion cycle must take place before the thresholds are updated. After the conversion cycle you should see expected behavior of using a read of the status register to clear the Alert.

    Thanks,
    David
  • Just a few more questions:

    Which order is correct, a) or b) below?

    a) Change threshold, wait conversion period, confirm

    b) Wait conversion period, change threshold, confirm.

     

    Does this mean for a conversion rate of 0.0625 (reg 0x4 = 0), we have to wait 16 seconds?

  • Hi Steven,

    "A" is correct.

    Conversion rate of .0625 per second (reg 0x4 = 0) does mean you will have to wait 16 seconds plus the time is takes to complete a conversion cycle shown in the electrical characteristics table on page 6 of the datasheet.

    Thanks,
    David
  • Another question from S/W engineering:
    As per latest, the fastest you can clear an interrupt is 62.5 ms – at the max conversion rate. This is unacceptable in a real time system. We need to find another way to at least clear the ALRAM signal state if not the internal state of the device. Is the MASK bit in register 3 also subjected to this limitation or does this bit act instantaneously (that is, when setting MASK, ALARAM desserts right away regardless of the internal state of the ALARM logic)?
  • Hi Steven,

    The MASK bit is not limited by the conversion time. You can use this for real time systems or you can use the ARA call which uses the Mask bit to clear the alert pin.

    Thanks,
    David
  • David,

    Could you please provide documentation addressing the following items:

    • recommended method of canceling the internal  alarm condition, with timing. This will list the registers that need to be changed, the order and all timing constraints.
    • recommended method of controlling the ALARM signal if independent from the alarm state. Timing constraints must be included.
    • behavior of the BUSY bit in relation to the internal alarm state, conversion rate/period
    • clear definition of conversion rate. That is, at 0.0625 conversion per second, do you have one conversion that takes 16 seconds or you have one conversion that takes 1 millisecond, stop for 15.999 seconds and then convert again? How does this relates to the BUSY bit?

    Thx.

    Steve

  • Hi Steven,

    I am working on this. Please give me a few days to gather this information for you.

    Thanks,
    David

  • Hi Steven,

    To clear the internal alarm condition please use a read of the status register. See Table 6.6 and Figures 13-17 for timing requirements.

    Only way to control Alarm signal independent of the alarm state is to use the Mask bit which will bring alarm High if there is an Alarm condition. If you need to force an alarm condition this can be done by changing the thresholds, but as stated before you would need to wait until conversion cycle for those to update.

    The BUSY bit reads as 1 if the ADC is making a conversion. This bit reads as 0 if the ADC is not converting

    Conversion rate is how many conversions will happen per second (ie. conversion time plus wait time). The conversion time is how long it takes to do a conversion as seen in the electrical characteristics table under "TEMPERATURE MEASUREMENT CONVERSION TIME (PER CHANNEL)"

    See above answer on busy bit.
  • Will you be formally updating the existing datasheet with this information? It's good to have these answers but we would like to see if formally documented. Please advise. 

  • Hi Steven,

    We will be updating the datasheets and formally documenting this information.

    Thanks,