USB SATA powerswitch
This is the documentation page for the USB SATA powerswitch PCB. The firmware was updated around Nov 2014. If you have yours since longer ago, look here: Old USB-SATA powerswitch
The old firmware used single character commands (s, c), the new version uses "words" (set/clear).
You can buy the USB SATA powerswitch in the BitWizard shop.
The USB SATA powerswitch PCB has an USB connector and connection points for 3 power rails. The brains of the PCB is an at90usb162 (or compatible) chip. The 12V power rail is switched with an IRF9333 FET, and the 5V and 3,3V rails are switched with FDS8884 FETs.
- led1 is connected to VCC
- led2 is connected to PD6
- led3 is connected to PD5
- led4 is connected to PD4
- led5 is connected to PD3
- led6 is connected to PD0 (12V FET)
- led7 is connected to PD1 (5V FET)
- led8 is connected to PD2 (3,3V FET)
- led9 is connected to 12V in
- led10 is connected to 5V in
- led11 is connected to 3,3V in
Viewing with the USB connector on the left side, and the power pads on the lower side:
- 12V IN
- 12V OUT
- 5V IN
- 5V OUT
- 3,3V IN
- 3,3V OUT
The device acts as a usb-serial port, and under Linux, will be available under /dev/ttyACMn (n=0 for the first device, 1 for the second, etc.).
At BitWizard, we use the following script for turning om our harddisks:
#!/bin/sh tty=/dev/ttyACM0 stty -echo -icrnl -onlcr < $tty cat $tty & pid=$! (sleep 0.2; echo set 0 ; sleep 0.2 ; echo set 1 ; sleep 0.2 ; echo set 2 ) > $tty sleep 0.5 kill $pid
"set 0" means "set output zero", which is the 12V output. "set 1" id the 5V output, and "set 2" is the 3V3 output. The four extra status LEDs are connected to output 3,4, 5, and 6. To turn off an output, simply send "clear 0", meaning "clear output zero".
Note that we start with output zero, or the 12V. We have experienced that harddrives will powerdown nicely (i.e. not burn down in flames) when you keep 12V powered and interrupt the 5V supply. So powering up the drive by bringing up the 12V and then the 5V should work. Below you see that John does things the other way around. Apparently that too doesn't cause immidate problems. BitWizard recommends powering up the 12V first, and then the other power rails. But if you want to do otherwise, feel free. Powering down we recomend inverting the powerup sequence. 3.3V first, 5V next, 12V last.
Reading from the device is necessary, because it needs to put its output somewhere. If you don't read it's output, the device may (or will) freeze.
John tells us that he uses the following windows script.
::startsatabat ::port parameters MODE COM3:96,N,8,1 ::For reading info from COM port type COM3 ::For sending info to COM port sleep -m 200 echo set 2 > COM3 sleep -m 200 echo set 1 > COM3 sleep -m 200 echo set 0 > COM3
The "type COM3" line is controversial. I would expect that line to block and the script to stop processing there. On windows, it seems it works fine without it. Then, I think John put the line back, but maybe as "copy com3: con:". Apparently that does not block. Please let us know how your experience is.
The parameters like "baud rate" and parity are ignored in the device. I don't see the need for the "mode com3:96,N,8,1" line. Maybe the act of initializing is neccessary on windows. Or maybe it resets other parameters like is neccessary on Linux. (On Linux the echo needs to be off: otherwise the first character that is echoed from the device back to the PC starts bouncing back and forth between the PC and the device).
The devices are shipped with the following .hex file programmed:
For info on how to flash this .hex into your controller, see the section on programming below.
This section describes how you get your program into the processor.
In general what you need to know is that the processor will boot into the code you programmed into it on powerup. Once you're done developing your program, that's the way you'll use it: Powerup, run.
If there is no program loaded or if you press the reset button the chip comes up in "firmware upload mode". This is done by a bootloader. You should take care not to overwrite or erase the bootloader, because there is no way to put the bootloader back once it is gone.
Get the dfu-programmer for atmel chips package. []
On sufficiently recent Ubutnu distributions that is as simple as:
sudo apt-get install dfu-programmer
I recommend creating a script called "dfu":
#!/bin/sh if [ -z "$CHIP" ] ; then chip=at90usb162 else chip=$CHIP fi hex=$1 sudo dfu-programmer $chip erase sudo dfu-programmer $chip flash --suppress-bootloader-mem $hex sudo dfu-programmer $chip start
TODO: figure out how to get rid of the "sudo" commands here...
Now downloading and starting a program is as simple as pressing the reset button and then:
TODO: When I'm developing, I'm likely to modify the code, and when I want to program the chip I hit the "reset" button on the board. Then the computer will see my chip re-enumerate as the Atmel DFU chip. A simple script could watchout for that and invoke dfu <mycurrentbinary>.hex the moment the chip has enumerated. Once that's running downloading and starting the latest code becomes as simple as hitting the reset button.
Apparently the FLIP program is now available for Linux too. See below.
Get the "flip" program from Atmel. http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3886
The chip is an at90usb162. http://www.atmel.com/dyn/resources/prod_documents/doc7707.pdf
You can program the processor as if it is a normal AVR processor without USB. Just like an arduino. Or you can program it to have USB support. For this the LUFA package is very useful. http://www.fourwalledcubicle.com/LUFA.php
Depending on what you want you can start from these examples:
DONE: Find out if we can jump to the bootloader from our code so that we can issue a "go get yourself updated" command over the USB (yes, but the documentation says nothing about what address to jump to). This comes in handy if the reset button is difficult to reach because the device is built-in somewhere. http://www.atmel.com/dyn/resources/prod_documents/doc7618.pdf
If you want to switch other things than a harddisk, keep in mind that the 12V is switched with a P-fet that is spec-ed for >10V VGS operation. So reducing the 12V to something else is not recommended.
Similarly, the 5V and 3.3V outputs are switched by logic level N-FETS which are driven with their gates to 12V. So for the 5V output the drive on the gate is 7V. As this is a logic-level N-FET, this works just fine. But increase the switched voltage on the 5V line to more than 8V and things become critical.
Future hardware enhancements
- Replace the SMD inductor with an TH version (1.3: Done!)
future software enhancements
- program the LUFA bootloader.
- Moved to screw terminals for the power connections.
- Switched order of 12V pads, so that the input and output are in the same order as the 5V and 3V3 pads.
- replaced the SMD switch with an TH version
- Added mounting holes
- Initial release