I have completed all the steps in the “complete phoenix tutoral” and when I turn on my robot the PS2 reciever lights blink for a second and then when I turn on the PS2 controler, both Reciever lights stay on. The Botboard II green light is on steady. But the SSC-32 Green light is Blinking (is this right?).
Otherwise the PS2 does not seems to activate the robot… and it does not move the legs to the start positions.
Any clues?
Did you press the start button?
Read the text at the top of the program file, it has the functions of the keys.
Alan KM6VV
Yes… Many times…
The ssc led will stay on steady when power is applied. Once the board recieves a signal it will flash and go out. Then when it receives a signal it should just flash. Does the led respond just to the controller or is it constantly flashing? Check the tx/rx bi-connection between the two boards. Are you connecting to pin 8 or 10,11?
Because the SSC-32 LED is blinking it means you should be on the right pins on the Bot Board II. The problem could be servo power. Do you have 6vdc going to the servos? Have you verified this?
Thanks for the tips… yes I’ve tripple checked all connections. I will try a different 6v bat later…but it worked during the offset and calibration procedure.
If you failed to configure the SSC-32 for the proper baud rate the LED will still blink, but the data will be corrupt.
Well… Now you’ll all know the symptoms for when you load the Phoenix 2.0 program into Basic Atom, where the SSC-32 (V2) was set-up without upgading firmware. 
That’s right, somehow I followed steps 1 thru 10 (therby skipping to step 5) in this tutoral lynxmotion.com/images/html/build139.htm and then finished the project using this tutoral… lynxmotion.com/images/html/build159.htm …I was using Basic Atom IDE and Phoenix2.0 requires Basic Micro Studio…
So I loaded up Phoenix1.3.bas and everythings perfecto now…
Later I’ll startover and upgrade to 2.04GP Beta firmware, Basic Micro Studio, and try loading Phoenix2.0.
Thanks for the help…and really cool robot!
great to see you have sorted it. yes, a very cool robot indeed. 8)
look forward to seeing it walk. Well done. 
phoenix_V20.prj does not compile…
Any suggestions? I’m getting this error using Basic Micro Studio…
Error: FILE C:\USERS\ALAMO\DOWNLOADS\PHOE2PS2\PHOENIX_V20.BAS(LINE 1071) : [TOKEN INC] : Redefining to VAR
Referenced Line 1071 in code…in bold below…
;[Handle TimerW interrupt]
BEGINASMSUB
HANDLE_TIMERW
push.w r1 ; save away register we will use
bclr #7,@TSRW:8 ; clear the overflow bit in the Timer status word
mov.w @WTIMERWOVERFLOWCNT:16,r1 ; We will increment the word that is the highword for a clock timer
** inc.w #1,r1**
mov.w r1, @WTIMERWOVERFLOWCNT:16
pop.w r1 ; restore our registers
rte ; and return
return
ENDASMSUB
Yep that has been reported and fixed a few times…
The compiler changed and it now at times confuses some of the inline assembly code with basic code words…
;[Handle TimerW interrupt]
BEGINASMSUB
HANDLE_TIMERW
ASM{
push.w r1 ; save away register we will use
bclr #7,@TSRW:8 ; clear the overflow bit in the Timer status word
mov.w @WTIMERWOVERFLOWCNT:16,r1 ; We will increment the word that is the highword for a clock timer
inc.w #1,r1
mov.w r1, @WTIMERWOVERFLOWCNT:16
pop.w r1 ; restore our registers
rte ; and return
}
return
ENDASMSUB
I believe the above should fix it… The ASM { } pair tells the compiler that treat this as raw assembly language code…
Kurt
Perfect…Thanks!
Can you point me to more info about assembly code?
Alan
There is stuff about this scattered in several different posts, including: viewtopic.php?f=4&t=3347
Basically you can put in-line assembly code anywhere. If the assembly code is not contained in: BEGINASMSUB/ENDASMSUB, the compiler will add code to get you in and out of assembly language. Having the compiler do this for you is great. In that mode you are free to trash most of the main registers: er0-er5. The places you don’t want this are places where you can code up your own assembly language interrupt handler such as the one you included in this post. In these cases you must preserve the registers you use, which is why you see the push.w r1 at the start of the function and and the end a pop.w r1…
Your assembly language code can address variables that you defined in basic. However you need to fully uppercase the variable in the assembly language code as the basic compiler does this and the assembly language code is case sensitive… As for learning about the actual language, I did this by using the H8 hardware manuals that you get to from the help menu of the IDE. The Bap28 uses the H8/3694 and the Bap40/Arc32 use the H8/3687. I use these reference manuals often. For example in the code you had problems with, this is for a timer (timerw). In Section 12 of the 3694 manual you can see what hardware registers do. For example the instruction: bclr #7, @TSRW:8
Instruction clears bit 7 of the TSRW register, which if you look is the overflow flag…
Good luck
Kurt
I just downloaded the same code and had the same problem with the blinking light on my robot SSC. I’m all connections are check and servos are working and powered, but updating the firmware ( or down-dating) didn’t solve the problem here. I kinda ran out of ideas to troubleshoot, am i missing something ?
PS: i used to have a different hexapod code that used to work in terms of communication.i just switched to xan code.
All help appreciated. 
Need Info:
What version of Xan’s code. What Robot, What Controller (BAP? Botboarduino?) Wiring? Battery… If you run the code does the LED on the SSC-32 flash? If not check that the right IO pins are used. If so but still nothing? What baud rate is the code configured for? What Baud rate is the SSC-32 configured for? What version of firmware is on the SSC-32? Is this a version of Xans code that uses binary mode? If so is the version of the firmware that is installed one that handles this?
Kurt
Im using “BlackWido IK for PS2 control (v2.0) (Nov 09, 2009)” from here. The robot is a quadruped, custom made from brackets and aluminum plate body. it’s controlled with BAP and SSC wired as follows :
From the SSC to the BAP, the Tx is connected to pin 10 and Rx to pin 11
The battery is “6.0 Volt Ni-MH 2800mAh Battery Pack”. When switched on i hear the speaker tune then the “D1” led on the SSC starts blinking constantly. The code is configured at 38400 baud rate, i set the SSC baud jumpers to that value but no luck. I also tried changing the code baud rate to 115200 and settign the ssc to that value, the results were the same.
I’m currently using the latest firmware “2-07EGP_A1A.abl” but i also tried the oldest “2-01XE.abl”. Im not sure if xan’s code uses binary but the firmware can handle binary according to it description.
The PS2 controller is connected properly (tested using terminal).
Sounds like you have things configured well. If it were me, I would probably try using a more recent Phoenix code base for this, as I am more familiar with it. I have not checked lately what Lynxmotion has up on their Github or other locations. So awhile ago, I put my stuff up on my github account. github.com/KurtE/Phoenix_For_BAPS
Looks like you tried most of the obvious things. Again in cases like this, I would start to do some simple debugging. To localize down what is not working.
Sounds like you tested that the PS2 was working.
Next I would write a simple program, that told all of the servos to go their center position, to see if the two boards are talking and the servos are working…
Actually if it were me, I would hook up a logic Analyzer to what is going out on the Tx/Rx pins and verify what I think it should be. (But that’s cheating )
Next up, I would start to sprinkle debug code in the code, that did things like print stuff out on the debug terminal, and/or use the LEDS. Note, the LEDS are on the same IO line that you hook up the PS2… On BB2 12-15. What I have done (leaned from Xan), was to unplug the PS2 jumpers on the board. And I use a 3 pin servo extension wire and plug one end into the 3 led Pin (the 5 pin group, pins closest to the LEDS), and plug the other end into 3 data lines (like 4-6). Then you can toggle these IO pins to check things. Like I will often put one in the code that does the output to the SSC-32. That way if I see it flashing I know the code is going through that point…
Question are you using an old ABB board like you show in the picture and not the newer BB2? If so the PS2 IO pins are on different on this board, like pins 4-7 and most code assumes 12-15.
Not sure what else yet. Note: I am real rusty with Baps. None of my current projects are using them and I am spending majority of time on Arduino and embeded Linux boxes (Raspberry Pi, Beagle Bone Black, Odroid U2). But will try to answer questions.
Good Luck
In addition to kurte’s answer, check to see that you are using the correct Tx / Rx pins on the SSC-32 (send an image if you can).
Good news!,I used a program kurte wrote to me in an older thread to check the servos:
[code]cSSC_OUT con P11 ;Output pin for (SSC32 RX) on BotBoard (Yellow)
cSSC_IN con P10 ;Input pin for (SSC32 TX) on BotBoard (Blue)
cSSC_BAUD con i115200 ;SSC32 BAUD rate 115200 require the Studio version 2.0.0.7 or later
leg var byte
pos var word
main:
gosub AllLegs1500
for leg = 0 to 31
gosub WiggleLeg[leg]
next
DoNothing:
goto DoNothing
goto main
AllLegs1500:
for leg = 0 to 31
serout cSSC_OUT, cSSC_BAUD, “#”, dec leg, “P1500”, 13]
next
return
WiggleLeg[leg]:
serout S_OUT, i9600, "Wiggle Servo: ", dec leg, 13]
for pos = 1500 to 1800 step 50
serout cSSC_OUT, cSSC_BAUD, "#", dec leg, "P", dec pos, "T250", 13]
pause 250
next
for pos = 1800 to 1200 step -50
serout cSSC_OUT, cSSC_BAUD, "#", dec leg, "P", dec pos, "T250", 13]
pause 250
next
serout cSSC_OUT, cSSC_BAUD, "#", dec leg, "P1500T250", 13]
return
[/code]
Everything went as planned, all servos are working and the program is operating at 115200 baud rate. I’ll try using debug messages on the terminal to see where xan’s code get stuck
Edit: In order not to take this thread off it’s topic, i’ll continue the debugging news on my thread here