SLUSCC7 Data sheet

SLUSCC7C July 2016 – June 2018 TPS546C23

PRODUCTION DATA.

Package Options

Mechanical Data (Package|Pins)

RVF|40
- MPQF268C

Thermal pad, mechanical data (Package|Pins)

RVF|40
- QFND333E

Orderable Information

7.3.25 Auto ARA (Alert Response Address) Response

By default, the devices implement the auto alert response, a manufacturer specific improvement to the standard SMBALERT response protocol defined in the SMBus specification. The auto alert response is designed to prevent SMBALERT monopolizing in the case of a persistent fault condition on the bus. The user can choose to disable the auto ARA response, and use the standard SMBALERT response as defined in the SMBus specification, by using the EN_AUTO_ARA Bit of the OPTIONS (MFR_SPECIFIC_21) register.

In the case of a fault condition, the slave device experiencing the fault pulls down the shared SMBALERT line, to alert the host that a fault condition has occurred. To establish which slave device has experienced the fault, the host issues a modified receive byte operation to the alert response address (ARA), to which only the slave pulling down on SMBALERT should respond. The SMBus protocol provides a method for address arbitration in the case that multiple slaves on the same bus are experiencing fault conditions. When the host has established the address of the offending device, it must take any necessary action to release the SMBALERT line. For more information on the standard SMBus alert response protocol, refer to the SMBus specification.

In the case of a non-persistent fault (a single-time event, such as an invalid command or data byte), the host can ascertain the address of the slave experiencing a fault using the standard ARA response, and simply issue CLEAR_FAULTS to release the SMBALERT line, and resume normal operation. However, in the case of a persistent fault (one which remains active for some time, such as a short-circuit, or thermal shutdown), once the device issues a CLEAR_FAULTS command, the fault immediately re-triggers, and SMBALERT continues to be pulled low. In this case, the device holds low the SMBALERT line until the host masks the SMBALERT line using SMBALERT_MASK and then issues the CLEAR_FAULTS command. Because the SMBALERT line remains low, the host cannot be alerted to other fault conditions on the bus until it clears SMBALERT. Figure 35 and Figure 36 show this response.

TPS546C23 dd_too_SLVSCC5_DESC_NON_AUTO_ARA.gif

Figure 35. Example Standard ARA Response to Nonpersistent Fault

TPS546C23 dd_too_SLVSCC5_NON-AUTO_ARA_PERSIST.gif

Figure 36. Example Standard ARA Response to a Persistent Fault

To mitigate the problem of SMBALERTbus hogging described previously, the devices implement the Auto ARA response. When Auto ARA is enabled, the devices releases SMBALERT automatically after successfully responding to access from the host at the alert response address. In this case, even when the device is experiencing a persistent fault, it does not hold the SMBALERT line low following successful notification of the host, and the host can be alerted to other faults on the bus in the normal manner. Examples of the auto ARA response are shown in Figure 37 and Figure 38.

TPS546C23 dd_too_SLVSCC5_AUTO_ARA_NON-PERSIST.gif

Figure 37. Example Auto ARA Response to Nonpersistent Fault

TPS546C23 dd_too_SLVSCC5_AUTO_ARA_PERSIST.gif

Figure 38. Example Auto ARA Response to Persistent Fault