PiSupply Project: Debugging the First Revision
The first set of boards for the pisupply controller (SYN001A) and power supply modules (SYN002A) arrived last week. I assembled one of each and began testing by probing out most of the power traces to ensure that it wasn't going to catch fire immediately upon being powered up. Once I was confident that nothing was too out of place, I applied 12V from my bench supply.
I tested the simpler power supply module first and was surprised to find that it worked flawlessly. The Murata modules worked great and supplied a clean 5V on the output with anywhere from 8V to 14V on the input. There's a ~32 KHz fluctuation on the output at 72 mV peak-to-peak with a 2 watt load. This is well within the USB 2.0 spec's 330 mV peak-to-peak maximum. I could probably filter this noise out even further with another capacitor or two, but that seems unnecessary.
The control board is essentially a copy of the power supply module with a RaspberryPI header, I2C EEPROM, and 74HC595 shift register. This board came up relatively smoothly without a RaspberryPI connected, but when I connected the RaspberryPI it started resetting itself every few microseconds. Clearly this indicates that something is shorting. While I'm not 100% certain, I believe a couple of the pins on the RaspberryPI header got connected to GND mistakenly in the schematic, causing the 3.3v supply to short immediately. The good news is that the short circuit protection works great!
I was able to continue testing by connecting individual pins of the RaspberryPI to the control board with jumper wires. The I2C EEPROM seems to be working as intended, with it's 3.3v supply coming from the RaspberryPI's regulator. I still haven't got a working device tree overlay for the drivers I'm writing, but I was able to do a few write/read cycles over I2C successfully.
The shift register also worked once I got the pins connected correctly (I miscounted a couple times). The only behavior I don't like here is that the shift register's initial state is to let all outputs go into a high impedance state, which allows the connected power modules to use their internal pulldown to start in the enabled state. This means that there would be a large surge of inrush current when the control board is first connected. This isn't exactly a huge problem, but it's not the behavior I'd like to see.
As I'd guessed, I had connected the clock and latch pins of the shift register incorrectly, so on every clock, all of the outputs will be updated, not just when I want them to latch after the eighth clock. The solution here is to connect each clock separately to the RaspberryPI, or add a counter that would trigger the latch after eight clocks. Not a huge surprise.
There are a few additional changes I'd like to make, such as labelling the positive side of the VIN pads and adding a few more test points to make things a little easier to debug. I've started thinking that some shunts for sensing the current on each output port would be nice to have too.
I've also realized that all of the issues I'm having with the shift register would be trivial to solve if I used a small microcontroller instead. A PIC or 8051 variant would only add about $0.30 to the cost of each control board. I could interface the uC with the RaspberryPI with SPI, I2C, or even USB if I wanted to add a few more components. Switching to a USB interface rather than the RaspberryPI 40 pin connector would allow me to eliminate the ID EEPROM and pin header, making the board about the same cost as it is now, while getting more functionality and a more portable interface.
I'm going to spend a week or two toying with ideas for a second revision of the control board (SYN001B) using a microcontroller.