SSC-32 Custom Firmware

well i think ive fixed the ramdom boot lock up

ive advanced into my sentinel build which can now run autonomously… and first thing ive noticed is that the ssc-32 did what Xueys described(driven by a pocket pc)
so this gave me a platform to work with the problem as the problem seem to not occur on my PC.

and for the moment, the problem didnt show up and the ssc-32 as booted everytime
but the problem remain unknow yet :confused:
and that seem to not be related to the code itself… seem like it depend how the compiler feel… somehow … :S

anyways… heres the v0.2

this new version introduce the reversible PWM outputs
which is a very nice feature that allow to drive any output channel in reverse

its been already usefull in my little rover which is driven by 2 parallax CR servo
by reversing the channel at the ssc32 level this allow me to drive the rover foward and reverse using 1 single value

ive also made a change/fix in the time calcul which now give a much better resolution with the extended time units (cs, ds, sec)

here the test results for timed command

MS : 65535 / 65.535 sec
CS : 65535 / 10 min 55 sec
DS : 65535 / 1h 49 min
SEC : 32767 / 9h 36min

so… ms, cs, ds offer full range
ive not tested sec over 32767… as sitting there for minutes whatching a number go from 1500 to 1449 is not so fun

well, so far this release as been stable… but time will tell i guess

new release, v0.21

finaly figured what was the problem

was an emtpy source/header file that messed up the compiler

in the v0.2 ive somewhat cheated as i didnt find the bug, so what i did is lower the optimization level which did build a rom that didnt lockup

however… ive had 2 times where the ssc32 did act weirdly after a power cycle.
things when nuts for a sec or so… then catched up with the datas that was sent

the difference bewteen the same code/config but the empty files removed was ~ 600 byte
which is really suspicious… really wonder what was these 600 bytes or so added to the output file

anyways… after removing the empty files the firmware started to act as it should ever had…
and thats the only thing that really matter

new release is stable… over 100 power cycles without 1 single glitch or weird behavior

ive also updated the protocol doc and put up a new terminal release even if i think ive made no change… just to be sure.

ive put up a new terminal… fixed a small bug related to speed

hum… long time ive not posted here.

ive finaly had sometime to finish off the next release.
kinda lost interest after getting that “bug” again on my PPC when i tought that i had fixed the problem in the 0.2 and 0.21 release
i also had to move into more urgent projects :confused:

but couple months ago ive managed to find the real problem
turn out it was not even a bug in the firmware but a buggy hardware/driver of my PPC.

on my desktop the firmware as always worked perfectly…
but as soon as i tryed to use the ssc-32 with my PPCs things started to go totaly wrong and had weird behaviors

well… i finaly found out that my PPC will actualy send garbage datas as soon as i call fopen(…)
and of course, that is not suposed to happend… function like purge and clear comm are totaly useless as they can only be called after getting a handle to the com port
which is given by the fopen function.

so… once the ssc-32 receive the garbage datas, the protocol goes out of sync and things get messed up…
when such thing happend the ssc-32 become really instable and can even lock up.
but sometime the protocol goes back in sync after a couple of commands
and thats where all the confusion came from.

of course that was to be expected since the firmware protocol is very strict w/o any security such as CRC or any other way to detect bad command or garbage.

there not much i can do about that due to the design of the protocol.
ive favored the speed of transfer and execution time over the security

what i didnt expect though was to get garbage datas from a call such as fopen :S

so… basicaly what that mean is if you have a solid communication system, the firmware will work as expected.
but if the communication system is bad and it throw unexpected datas for some reasons…
then the protocol as a good chance to go out of sync.

same thing will happend if the user does not handle the protocol properly.

as for the new release…

ive fully implemented the input modes digital, latch low and latch hi
if i remember well, the prior versions only had mode analog and latch available… and latch was not even functional

some change/fix been made to the get_device_info command

and i have removed the set_output_pwm_s as this was getting confuse and the function was useless anyways

also made a major rework of the protocol document in hope to make things cleaner and easier to understand.

files are available in the first post.
check the release.txt for more infos on the fixs/changes

Hello,

How CAN i put this new firmware on my ssc32?

Thanks

If you purchased your SSC-32 in the last ~year and a half, the firmware you have should be fine. If you really wanted to upgrade the firmware, you would need to re-flash the ATMega chip. Question is, why do you want to change?

hello this link with firmware no work, from which you can download; I have the 2.02Gp and I could not spend some of the link of lynxmotion

The latest firmware can be found here:
lynxmotion.com/p-395-ssc-32- … oller.aspx
Can you indicate why you want to upgrade the firmware?

Yes, i have a hexapod Robot, and now i close the binary protocol, but cant upgrade.
http://www.lynxmotion.net/download/file.php?mode=view&id=4223&sid=5b1bfa0f3f14b2f67124413318e5f89d, i chech the speed jumber, and i power but i cant upgrade, made i can with FTDI adaptor?

Not enough info to see why it failed. Things to check:
a) Power - Is the battery charged?
b) Serial configuration: upgrade only works at the baud rate of 115200. Is the board and software configured to this?

Note: The hexapod/quadapod code bases up on the Lynxmotion github are configured to use the newer EGP versions of the firmware. It was done awhile ago (2 years?) with the understanding that the new default firmware would be updated to one of these, which never happened. Suggest at this point update github version to turn off binary mode.

Kurt

hello Kurte

I have problems with movement in some leg, when the body is low, a few feet move faster upwards, and they make one greater move. If you upload the body a little upwards working properly, mabe fix with firmware upgradE?

@GIANNHSitia Which version of the firmware you trying to upload? 2-07EGP_A1A.abl?

Seems like the upload isn’t working at all: 0x3500 is the first address that would be programmed/checked. Can you still type VER to get the version information? What version do you see?

Like Kurt said, let us know if you are using a charged battery and if you are using the 115200 baud rate.

yes 2-07EGP_A1A.abl… I have tried all the version. my firmware is this in photo. i using 115200 and lipo battery 7.4. no other way I do upgrades; mabe isp programmer?


Maybe would help if you show a picture of your SSC-32.

my ssc32 is in my hexapod :S

Are you connected directly to the SSC-32 with a serial cable, or are you using bluetooth? If you are using bluetooth, you might not actually be using 115,200…

Can you try doing the firmware update with the SSC-32 Servo Sequencer Utility?

I failed to upgrade nor with self,at the beginning of my finds ssc32, com2 115200, i can move the servo, but when I go I upgrade, selected firmware and after I drew that. i have programmer mabe find the firmware to hex version?

I’m not sure I understand your answer. For programming the firmware, we usually recommend connected your computer directly to the SSC-32 with a serial cable.

Is this firmware or something similar available still? The links in this thread point to a defunct website.
Thanks!

Hi,

These firmwares are for the old SSC-32 (now discontinued), not the SSC-32U.

You can find archived versions of the SSC-32 firmware binaries here. Please note that those firmware versions are for the older/discontinued SSC-32, not the SSC-32U and are not compatible.

The SSC-32U ships with the firmware version 2.50USB already installed, which is the most up-to-date version available for the SSC-32U.

Sincerely,