Hey guys, Beth added me in here so that I could discuss the SSC-32 firmware update process with you. I’m ready to begin working on the EEPROM and the GP player however I need to update the firmware on the couple of boards sitting on my desk to the GP firmware. I would like to attempt to create a flowstone based update program but there’s nothing in the manuals on how the update process actually works. I was hoping someone could clue me in?
Sounds like a question for Mike,
I don’t have any of the sources for the bootloader or for Lynxterm or the like, so I am not sure what sequences are used to get into the downloader code. The other person who may be able to help is Laureatus, as he may have source code that went into Lynxterm or Seq that has the code to do the actual downloading.
Kurt
Devon,
I’ll start by digging up the info I sent to Laurent way back when and posting it here. You can try using the bootloader manually with the following steps:
- Use a terminal program that can download ASCII text files, such as Windows hyperterm. Set the SSC-32 and the terminal program to 115.2 kBuad. You might have to play with settings such as echo to get things to display correctly.
- Send the “VER” command to confirm the current firmware version.
- Send the GOBOOT command to put the SSC-32 into bootloader mode.
- Verify that it is in bootloader mode. “r0000” will read the first page of memory, which will be a bunch of hex digits. “v” will return the bootloader version, currently 2. (All commands to the bootloader are lower case; all hex digits are upper case if alphabetic.)
- Read the first line of the .abl file with the firmware. It will have the new version number.
- Use the terminal program to send the .abl file to the SSC-32 as a text file. The .abl file consists of a bunch of erase commands to erase all of the pages of memory (in the form “e0000”, etc.), a bunch of write commands to write new data (“w0000” followed by lines of hex data), and lines of ‘.’ characters. The ‘.’ characters are just there to waste time while the SSC-32 carries out the erase or write operation.
- When the transfer is complete, the new firmware is installed. I have never seen this fail with a wired connection, but it sometimes fails with wireless.
- Send the command “g0000” to start the new application running. This command says to start running at address 0000. g=GO
- Send the “VER” command to verify the new firmware version.
What you are interested in doing is automating this process. There are a few complications:
- If the current firmware is corrupted, then it is necessary to use a jumper across the Baud pins to recover;
- After the firmware has been programmed, you can read it back to verify;
- The process can be sped up by not transmitting the lines of ‘.’ characters, and instead waiting for the SSC-32 to reply with a ‘.’ indicating the command is complete.
I’ll follow up with more detailed information.
Mike
The problem I see is sending the actual firmware file through flowstone. Flowstone is only capable of sending strings of bytes, not simply a single complex file. Flowstone would, as a guess, import the file and send it out as a string if the SSC-32 would be able to accept that.
I think the abl file is just a long string of bytes. 
Yes, you would need to read the file in as a big string (or collection of strings, one per line) and send the string(s) to the serial port. That’s what a terminal program does under the covers, and what LynxTerm does as well.
Mike
Thanks for the info mike, i’ll have to try loading the firmware into flowstone and see what happens. I’m assuming that the most reliable method would be to make the program wait for the … response after each line?
mike,
I can’t seem to get the data from the SSC-32 back inside of flowstone when in boot mode. Do any of the serial options change in bootloader mode? Also i was wondering when you were going to be able to post anymore information?