2

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

Toby
  • 825
  • 1
  • 8
  • 16
  • 1
    @AdamLawrence Out of curiosity, do you see much use of PMB currently? – Toby Jul 15 '16 at 09:27
  • 1
    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 :) – Adam Lawrence Jul 15 '16 at 17:12

1 Answers1

1

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.

Adam Lawrence
  • 32,921
  • 3
  • 58
  • 110
  • 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! – Toby Jul 13 '16 at 19:52
  • 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. – Toby Jul 13 '16 at 22:18
  • 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*. – Toby Jul 13 '16 at 22:20
  • 1
    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. – Peter Smith Jul 14 '16 at 13:36
  • 1
    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. – Adam Lawrence Jul 14 '16 at 13:41
  • @AdamLawrence If you'd like to edit your answer to this effect I'll accept it. Also, do you have any reference for this? (existing product data sheet, PMB org presentation slides, etc). Thanks – Toby Jul 15 '16 at 09:26