SX-Key

Comprehensive In-circuit Development System for Ubicom SX uC's

• Product Brief
• Manual, latest version of the software from sxtech web site The company provides a rich set of educational materials and is known to be responsive in answering technical support questions.
• DONT leave off the END statement! It causes lockups at the wierdest places (not just at the end)
• Not compatible with all USB to serial adapters. Parallax has one that does work nicely. Here is the RS232 interface on the SXKey
• Watch CAN be used to view the same variable in more than one base.
• Al Williams Microchip-style mnemonics for PIC coding
• See the program templates in the code library

see also:

• sxkey page at Parallax.com
• Ubicom, Inc.
• http://sourceforge.net/projects/gsxprog/ - C Linux code to read and program SX chips with the SX-Blitz or SX-Key hardware. See:
  http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/gsxprog/?cvsroot=gsxprog for the actual source.
• http://sourceforge.net/projects/blitzer/ - C / Python code for Linux and PalmOS to drive the SX-Blitz

 SXKey updates:

• 2004/11/01 SX/B BASIC to ASM code generator released and integrated with SX-Key IDE. You now have a high level language to whip out code with while still being able to fine tune the resulting assembly for maximum performance! See:
  http://www.parallax.com/sx/sxb.asp
• 2004/07/09 SX-Key Beta 2_02_09 A few more features added:
  • When you make a change to a file, the name displayed in the list on the left of the IDE has an asterisk prepended in front of it.
  • Added "Restore Workspace" option to have the IDE reload all the files that were open when it was last shutdown. This is a user selectable option available on the Configuration dialog.
  • Ctrl-Tab file cycling. Yes, like most good file editors, if you have more than one file open, pressing Ctrl-Tab will cycle through all the open files sequentially. Ctrl-Shift-Tab will cycle through them backwards. A "single" Ctrl-Tab (where you release all keys between each Ctrl-Tab) will toggle between the last two files that were selected. The files do not have to be sequential, as you can choose any two files in the list of files on the left of the IDE.
• 2004/06/19 Sx-Key Beta 2_02_07 Peter is working on tons of improvements to the IDE which will be released soon at the Parallax site.
  • The most important new feature is the addition of the "Top" file. Since SASM can include files, it's important that when it is told to start assembling, it knows what source file is the topmost in the chain. Currently, if you have a multi-file project and are working on a file other than the topmost one, you have to manually switch back to the topmost file before hitting assemble. If you don't, you get all sorts of errors due to the fact that SAMS is assuming the current file is the topmost.
     
    Now, if you are working on a multi-file project, you can tell the IDE which of the files you have open is the "Top" file. To do this, click on any file name in the list of open files on the left of the IDE. Right clicking on the selected file will bring up a menu which has a new option: Set as Top File Clicking on it will cause the file to be displayed in boldface. Now, as long as that file remains open, you can work on any other file inb the project and when you hit assemble, SASM will be told the proper file to start assembling from. In addition, anytime you set a file as "Top", that file path and name are stored in the registry. This information is used so that when you open a file, if it's on the list of known "Top" files, the IDE will ask if you want to make this the current "Top" file. If you decide you don't want a "Top" file anymore, right clicking on the "Top" file will bring up a menu with two new options: Set as Normal File and Remove from Known Top File List The first option simply restores the file to normal status. The second will remove the file from the list of known "Top" files it stores in the registry.
     
    I feel this makes multi-file projects much more convenient, as it doesn't require you to manually switch back to the topmost file everytime you hit assemble. It also requires very little work on the user's behalf, since the "Top" files are stored in the registry auomtically. A total of twenty known "Top" files is stored, and the list is maintained as a "Least Recently Used" list.
  • Fixed bug where creating a new blank file would disable the toolbar buttons for assembling ANY file that was open.
  • Changed label on Debug window from "Update Speed" to "Walk Update"
  • Added support for stricter parsing by SASM. For the IDE, it was mainly adding the support for a checkbox in the cofiguration dialog, and adding another switch to the command line it builds for SASM.
  • Force register window to correct size when "Reset Pos." button is hit on the Debug window. All other window sizes/positions are based on this, and it was possible before the fix to have the register window at the wrong size even when the reset button was hit.
  • Fixed bug where using the old assembler could cause the horizontal splitter for the error messages to get partially covered with text from the old assembler screen.
  • Added support for allowing user to click on version string in "About" box and have it toggle between the IDE version and the SASM.DLL version.
  • Fixed bug where displaying the list window without having a RESET in the code would cause an error dialog telling the user they needed a RESET. Since they weren't trying to download the code to the chip, there was no reason for the IDE to display the dialog.
     
    In SASM:
  • Fixed error where support for "LIST W = n" was broken. The "LIST W=" sets the warning level, but the code was broken and regardless of whether you told it warning level 0, 1, or 2, it always used 0, which means ALL comments, warnings, and errors.
  • Added commandline support for stricter assembly parsing. I had a source file with a row of "*" characters which SASM accepted as legitimate. The problem is that a row of "*" characters is illegal and should be flagged as an error.
  • Changed error # 4 ("Symbol is a reserved word.") so that it took the problem symbol as a parameter. I also changed the wording slightly. For example, "PCL" is a reserved symbol. Previously, if you used it, you got the generic warning. Now if you use it, you get: 'PCL' is a reserved word. This makes it MUCH easier to figure out what is causing the problem in your code
  • Added additional, individual return error values when SASM has a problem trying to create any of the following types of files: .map, .obj, .sym, .lst Without these, SASM would finish assembling without leaving a logfile, and the IDE only knew that an error had occurred, but had no idea what the error was.
  • Modified SASM to indicate error if an invalid watch type (UBIN, UDEC, etc) was specified. I added a new error message to more clearly indicate the problem. Without the new error message, the user was told there was a missing WATCH parameter. That's a vague and misleading error message. The new message is defined like this: {"Invalid watch type specified - \"%s\"", ERR_INVALIDWATCHTYPE, 1}
  • Modified SASM to output "Unmatched Macro" warning instead of "Unexpected End of File" error when as macro has no "ENDM" to close it.
  • Added ability for user messages to contain variable values. I wanted to have the assembler let me know what was being compiled by outputting messages after assembly. In one prject, I hardcode different addresses, and wanted a quick "sanity check" to know I had the right address. The address is a constant called "SN_ThisNode". The variable or constant needs to be outside any quotes.

    SN_ThisNode	=	5			;Node of this module
    	ERROR p2w '----------------- Node set to ' SN_ThisNode ' -----------------'
     
    

• 2004/05 Parallax announces new partnership with Ubicom, SX-Key price drops to $89 with full kits at $99
• 2002/07/18 Peter Montgomery was hired by Parallax Inc to revamp the IDE, and make improvements to the system... AND BOY DID HE!
  • A new, multi-file editor
  • Scrollbars!
  • Colored syntax highlighting.
  • Multiple Un-Do.
  • Integrated SASM as the new, default assembler. This allows the use of INCLUDE files.
     
• 2001/08/01 Peter Montgomery has released his first SXKey software improvements!
• Parallaxreleased the source code for the IDE and we hope to see some grassroots updates very soon:
  http://www.parallaxinc.com/html_files/downloads/downloads_sx.htm

The IDE on the older versions of this product wasn't great. See Read, Program and Debug the SXKey using a QBASIC-program (QBL99V3.BAS) and http://sourceforge.net/projects/gsxprog/ ( http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/gsxprog/?cvsroot=gsxprog ) for efforts to replace it.

Having problems in Windows XP with the serial port? Peter Montgomery says:

Go to the hardware manager and open the settings for the serial ports. For the port that's attached to the SX-Key, check the FIFO settings. Most likely it's something like 14/16 bytes. Set the values down to something low like 3/4 bytes. I have found this often cures a number of SX-Key anomalies such as random disconnects. You might even want to experiment with turning the FIFO off. I know the FIFO is a nice thing to "take the strain" off the CPU, but when everyone is running 800 MHz and up CPUs, I find the CPI can handle the burden.

Stephen Holland says:

The device directives OSCLP1, OSCLP2, OSCXT1, OSCXT2, OSCHS1, OSCHS2 and OSCHS3 correspond to the following settings shown in the SX datasheet (taken from the SX28 here, but SX52 is the same):

FOSC2: FOSC0 External oscillator configuration (valid when IRC = 1):
	000b = LP1 - low power crystal (32KHz)
	001b = LP2 - low power crystal/resonator (32 KHz to 1 MHz)
	010b = XT1 - normal crystal/resonator (32 KHz to 10 MHz)
	011b = XT2 - normal crystal/resonator (1MHz to 24 MHz)
	100b = HS1 - high speed crystal/resonator (1MHz to 50 MHz)
	101b = HS2 - high speed crystal/resonator (1 MHz to 50 MHz)
	110b = HS3 - high speed crystal/resonator (1 MHz to 50 MHz)

Even when using an external 50MHz crystal oscillator, you will still need some gain, so I suggest using OSCHS1 or OSCHS2. The directive 'INPUT' is the same OSCLP1, and after significant testing, is not suggested, even for external crystal oscillators. That is why the current revs of SX-Key software do not provide this selection in the device configuration window, even though the directive itself may not give an error.

SX-Key software for SX28 rev 1.08+ and SX52 rev 1.16+ have support for these directives.

There is no difference between Rev E and Rev F of the sxkey other than the cable.

William K Borsum of Dascor says:

The SX-Key must have five volts input.

There is a DC-DC on the board but they couldn't/wouldn't tell me specifically what it was for.

The outputs from the SX-Key (OSC1, 2) must NOT be clamped to anything. Apparently there is a higher voltage required on these pins to tell the target chip that it is in SX-Key/debug/program mode.

The higher voltage on OSC1 and OSC2 will NOT appear on any other pins of the target chip.

The five volt supply on the SX-key can be different from the target chip--i.e. the SXkey can run from a five volt supply (single 7805, caps and wall wart= SX-Key-Ring) while the target system runs from its own supply. Only common pins are GND, OSC1, OSC2. The power rails are NOT connected if a different voltage.

To replace a PIC 16x5x with an SX18 or 28, just get the hex file from MPLAB, etc... and open it in the SX-Key software under Run / Device / Load Hex. Don't open the hex file with File / Open; use Run / Device / Load Hex. You can either rename the hex file to .sxh or enter *.hex in the File Name control and hit enter to see the file. Ensure that the options are set correctly (you may have to try several different Oscillator Crystal options to find the one that works best for your circuit) then press Program then Verify. If you turn on the Turbo mode, your code will run approximatly 4 times faster with the same clock, but timing sensitive items (bit banged serial, IIC etc...) may be affected. The Options for Stack and ADD/SUB with C should not be used.

 .sxh file format:

       :BBAAAARRLLMMLLMMLLMM......LLMMCC

       BB   # data bytes
       AAAA load offset (address x 2 as msb:lsb)
       RR   record type, 00=dat,01=eof
       LL   lsb code word
       MM   msb code word
       CC   checksum

Don Wade [WadeD at ncc.edu] explains how to use SXSim with the SXKey's assembler

Here's the instructions I give my students when we use SX Sim:

In order to use the simulator program you need to produce a "list" file of your program. You can do this with SX Key as follows. First write your program and assemble it (with no errors). Save it under whatever name you wish using the "FILE-Save As" function if it does not already have the proper name. After you have written your program, In the FILE menu click on "Toggle List On" --this will show the list file with both code and mnemonics. Then click FILE - SAVE which will save a list file under the same name but with the extension ".lst" instead of ".src."

Note: If you click on "Save As' and try to rename the file, SXKey will usually add on the ".SRC" extension so the file will be saved as XXXX.LST.SRC (where XXXX is the name you gave your file). This file will not work in simulate and you need to change its extension. Open up the folder the files are in. You should see the XXXX.LST.SRC file. Click (only once) on it to highlight it and then press F2 in order to edit the file name. Use the right arrow key to move to the end of the name and then backspace over the extra extension so it now is XXXX.LST only. [Or use any other method you find easier to change the extension to ".LST"]

JP Harrison offers some advice for troubleshooting problems with the SXKey:

Make sure you have built the simplest circuit possible. Use new chips, test all connections.

Is your power supply stable?

Breadboards don't always make good contacts, especially if they have been used quite a few times. If necessary, wire-wrap a test circuit.

Keep a known (simple) test circuit on your bench. Use this for a sanity check every once in a while.

Check your serial port to see that it is working. You can use an old external modem - hook it up, and install it (on Windows) - you can then do a test on it - the lights should blink. If they do, and Windows can identify the modem, your COM port is almost certainly working. Use the SAME cable to connect to the Key. Of course, you can hook up your serial port to another computer, and use Hyperteminal to communicate. BUT: don't forget you have to cross the receive and transmit lines, so you can't use this cable to connect to the Key.

Write a little 3 line program to see if the chip can be erased and programmed.

DO NOT use the sleep command; if you do, you'll have to reset the chip before re-programming, or you'll get the message "Chip connection failed".

I found that I could reverse the Key connections, and it would not blow up the Key - I don't recommend it, but it didn't seem to hurt anything. I also reversed the SX28, and the Key was still fine - it also didn't (seem to) hurt the SX28, but again I don't recommend doing this.

It seems that the Key is pretty robust. The first thing you should suspect (if you can't program the chip) is your circuit (or the chip itself).

The tech people at Parallax were very helpful.

Guenther Daubach says:

Today, I made an intersting experience with the SX-Key.

I was testing a little SX application, handling a UART VP sending out serial data to a PC COM port. As I had only conncted one serial cable to the PC, and did not want to spend too much time, installing another one (you know - creeping on the floor, locating the COM port, trying to figure out where the other end of the cable is located...) in order to use different COM ports, one for driving the SX-Key, and one for capturing the SX serial output with HyperTerminal, I had to go with just one COM port for both.

<SNIP>

Now, after programming the SX with SX-Key, it came to my mind that the SX-Key can also act as clock device. So, with the serial cable still connected to the SX-Key, I selected "Run - Clock", set the clock to 50 MHz, clicked the "Reset" and finally the "Ok" button to close the Clock window again.

Leaving the power on, I then unplugged the serial connector from the SX-Key, just to notice that the SX continued execution of the program, as some status LEDs continued blinking as expected. I then plugged the serial cable into the SXes serial port. After launching HyperTerminal, I could nicely see the serial data sent from the SX with the SX-Key acting as clock source.

Looks as if the SX-Key simply continues generating the clock signal defined by "Run - Clock", even if the serial cable is no longer connected to it.

Well, this has one drawback: As soon as you un-/re-power the system (or even a "glitch" on the power supply) brings the SX-Key into idle mode, and it stops clock generation. I did not test if the SX-Key also stops clock generation when the SX MCLR* pin is pulled low for a reset.

Nevertheless, this saved me some work during the test phase today, as there was no need to plug/unplug the resonator/SX-Key all the time.

Using the SXBLITZ-protocol with a SXKEY instead of a SXBLITZ

Read, Program and Debug the SXKey using a QBASIC-program (QBL99V3.BAS)

See also:

• http://dmtwww.epfl.ch/~jzuffere/SXCompiler.html ByteCraft SXC: a C compiler for Ubicom SX microcontroller ... description and list of bugs ...

  .