• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 731 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TPS544C25: SMBALERT from STATUS_CML

John Clark1
Prodigy 10 points
Part Number: TPS544C25

I have an SMBALERT that appears to originate from an errored programming of the SMBALERT_MASK. This condition is described in paragraph 3 in section 7.6.8 of the TPS544x25 reference. As the corrupted STATUS_X command code is due to noise I have no method to prevent this occasionally happening. Note that the Tx command does use PEC hence should be disregarded but seems not.

How can I clear down the SMBALERT? Writing 1's or 0's to STATUS_CML and clearing FAULTS does not prevent the PMB Alert from rearming immediately.

  • 0
    TI__Guru**** 191445 points

    John,

    Peter from our team will look into this today.

  • 0
    TI__Guru 56795 points

    John,

    Per the PMBus Specification Revision 1.2, Part II, section 10.8.1 (Page 42)

    If a PMBus device detects that the Packet Error Code (PEC) calculated by the receiving device does not match the received PEC, the preferred response is to NACK the PEC byte.  Some PMBus devices may not be able to calculate the PEC and respond in time to NACK the last byte.  This is acceptable behavior.

    Whenever a PMBus device detects that the received and calculated PEC bytes do not match, whether or not the device was able to NACK the PEC byte, the device shall respond as follows:

    Not respond to or act upon the received command

    Flush or ignore the received command code and any received data

    Set the CML but in the STATUS_BYTE (and low byte of STATUS_WORD)

    Set the Packet Error Check failed bit in the STATUS_CML register (if supported)

    Notify the host as described in Section 10.2.2

    So, the part is responding correctly to a noise corrected transmission that is failing Packet Error Check.

    You should be able to clear the SMB_ALERT assertion by:

    Contact the TPS544C25 via the Alert Response Address by sending a Receive Byte transaction (Slave Address + Read bit) on the PMBus and allow the TPS544C25 to respond with its address.  (Alert Response Address is PMBus Address 12d, Address byte contents 19h)

    This will cause the TPS544C25 to release SMB_ALERT until a new fault or warning is generated.

    Send a CLEAR_FAULTS to the device by using the Send Byte protocol to Command Code 03h

    Write to STATUS_CML (Command Code 7Eh) with a "1" in the position of the bits to be cleared (FFh will clear all bits)

    For CLEAR_FAULTS and STATUS_CML, if the fault is continually occurring, the status bit will immediately be re-written and SMB_ALERT will be reasserted.

    After an ARA response, SMB_ALERT should remain released until a new fault occurs, but not if the same fault persists.

    To mask the PEC failure from asserting SMB_ALERT:

    Use the Write Word Protocol [ Address + Wr ] [Command Code: 1Bh] [ Low Byte (Status Command Code): 7Eh ] [ High Byte (Mask Byte): 20h ] to set the MASK_SMB_ALERT Bit 5 (PEC) in STATUS_CML.

    I would recommend reading STATUS_WORD (Command Code 79h) to verify if there are any faults other than PEC being triggered.