I fully charged the two Lithium-ion battery banks (around 8.4 volts in series), but the BLDC problem that I mentioned in my previous log entry still occurred, so I wrote up a small amount of Python and C code to create a new XMPP command called "bldctest [testnumber]" so that I could activate the coils in different polarities for 2-second periods to troubleshoot.  Testnumber 1 is +U -V, 11 is -U +V, 2 is +U -W, 22 is -U +W, 3 is +V -W, and 33 is -V +W.

I was then able to connect my multimeter to read the voltages at BLDC coil terminals U, V, and W and text the appropriate command to see what was going on.  It was soon apparent that the U coil wasn't working, and it was indeed only running on only 2 phases, as I surmised.  I tracked it down to a bad solder joint on the U coil L6234 enable pin (EN1 in this case) that was only receiving .5 volts instead of the full 5-volt logic coming out of the ATtiny 1634 (which I have running at 5 volts), which was too low to activate the L6234 logic gates/MOSFETs.  So I reheated the joint to correct the issue, and the Gyrofan is once again operational.  Thankfully, there doesn't appear to be any damage to the L6234 or the ATtiny...

Whew!

To ensure that this chip lock-up issue doesn't occur under intermittent solar power and burn out the motor again, I turned on brown-out detection on both ATtiny 1634's and set the threshold to 4.3 volts.  If the voltage drops below 4.3 volts (or 4.1 volts minimum) the chip will go into reset mode until the voltage is restored.  These ATtinys can operate at lower voltages, but since they should only be receiving power from my solar charger's 5v USB output (or via a 5v USB bypass line in test mode), I set the threshold fairly high.  This ensures that the solar charger output has at least ramped up to operating voltage and should be more stable.  If the high-current motor PWM drops this voltage below the threshold and resets the chips, I may try lowering it to 2.7 volts, but I'm hoping that my bypass capacitors will handle it and this won't be necessary.

First, I set the High Fuse Byte to DC (11011100) to enable a BOD trigger level of 4.3 volts (typical):

sudo avrdude -pt1634 -c linuxgpio -U hfuse:w:0xDC:m -C avrdude-sawyer.conf
sudo avrdude -pt1634 -c linuxgpio -U hfuse:w:0xDC:m -C avrdude-huckleberry.conf

Next, I set the Extended Fuse Byte to F5 (11110101) to enable Active, Idle, and Sleep Mode Brown Out Detection:

sudo avrdude -pt1634 -c linuxgpio -U efuse:w:0xF5:m -C avrdude-sawyer.conf
sudo avrdude -pt1634 -c linuxgpio -U efuse:w:0xF5:m -C avrdude-huckleberry.conf

Since both AVRs, Sawyer and Huckleberry, share the same SPI programming lines except for their reset lines, I use two custom avrdude.conf files to program each chip, with only their reset lines differing between the files.

Also note that there are two bugs in the latest released 6.3 version of AVRDUDE that have to be fixed before it will correctly program the ATtiny 1634:

http://savannah.nongnu.org/bugs/?40144
http://savannah.nongnu.org/bugs/?47550

And AVRDUDE has to be compiled with the --enable-linuxgpio=yes option for bitbang support.  I use Arch Linux, so I just use the Arch Build System to make the corrections in the source and then recompile (and then I also edit the avrdude.conf file to add the other bug fix to the ATtiny1634 section).

All TRILLSAT-1 hardware is now operational again.