PSM Applications : GPIOB_ASSERTED_LO

Created by Michael Holloway, last modified on Oct 05, 2015

The channel was turned off or prevented from turning on at least once because the channel's GPIOB pin was asserted low and the channel is configured to respond to the pin.  The root cause item of interest either another channel or external device in the system that asserted the pin low.

Shared Fault Pins are used as a bi-directional fault coordination bus for other PSM devices or external devices.  Some PSM devices name the shared fault pin "FAULTBX" while others name it "GPIOB".  GPIOB pins can be used for other purposes as well, but are typically used for fault sharing.  See the next section for a better understanding of how fault sharing behavior works.

Device Behavior in a Shared Fault Scenario

The example waveform above illustrates fault sharing behavior of the 'root offender' channel in conjunction with a 'responder channel'.

NOTE: This is one specific example for the purpose of understanding.  The following events occur in the example:

  • a -- A channel (called 'root offender') encounters a fault (over voltage in this example) with a non-ignore response setting, and disables its output (example VOUT_OV_FAULT_RESPONSE= Deglitched Off, Infinite Retry)
  • b -- When its output is disabled, the root offender, if configured to propagate to a shared fault pin (FAULTB OR GPIOB) will immediately pull low on the open drain shared fault pin.
  • c -- A responder channel (configured to respond to the shared fault pin) will immediately stop power delivery (immediate off)
    • For PSM Controllers, power deliver is stopped by the controller itself, and the condition is reported as GPIOB_ASSERTED_LO
    • For PSM Managers, the output enable (VOEN) pin is de-asserted to disable the managed power supply, and the condition is reported as FAULTBX_IN

NOTE: The LTC2977, LTC2980, and LTM2987 may be optionally configured to honor off sequencing delays (TOFF_DELAY) before de-asserting the VOEN pin upon fault.

  • d -- After the root offender has waited its programmable retry delay (MFR_RETRY_DELAY),  if the fault is no longer present (as in this example), it releases the open drain shared fault pin.  
    • This signals to all responder channels that a re-sequence should occur.  
    • The rising edge of GPIOB sets time=zero for a coordinated re-sequence of the root offender and any responder channels.
  • e -- During the coordinated re-sequence, a responder channel, after waiting its programmed on delay (TON_DELAY) will start ramping its voltage up
    • Controllers have the ability to ramp the voltage directly, and will ramp the output consistent with the programmed TON_RISE setting.
    • Managers will assert the assert the VOEN pin to enable the managed supply at this time

Possible Causes:

  • Missing a pullup on the GPIOB pin 
  • Another chip or channel is pulling the GPIOB pin low. Check the rest of the system for faults:
    • If the responder channel remains off, the 'Why am I Off?' will provide a succinct list of faults in your system
  • An External Device other than a LTC device may be holding GPIOB low.  
    • Check the schematic for any other devices that may be connected to the GPIOB pin (an unprogrammed FPGA for instance)
  • You may have a misconfiguration that may keep the GPIOB low.  Read the configuration and click the "DRC" button in the toolbar to check it.
  • You may also scan the system for faults manually:
    • Select the FAULT_WARN_LIST pseudo-register in the Telemetry/Status window
    • Use the 'All Pages in System' view to scan the FAULT_WARN_LIST across the system to see all faults/warnings in the system in one place.  
    • If there are any 'red' channels in the system tree, focus on these channels first.
    • Look for critical or important faults (OV, OC, OT, etc) on another chip that is propagating to the GPIOB/FAULTB pin

Remedies and Workarounds

Here are some experiments you can try to narrow things down:

  • Configure the channel to ignore the GPIOB pin in the "Fault Sharing" Section of the configuration.  This will allow the channel to startup up regardless of the pin.
  • To determine if the 'root cause' is a PSM device or external source (unprogrammed FPGA, etc) driving the pin low:
    • Disable propagation to GPIOB/FAULTB for all devices in the system
    • If the GPIOB pin remains low, this indicates an external device or circuit may be keeping the pin low.
  • If the DRC check produces any warnings, fix these and see if the problem goes away.

Other Debugging Tips

If the channel is presently off, use the "Why am I Off? Tool".  Otherwise, if you have an oscilloscope, do the following:

  • Trigger the scope on the falling edge of this channel's GPIOB pin and 
  • Look at other possible signals in the system that may be responsible driving GPIOB low
  • Disable fault propagation for all devices.  If the pin is still low, trace the schematic for any devices connected to the pin and insure they are not driving it low.

 

Attachments:

image2015-9-24 14:26:25.png (image/png)