When I connect my SSC-32 to my PC, activate LynxTerm, and then apply power I am presented, in LynxTerm, with a bunch of ASCII characters. Furthermore issuing commands does not have any effect and attempting to update the firmware fails (even when using jumper mode).
I did not have this problem until last night. At that time I had my SSC-32 and BotBoard II configured as described in image 4 of the SSC-32 Power Options post (lynxmotion.net/viewtopic.php … sc&start=0). While attempting to program the BAP I bumped the bot resulting in an arc at power terminal VS2 (the terminal that powers ports 16 - 31) on the SSC-32. The result was some melted wires and a damaged VS2 terminal. However I do not see any burn marks on the board itself. Using my onboard battery checker I can tell that everything is receiving power by shorting VS1, VS2, and VL and then applying power to VS1 or VL. I suspect something has happened to the atmega.
I’m looking for advice for recovering from this little accident. I would like to be able to identify the problem and repair it (assuming of course that it can be repaired).
The melted wires sounds like a result of the wires not making it inside the screw terminals properly. There should be no damage to the SSC-32 functionality.
To help with the com problem you will have to provide more information. USB or serial cable, baudrate, green LED status, etc. BTW it is a really really bad idea to try and upgrade the firmware as part of a serial com troubleshooting effort. I mean c’mon…
You are correct. The wires were not well seated. I was using 18 gauge stranded which doesn’t fit into the terminals well. I plan to rectify that problem by switching to 20 or 22 gauge stranded once I’ve confirmed that it can handle the current/voltage (and once I have my replacement board of course ;] ).
I am using a USB/serial converter that has worked just fine to date. The baud rate is set to 115.2k. The power LED does come on but it does not go out as expected when I connect with LynxTerm.
As for upgrading firmware as part of serial com troubleshooting. Generally speaking I would agree but given that everything worked fine before my little accident and now not so much I don’t believe the problem to be a com issue but a hardware issue (i.e. I think I damaged my chip). I just want to be sure before I replace it. To that end are there any diagnostic functions that I can I run to validate the SSC-32 is receiving my commands (e.g. a simple ping). I tried issuing a servo move command but that was fruitless.
The best quick test is to connect to LynxTerm. While all of the programs we offer use the same com port code, the LynxTerm application does not have the high speed bidirectional requirements that RIOS has.
Just connect and type VER. The SSC-32 should return the firmware version to the screen. You can also do the short pins 2 and 3 on the DB9 end of the USB cable to see if the characters are echoed on the screen. There should be two of each typed characters on the screen for this test.
No response from the VER command. However shorting pins 2 and 3 does result in the same character appearing twice in the LynxTerm terminal. I think that tells us that the cable is working and that the board is not responding. Would you agree?
The baud jumpers are oriented correctly (i.e. vertically with respect to the atmega). However in checking that I noticed that I had not shorted the TX and RX lines. I’m back in business! Now I just need to replace that damaged terminal
Great news! I have done this myself a few times. Just got to remember when switching from PC coms to TTL coms, you have to remember to install or remove the 3 jumpers. Baud,Tx, and Rx jumpers.
