Hacking HP Common Slot Power supplies - 12V@100A Page 1 sur 8

Hacking HP Common Slot Power supplies -

14th October 2016
12V@100A
I currently need a high power 12V power supply (to feed a Class-D amp, which in turn is going to provide an
easily tuned source of ~60Hz power, to drive a stirling cycle helium cryocooler, to make liquid nitrogen -
more on that another time).

Lots of people in the RC community have hacked server power supplies to this purpose, and I happen to
have a couple of HP 1200W DL580 PSUs to hand which should both be fairly easy to adapt, and offer pretty
high efficiency.

[https://2.bp.blogspot.com/-
4W781SdSez8/WADekzDg5cI/AAAAAAAAAGc/gtprQwaBTpEnBRaJ68_P6kNvWDLOkgT2ACLcB/s1600/2016-10-14%
2B14.31.39.jpg]

Looking on the various blogs, the current most common way to get these supplies to operate, is by attaching
an ~1K resistor between pins 33 & 36 http://www.rchelination.com/setting-hp-dps-1200fb-power-supply/
[http://www.rchelination.com/setting-hp-dps-1200fb-power-supply/] , but there are very few details as to why this
works.

As part of my "day job" I've worked on the design of quite a few systems using high power PSUs, and I was
keen to understand a bit more about these units before just hacking away. I also wanted to see if there was
a way to easily monitor the output voltage and current of the supply from a Raspberry Pi (most PSU of this
class have an I2C bus).

The DL580 1200W PSU is just one of a range of HP PSUs which fit into servers with the "Common Slot"
support http://www.hp.com/ctg/Manual/c03502743.pdf [http://www.hp.com/ctg/Manual/c03502743.pdf] .

Compatible units have varying powers and efficiencies, but all share the same physical form factors, which
has power entry at the front (DC or AC)

http://colintd.blogspot.ca/2016/10/hacking-hp-common-slot-power-supplies.html 2017-03-28
Hacking HP Common Slot Power supplies - 12V@100A Page 2 sur 8

[https://2.bp.blogspot.com/-
qX96toWPA5Q/WADg5WPbHBI/AAAAAAAAAGo/wU819NnWPaAvXxM7_e8dVLvn7pvS58NFQCLcB/s1600/2016-10-
14%2B14.41.02.jpg]

and an edge connector at the back which feeds power to the server and provides control & monitoring.

[https://2.bp.blogspot.com/-
yR1FvTFVvR4/WADhFYukFKI/AAAAAAAAAGs/mkcjtHCIZ3889899N8-IwL8CinG5dMMuwCLcB/s1600/2016-10-14%
2B14.40.40.jpg]

That the two large areas provide the main 12V feed is both obvious and well proven, but I couldn't easily find
any details on the control signals (contacts 27-38).

Having designed with similar supplies in the past I've got a fairly clear idea of the kind of signals which
should be the interface: present, enable, PMBUS serial interface (address setting, SCL/SDA & alarm),
standby power, current share, possibly remote sense, etc) but I wanted to have precise details.

Some quick work with the multimeter, a peek at the PCB, some prior knowledge of similar units, and a bit of
I2C bus analysis suggests the following assignments for the bottom contacts:

27-29 = Used at start of day to set PMBus slave address for the PSU (at least I've verified 27 causes an
address change, and I suspect the other two will also).

http://colintd.blogspot.ca/2016/10/hacking-hp-common-slot-power-supplies.html 2017-03-28
Hacking HP Common Slot Power supplies - 12V@100A Page 3 sur 8

30 = Signal Gnd
31 & 32 = PMBus SDA/SCL lines allowing monitoring and control of the PSU inline with
https://en.wikipedia.org/wiki/Power_Management_Bus [https://en.wikipedia.org/wiki/Power_Management_Bus]
(This is something I plan to explore further in the future)

Looking at the top:

38 = PS alarm

I know that PMBus PSUs normally have an active low alarm output, and from the idle voltages
and unpowered resistance, I am fairly certain that this is pin 38

37 = 12V Standby Power

Good for 2.5A, and perfect for powering a 12V-5V converter for the Raspberry Pi I want to use for
monitoring/control.

That leaves 33,34,35 & 36.

33 & 36 are clearly involved in enabling the supply, both because that is where people are currently
connecting a resistor, and because 36 is a short "last make / first break" contact. Having said that, I wasn't
convinced that the intended mode of operation was to join the two signals with a resistor.

I have various reasons for this belief, including that:

• it is normal to have separate "enable" & "present" signals
• testing shows power up with a bridging resistor only works for quite a limited range of values, with
resulting pin voltages which are quite atypical of these interfaces
• the voltage on pin 36 with the resistor present is very suggestive of a diode clamp to ground.

36 = Present

Having taken some measurement on a live server, I am fairly certain that 36 is a dual purpose "present"
signal which is pulled up by the platform from a voltage derived from the standby power. When a PSU slot
is empty (but the server has other PSUs in place), this signal will be high on the server side showing no PSU
in place. When a PSU is inserted, the server signal is clamped to about 0.53V (a typical diode drop, or
transistor base voltage) by the PSU which allows the server to notice a new PSU. From the PSU
perspective, this input being pulled up tells the PSU that it is full inserted (making the transistor base
interpretation more likely).

In my testing, a 22K resistor between pin 36 & 12V Standby power (pin 37) is enough to make the PSU
think it is inserted into a slot. With the clamp action of the input, this gives around 500uA of current.

33 = Enable#

With the Present pin biased from 12VSB, pulling pin 33 directly to ground causes the main 12V output to

http://colintd.blogspot.ca/2016/10/hacking-hp-common-slot-power-supplies.html 2017-03-28
Hacking HP Common Slot Power supplies - 12V@100A Page 4 sur 8

enable. Looking at the current, open voltage and operation point, it looks like the pin is pulled up to the PSU
internal 3V3 bus via a 10K resistor, and is monitored via a standard CMOS Schmitt trigger input gate.

I've not yet tried controlling the PSU over the PMBus, but PSU of this type can typically be enabled either via
the Enable# pin, or via software control.

This splitting of 33 & 36, into a pulled up / clamped "present" signal, and a simple pull to ground "enable#"
signal (which can also be driven over I2C) is much more consistent with other PSU I have worked with.

Given this understanding, you can see why the resistor between 33 & 36 works, because you are using the
pull up on the Enable# input to bias the Present signal, and that load is in turn pulling Enable# low enough to
operate.re is a fairly tight range of viable

However, in my own supply I will simply be going with a fixed 22K resistor from Present to 12VSB, and a
separate switch between Gnd and Enable#, as that leaves the possibility of software control over the
PMBus.

That now leaves two pins, 34 & 35.

34 = Current Monitor

Based on some testing I think 34 is a current monitor output. I've only tested low currents so far, but I think
the output is around 60mV/A. I'll update this figure once I've tested to full range. If I can't get the PMBus
interface to work, this analog signal will still provide a useful means of monitoring current draw, A 6:1
resistive divider to ground would give 10mV/A, and you could then connect a cheap 0-1V voltmeter module,
ideally with programmable decimal place, to directly display current in A.

35 = PSU status

That leaves 35 as the last pin, and I think it is a PSU status pin, providing a similar indication to the front
panel LED. I'm guessing that it will be multi-level to allow error indications, but don't yet have a clear
mapping, except to say that this pin shows 0V09 when the PSU is plugged in, but not enabled, and 3V2 then
the PSU is enabled.

In terms of current sharing between loads, I'm fairly sure that it is simple "Active Droop", of around 3mV/A.

I am surprised not to see remote voltage sensing (to allow compensation for connector voltage drop),
but given the above assignments there are no obviously spare pins for this function. I have seen in the past
PMBus address setting done via an analog input & resistor value, so if it was going to be anywhere, then I'd
look at pins 28 & 29. Something to explore further next time I remove the PCB from the case.

Finally, I've done some research and believe the matching socket (vertical variant) for the edge connector is
FCI part 10046971-001LF which is available from a number of places including Digikey and Mouser. I have
a couple on order and will report back if they fit properly. If they do, this will mean I can solder the load wires
to the connector and simply plug in the unaltered PSU.
Posted 14th October 2016 by Colin Tregenza Dancer

http://colintd.blogspot.ca/2016/10/hacking-hp-common-slot-power-supplies.html 2017-03-28
Hacking HP Common Slot Power supplies - 12V@100A Page 5 sur 8

Labels: 12V 100A, DL580, Hardware Hacking, HP Common Slot

14 View comments

Unknown 3 February 2017 at 21:48

Hey Colin,

Did you ever get that PS to work correctly, with PMBus functionality? I'm in the process of black-box
testing HP's 500242-001, 2,450 Watt power supplies, for parallel operation. If you could share your
method of determining the PMBus' address lines, as well as SCL and SDA, that would be helpful.

Frode
Reply

Colin Tregenza Dancer 4 February 2017 at 18:08

It's providing 12V 100A nicely but the PMBus element is on the back burner.

In terms of determining function. If you've got a midplane, the wiring there can be very informative,
because you can look for the bussed signals. If not, have a look at the voltages when the PSU is plugged
in but not enabled. The PMBus signals will be pulled up. Looking at where the traces go on the PSU in
relation to the controller chip can also be helpful.

Finally, see if you can find a datasheet for a compatible PSU module (see my later posts), because that
can tell you everything.
Reply

Dr.Tune 15 March 2017 at 22:54

The I2C is at 4.8v but has a very weak pullup (0.2ma flows to gnd when pulled down) so I just hooked it
directly to my (3v3 input) linux SBC (in this case an OrangePi One) knowing that only a very small
amount of current would flow through the input protection diodes on the linux SOC; 75uA - thus avoiding
bothering with level shifting it; works fine. "i2cdetect" sees an I2C device on address 0x58 (7 bit
addressing). Yay ok now to poke at it some more. Thanks for your info! Pin 31 is SDA, 32 is SCL. Cheers!
Reply

Dr.Tune 17 March 2017 at 02:14

..continuing.. PSU NACK's I2C requests initially, then I pulled up the PRESENT pin (36) to 12v (37) with a
20k resistor and shorted ADDR (27) to GND and it moved address to 0x5B (0xB6 in alternate I2C
address parlance) and is now ACKing reads (although returning 0x55 0xaa on every address). There
appears to be no EEPROM in there. Ok more poking, looking for meaningful data i/o..
Reply

Replies

Colin Tregenza Dancer 17 March 2017 at 09:37

I don't know if you saw the docs I referenced in one of the other posts?

http://pmbus.org/Assets/Present/Using_The_PMBus_20051012.pdf
http://pmbus.org/Assets/PDFS/Public/PMBus_Specification_Part_I_Rev_1-1_20070205.pdf
http://pmbus.org/Assets/PDFS/Public/PMBus_Specification_Part_II_Rev_1-1_20070205.pdf

http://colintd.blogspot.ca/2016/10/hacking-hp-common-slot-power-supplies.html 2017-03-28
Hacking HP Common Slot Power supplies - 12V@100A Page 6 sur 8

You might also find this code useful

https://github.com/groeck/pmbus

Dr.Tune 17 March 2017 at 23:56

yeah it's not looking good so far; I have SMBus comms working fine but the damn power
supply will only spit out "0x55aa" in reply to anything at all; I've tried selecting all the PMBus
pages, tried every command, read every location, etc; it just spits back the same response for
everything, never any variation on it. I'm starting to think that the firmware in the PIC inside
these PSUs doesn't have PMBus implemented/enabled.. which would suck.
I'm reasonably sure I know what I'm doing (I do embedded systems stuff professionally); I
looked at the i2c on a logic analyzer etc. It's responding (i.e. ACKing the transfer) but all it
says is what is fairly obviously a test pattern. :-( Running out of things to try; I did look at the
PMBus spec, and I also tried using the linux PMBus kernel module and none of them are
doing anything interesting apart from fail.
Tried it with the PSU running (+12v output on) and off etc; obviously I connected the
"presence" line; it's driving 12v on the main output fine.

This is a bit of a bummer. The PSU itself is made by Delta ("DPS.."), as it confirms on the PCB
inside (Delta logo). They certainly do make PMBus capable supplies (although there's almost
no public docs from them) but my guess is that this supply (which was never used; came in
factory wrapping) simply doesn't have PMBus support. Shrug. Can't find any HP Proliant
GL380 G5 docs either, so can't confirm if they actually require the common slot socket to have
working PMBus.
The linux kernel driver does claim to have supports for the DPS-{other models} which is just a
slight workaround tweak to the standard PMBus support; so far I can get nothing interesting
out of the supply on my desk at all.
I suspect the firmware in the PIC controller literally has PMBus commented out and replaced
with a simple "just return 0xaa,0x55 to everything". I don't have any other PMBus supplies
here to verify, but it's not looking good. :-(
Shame!

Dr.Tune 18 March 2017 at 00:26

It's one hell of a good power supply though, I'll give it that. DAMMIT I wanted full PMBus
monitoring...

Dr.Tune 20 March 2017 at 09:37

Hm opened one up (I have two) and it definitely has a 24C02 EEPROM connected to the I2C
(PMbus) bus pins in addition to a PIC 16F886 (as I had expected). This is odd because I could
only detect one device on the i2c bus; this indicates I may have done something wrong so
perhaps there is some hope... will re-check my stuff

Dr.Tune 20 March 2017 at 22:20

Ok much more hackery. I pulled it apart and powered up just the main logic board with
external 5v (too scary to have the whole thing turned on when open on my desk, frankly;
there's a terrifying high-side capacitor in there)
1) The pins 27..29 are the low 3 i2c address bits in digital form (not analog) all 0 means the
24C02 eeprom appears at 0x50 (=0xa0) up to 0x57 if all 1s (all 1s is default, i.e. has pullups
internally)
2) The CPU in there (well there's two, but one is just for the high-voltage side processing, one
is for low voltage, separated with optoisolators) is PIC16F866 CPU - that didn't have the code

http://colintd.blogspot.ca/2016/10/hacking-hp-common-slot-power-supplies.html 2017-03-28
Hacking HP Common Slot Power supplies - 12V@100A Page 7 sur 8

protect bit set so I read and disassembled it :-) - which also on the I2C bus at 0x58 upwards
depending on the 3 address select bits).
3) The EEPROM contents includes the ascii "441830-001 .. 10/10/08 .. DELTA HP PROLIANT
SERVER PS 437572-B21 01 5AMJQ0D4D4H2Q7" (the last number is same as "CT" printed
on the case label)

Still no luck talking PMBus to the PIC but I've got a lot further. Here's hoping... It's only got 8k
of flash though. Later DPS-xxx power supplies use a dsPIC and have much larger firmware (I
found an update file on a Lenovo site)

Dr.Tune 20 March 2017 at 23:27

Ah ha... am disassembling the I2C handler in the PIC. There's clearly enough code there to be
doing something useful - certainly more than I've yet managed to coax it into doing from the
outside... There may be hope yet...

Frode 23 March 2017 at 19:27

Excellent information, Dr. Tune! Thanks for sharing with the rest of us here. I lack your
experience dealing with these types of embedded systems, but expect to start testing my PS
following the same discovery process you've outlined.

Dr.Tune 24 March 2017 at 03:30

Ok cool I've disassembled the i2c handler in the CPU and figured out the i2c protocol (to some
degree) and have the psu talking stuff (more than it did before) - more news as we have it. It's
definitely not PMBus, it's a home-grown protocol.

Dr.Tune 25 March 2017 at 00:16

Sweeeeeet... here's output of my test rig; (am figuring out register usages)..

01 0202 514 514 514 (0) 514.000 FLAGS

02 0000 0 0 0 (0) 0.000
03 0000 0 0 0 (0) 0.000
04 0eff 3839 3839 3839 (0) 119.969 ?INPUT_VOLTAGE
05 0005 5 5 5 (0) 0.050 AMPS_IN
06 0032 50 50 50 (0) 50.000 ?pwr3
07 0000 0 0 0 (0) 0.000 OUTPUT_VOLTAGE
08 0000 0 0 0 (0) 0.000 AMPS_OUT
09 0000 0 0 0 (0) 0.000 ?v3
0a 0000 0 0 0 (0) 0.000
0b 0000 0 0 0 (0) 0.000
0c 0000 0 0 0 (0) 0.000
0d 07c0 1984 1984 1984 (0) 19.840 ?TEMP1_INTAKE_CELCIUS
0e 08c0 2240 2240 2304 (64) 22.400 ?TEMP2_INTERNAL_CELCIUS
0f 0d98 3480 3480 3480 (0) 3480.000 FAN_SPEED_RPM
10 0000 0 0 0 (0) 0.000
11 0000 0 0 0 (0) 0.000
12 0000 0 0 0 (0) 0.000
13 0000 0 0 0 (0) 0.000
14 0000 0 0 0 (0) 0.000
15 0000 0 0 0 (0) 0.000
16 3c40 15424 15424 15424 (0) 15424.000
17 0010 16 16 16 (0) 16.000
18 5320 21280 21280 21280 (0) 21280.000

http://colintd.blogspot.ca/2016/10/hacking-hp-common-slot-power-supplies.html 2017-03-28
Hacking HP Common Slot Power supplies - 12V@100A Page 8 sur 8

19 0032 50 50 50 (0) 50.000

1a 001b 27 27 27 (0) 27.000 ?flags
1b 0000 0 0 0 (0) 0.000 ?voltage
1c 0000 0 0 0 (0) 0.000

..so remaining is to finish figuring out the most useful readable registers (which include all the
good stuff you'd expect) and figure out the writing stuff (mainly just turn on/off in software).

Nice! That was fun. I'll post python (+commented disassembly of the PIC CPU) on Github in a
day or three...

Dr.Tune 27 March 2017 at 23:03

Here you go;

Have not figured out how to turn the output on/off yet (may not be possible); there are some
writable registers (see python code) but they appear to mostly control fan speed/temp
thresholds and (perhaps) under/over voltage limits.

Python code here (and disassembly of the CPU firmware in the power supply etc)..
https://github.com/raplin/DPS-1200FB

That should be enough to get anyone going.

Enjoy!

Reply




Comment as: Unknown (Goo  Sign out

Publish Preview Notify me

http://colintd.blogspot.ca/2016/10/hacking-hp-common-slot-power-supplies.html 2017-03-28