-------------------edge of PCB
2 4 6 8 10
1 3 5 7 9
then I think it might have been pins 3 and 6 or even 3+5+6, but again that's a guess since the whole mis-reset happened because I was too quickly trying to reset the board when I really should have just turned off and on the PSU (was trying to keep the other Chili on the same PSU running during the reset). All I know is that the USB comms didn't seem to work after that and so I replaced the FTDI chip and then all seemed pretty normal (once I had reprogrammed the FTDI).
Alright, so now I'm even more confused. I've moved it upstairs to work on it with my laptop (running the same version of Ubuntu as the machine it was on previously), and now it's been running solid for almost 4 hours. A few bfgminer crashes after 10 minutes at first, and now it's solid. I'm reluctant to move it back to where it was, but it's not like it's in a good place.
Anyway, anyone run into this kind of an on-again off-again problem moving from machine to machine? Thoughts?
It seems to reset now (no more comms errors, just bfgminer crashing/stopping though it's solid with other units (chili and other USB miners)). But it does so randomly, between a few minutes to several hours (even up to 12 hrs as the longest so far). No raise/lower in GH/s, getting a solid 34-35 GH/s depending on pool and no noticeable change right before crashing.
Are there some test points I can measure while it's hashing that could help now that it's no longer got comms errors but instead leads to bfgminer crashes?
BTW, I can "make" it crash bfgminer by bumping the table it's on or moving it. Must be a loose connection somewhere? (maybe USB port/cable? Will try a different cable tonight).