2
\$\begingroup\$

EDIT: I should make it clear that I am asking in terms of creating the PMBus firmware for the device rather than attempting to program the device using PMBus commands.

In section 10 The PMBus specification (>= rev 1) states that the fault response parameter is a byte made up of several values, one of which is the 3-bit Delay Time value described as

The number of delay time units, which vary depending on the type of fault. This delay time is used for either the amount of time a unit is to continue operating after a fault is detected or for the amount of time between attempts to restart.

The latter part seems ambiguous: "the amount of time between attempts to restart". Is this the amount of time from the start of one restart to the start of the next (fig 1), or from the end of one restart to the start of the next (fig 2)

graphs displaying result of different interpretations

If the first meaning (fig 1) is correct then well and good.

However, if the second meaning (fig 2) is intended then how can one know whether a subsequent fault is part of the previous fault response and should constitute one of the allowed number of retries, or an entirely new fault that should start a response anew?

EDIT: I realised there is a third possible interpretation where the former meaning is taken but the delay time is enforced by stopping any further retry occurring until the delay time for the first retry has expired (fig 3)

illustrating third interpretation

\$\endgroup\$
2
  • 1
    \$\begingroup\$ @AdamLawrence Out of curiosity, do you see much use of PMB currently? \$\endgroup\$
    – Toby
    Jul 15 '16 at 9:27
  • 1
    \$\begingroup\$ I work for a power supply manufacturer. Every product we make uses it, as do the products of our competitors. So yes, but I'm biased :) \$\endgroup\$ Jul 15 '16 at 17:12
1
\$\begingroup\$

Looking at the PMBus 1.1 spec: to understand what to do with the delay time bits for a given fault, you need to look at the corresponding fault response data byte for the particular fault you care about.

  • IOUT_OC_FAULT_RESPONSE
  • VOUT_OV_FAULT_RESPONSE
  • VOUT_UV_FAULT_RESPONSE
  • IOUT_OC_LV_FAULT_RESPONSE

...etc.

Bits 7 and 6 (Response) define what happens: continue without interruption; operate for delay time then follow the retry setting; shut down immediately then follow the retry setting; shut down immediately and stay off until the fault is clear.

Bits 5 to 3 (Retry Setting) control restarts: 000 => don't restart, 111 => restart continuously, 001 to 110 => restart 1 to 6 times

Bits 2 to 0 (Delay Time) - what they do depend on what is commanded by the other bits.

I would argue that your illustration #2 is the correct one. As for whether or not they are all part of the same 'event', well, I don't think there is a command to read back the current retry counter. You'll know when the event(s) are over when the count is exceeded (assuming it's not set to perpetual) as the warning states should become fault states at that instant.

You'll need to implement some sort of timer and decide for yourself how long a period of non-fault, non-warning operation is needed to consider the fault cleared. It could be hundreds of milliseconds or several seconds. You'll then need to define this value in your PMBus documentation.

I am not aware of a PMBus command that could be used to query or control this timeout value - based on the products that I have been involved with, there is no standard command for this. Some developers have implemented manufacturer-specific commands (i.e. MFR_RETRY_DELAY) to provide this functionality.

\$\endgroup\$
6
  • \$\begingroup\$ Still confused. If it is the second one, example settings of bit 7:6 = shutdown then retry, 5:3 restart once. Fault occurs and the device shuts down for delay time then restarts after delay time is complete. Thus the one allowed retry has been consumed. Another fault of the same type occurs again, at some point in the future would this mean the retry failed and thus the unit should shutdown. Or is this an entirely new response and the unit should allow another one retry... without any other timing property how can one determine this? The second fault could be ms or days after the first fault! \$\endgroup\$
    – Toby
    Jul 13 '16 at 19:52
  • \$\begingroup\$ I guess what Im getting at is if one cannot know if the retry is part of a previous response then one cannot have a correct count of the consumed retries and thus cannot know if the device should shut down completely or not. \$\endgroup\$
    – Toby
    Jul 13 '16 at 22:18
  • \$\begingroup\$ Sorry I should have mentioned, I am creating the device firmware, not sending it PMBus commands. I am trying to determine what the operation should be, not what it is. \$\endgroup\$
    – Toby
    Jul 13 '16 at 22:20
  • 1
    \$\begingroup\$ I think I see your confusion: how long is permitted between retries for the retry to be considered 'new' (and thus start from the original retry count) is how I read your issue. \$\endgroup\$ Jul 14 '16 at 13:36
  • 1
    \$\begingroup\$ You'll need to implement some sort of timer and decide for yourself how long a period of non-fault, non-warning operation is needed to consider the fault cleared. It could be hundreds of milliseconds or several seconds. You'll then need to define this value in your PMBus documentation. \$\endgroup\$ Jul 14 '16 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.