Several other threads deal with problems that may, or may not be caused by a defective SX-Key.

Here is a test you may perform to check your SX-Key:

Make sure that the SX-Key IDE is not running, or any other application that makes use of the COM port, the SX-Key is connected to.

Make sure that the SX-Key is connected to this COM port via a serial cable, and also make sure that the SX-Key is powered, i.e. it is plugged to a target system's 4-pin header in correct orientation, with power applied to the target system.

Launch HyperTerminal or any other equivalent communications program, and configure it to use the COM port, the SX-Key is connected to, set the baud rate to 57,600, 8 data bits, no parity, 1 stop bit, no handshake. When the terminal program has an option to echo the input characters, turn this option off.

Next, enter the following text in the terminal program (without the quotes but in correct case): "SX-Key". As you type each character, it should be immediately displayed in the terminal's receive window. This is because the SX-Key hardware is designed to directly echo back each received character by hardware, i.e. not through the on-board SX20. So, you would receive such echos even when the SX-Key is not powered..

When you don't receive these echos, it is most likely that you have selected (or connected the SX-Key to) the wrong COM port, or the serial cable between the PC and the SX-Key might be (broken, or not a straight-through cable), or that any of the SUB-D 9 connectors has bad contact. In this case, fix such problems, before continuing.

Immediately after you have entered the last "y" of the "SX-Key" string, the SX-Key should respond with "SX-Key???" where the three "???" are any arbitrary values.

When you get this answer, you can be sure that the hardware to connect to the SX-Key is in good shape, and that the SK-Key's on-board SX20 is operating - at least does it correctly handle the communication with the PC.

There still may be other SX-Key components broken, like the on-board 5/12V DC/DC converter for the programming voltage (Vpp), or the on-board clock generator. To my experience, this might only happen when you put the SX-Key under extreme stress, like supply voltage above 7 Volt, or a heavy electrostatic discharge.

More than once did I plug the SX-Key on a target system's 4-pin header the wrong way but even this did never "fry" the SK-Key. Even plugging to or un-plugging from a powered target system did not kill any of my SK-Keyes. Nevertheless, it is good practice to un-power a system before plugging/un-plugging components, and this includes the SX-Key as well.

I did the test as described with a bad SX-Key (probably bad internal clock generator - doesn't work for Debug but does work for transfering code) and a new SX-Key.

I was able to type in SX-Key in the Hyperterminal which it displayed while typing. Both SX-Keys displayed the SX-Key with the 3 strange characters as expected.  
I did notice that you must type it in exactly as SX-Key
(Upper Case S X K and Lower Case e y)
If you enter SX-KEY (all caps) it will not work as expected.

Timothy,
yes, you are right, the text to be sent to the SX-Key is case-sensitive, so it must be exactly "SX-Key", all caps except the last two letters.

When one of your SX-Keys works for transferring code, this means that the SX-20 is operable as well as the DC/DC converter for the programming voltage, and it is most likely that the clock generator is damaged, so you can't use this SX-Key for debugging, running, or clocking a target device. Actually, you have converted this SX-Key into an SX-Blitz :-) .

Guenther,
Thank you for the good analysis. Can you tell me what exactly an SX Blitz is as I thought it was another manufacturers version of the SX-Key? I see it listed on your book but maybe I missed something.

It sounds to me from what you said that an SX-Blitz is a first generation SX-Key as the SX-Key has more features like Debuging. Can one still purchase an SX-Blitz. I am just curious as to where the product comes from.

I also did the recomended steps to check my SX-Key. I got the echo back of "SX-Key" with the three character jiberish. I have no problem executing the debugger, and it seems to do things as expected when I do a "Run", and in some cases when I do a "Program". So, it looks like my SX-Key is good after all. At least I got that out of the way. Thanks for taking the time to provide some "hand holding".

"... so you can't use this SX-Key for debugging, running, or clocking a target device." You mention that it is basically an SX-Blitz, if you can not debug, "running" , or clock, what does the SX-Blitz really do.

Hi Ray and Timothy;
The Blitz and the SX-Key are very similar; they both can erase and program any SX processor, but only the Key is designed to facilitate the debugging features.

So really, the Blitz is a lower end "erase and program only" tool similar to those supplied by other manufacturers for their processors.

I have some Blitzes, but rarely use them, and off hand I don't recall if they can be used to generate a variable speed clock for your SX.

Simply, the SX-Blitz is an SX/Key without the on-board variable clock generator that is required to debugging, running, or clocking a target device. Both, the SX-Key and the SX-Blitz are Parallax products, where the SX-Blitz is out of stock right now.

In another thread in this forum, you will find an announcement that a new version of the SX-Blitz (USB) will be available soon.

Hi Guenther, even though you may not "fry the SX-Key" by plugging it in to the header wrong, you CAN fry the debugging aspect.

I suspect this is what happened to tgd8934's bad SX key.

After reading your post I understand how this happens.

If you plug the SX key into a hot header in a way that only three pins go into the key, or if a short in your circuit puts Vdd onto the oscillator pin it fries the internal clock and debug mode becomes deadbug mode.

Hi Electronegativity,
well, I never tried this (and better don't). It only happende to me once in a while that I plugged in the Key in reverse, i.e. OSC1 to Vss, OSC2 to Vdd, Vdd to OSC2, and Vss to OSC1 which did not kill it. Nevertheless, I also have one SX-Key here that does no longer debug, or clock a device. Maybe, I handled it the way you had mentioned without noticing it.

In general, a good rule, handling this little, but valuable device is:

- Always turn off power before connecting, or disconnecting the SX-Key to/from the target device.
- Double-check the right orientation, and position of the SX-Key on the ISP-header before powering the target device.

I also always use a short ribbon cable with a male SUB-D9 on one end, and a female one on the other end sitting between the SX-Key, and the serial cable going to the PC's COM port. This reliefes a lot mechanical stress from the SX-Key.

Hi Guys;
I can also confirm that an exact backward plug-in of all four pins has not damaged my SX-Keys. This happens frequently now that my older debug/development boards use the old "right side up" orientation, and the more recent Pararallax standard uses the "wrong side up" orientation. As I frequently have multiple debug/development boards going at one time, and frequent re-programs, the movement of the SX-Key among these configurations now causes frquent reverse plug-in occurances.

But as long as the pins are not also skewed by one there appears to be no harm done. The one time I did reverse and skew them (which direction I can't recall) it was toast.

I'm not sure why Parallax has adopted this new orientation scheme.....

It would be nice if they would use a keyed connector on future keys......
It probably cost a bit more, but users would be better off in the long run...

Bob N9LVU :scool:

I can certainly agree with that.

By using a keyed connector we also force the end user to use a keyed header.  If they don't the possibility exists to still plug it in backward.  There's no easy solution other than basic precaution.

How about an adapter that plugs into the SX-Key that is "Keyed" on one end.

Then get another adapter that plugs into the SX Tech Tool Kit or PDB that is also "Keyed" on one end.

The "Keyed" ends could plug into each other as a reminder to the user. It may look a little ugly and lengthen the SX-Key but just a thought...

Timothy,
  Please don't take this wrong, but what you're saying means the person putting the adapter on the end needs to make sure they don't put it on backwards.  If you're aware that it cannot go backwards then you shouldn't need something to avoid it.  It's not like the SX-Key looks the same on both sides so it's hard to tell which end is up.  It's just as easy to connect the power backward on many devices or plug your Stamp Module or SX chip in backward.  It's more effective to always be sure of your connections before powering something up.

Hi All,
I agree wholeheartedly with Chris, after all we are playing with a higher intelligence TOY
so can we also expect that the player could also be of a little higher intelligence than the average
player out there.

I mean we are doing hardware development here.  There are soooooooo many ways to fry everything
that expecting Parallax to have to make the Key IDIOT proof is asking toooooo much.

The Key is fine as it is, and to stop the Mechanical stress problem (ie plugging it in straight to the board)
I made a flexible extension cable. This way The key sits on the table and the cable from it (very short)
reaches up into the board.

I guess this can aslo serve as a slotted connection if you keep the flexiple end always plugged into the board
and have one made for each board and one for the Key.

Common Guys, we are making things here so why can't we show some more deligence while plugging
things in. I never ever turn the power on until I have checked my connections and then double checked
again.

I used a marker pen to draw a black dot on the SX-Key, close to the OSC1 pin, and I also draw a black dots on the target PCBs, close to the OSC1 pin of the ISP/ISD header. This is a good aid to optically check if the Key is plugged in the right way.

I absolutely agree with Samuel - you cannot make a development tool absolutelty IDOT proof, and you must expect that users of such systems are intelligent to know what they are doing.

Samuel,
Relieving mechanical stress on the SXKey is a good idea, but the preferred method is to make a small serial cable extension using ribbon cable with IDE style DB-9 connectors at both ends.  Even though you say your cable is short, the SX can be generating signals up to 75 MHz or so, and running those across loose cables can cause weird problems that will make you think the SXKey is failing.

Hi PJ,
I am talking about connecting the Key to the Development Board, it sticks out from the board in the air with
no support and the DB9 cable connector is quite heavy, so it can bend the Key and/or the pins.

So I made a short cable to connect to the Dev. Board, and then the Key to the cable, then the
Key is connected to the DB9 and the other end of the DB9 to the PC.

That way the Key can sit on the table next to the dev. board and not have to carry the weight of the
DB9 connector end.

The short cable is flexible and thus their is no weight bearing on the board or the Key and the slightly
inflexible DB9 cable will not cause Torc or Bending on the Key or the dev board pins.

Samuel,
as Peter mentioned, extending the 4-pin side of the SX-Key can cause weird problems when you use the SX-Key to clock the target system at higher clock rates, say 50 MHz up to 75 MHz. On the hand, when you only use the SX-Key to program the target device, the signals on the 4-pin side are pretty slow, so your solution should work fine.

Nevertheless a ribbon cable on the DB-9 side is what I'm using here. As the ribbon cable is much more flexible than a usual round serial cable this reliefes a lot of mechanical stress from the SX-Key, and the DB-9 connector plugged into the SK-Key is not that heavy at all.

Samuel,
I understood that you were trying to relieve the stress from the heavy serial cable.  The point I was making is that creating a short ribbon cable with DB-9 connectors on each end will do exactly that.  The difference is that extending the serial signal is no problem, whereas extending the extremely high frequency SXKey signals can cause lots of problems.

I have attached a picture to show my key with the ribbon cable.  Believe me, the SXKey has absolutely no problem supporting the weight of this as it probably weighs about two ounces.

Hey Guys,
I like your idea better than mine. I actually have made a serial cable
just like this for something else about a year ago. I am going to dig it out
and use it.

Guenther,
The scary thing is that I probably could get a patent here in the US for something as obvious as this.  Apparently the US patent office has given up on the "non-obvious" requirement for getting a patent and will give one to just about anybody with the application money.

PJMonty,
You are absolutely right. I subscribe to a patent news group and you can't believe what kind of
patents are being awarded. Even for software code that is possible to be coded by
any one who has gone through a basic computer science degree.

Again this is an example of the damage USA lawyers have done to all of due to their greed and
absolute disregard for any sanity or decency just for a buck.

All that matters these days is MONEY. But we can't blame it all on lawyers, they are only acting
in the name of some one who is even more greedy and money hungry.

Sam,
Well, as much as we all love to hate lawyers, this really has nothing to do with them.  Blaming lawyers for bad patents getting approved is like blaming car salesman for selling fast cars to bad drivers who get in accidents.  It's the drivers fault if they hit someone, not the car salesmen's fault.  Lawyers do not approve patents - patent officers do.  The fact that the people who approve the patents (the patent officers) can't tell the difference between something patentable and something not patentable is a problem with the USPTO, not lawyers.  All the lawyers do is charge someone money to put the paperwork together and submit it.  After that, it's all in the hands of the patent office.

Similarly, when people complain about the stupid cases going to court (and often winning), remember that it's not the lawyers who decide the outcome - the jury does.  Furthermore, the case was able to go to trial because a judge didn't throw it out before it got that far.  The next time you see a McDonalds "hot coffee" style case, ask yourself what judge let it go to trial.  This isn't to say that lawyers don't do lots of things we all hate, but it important to understand the judicial mechanism and how it works before assuming that everything is bad only because of the lawyers.

The scary thing is that these lawyers and judges become senators and congressmen and presidents
and supreme court judges.

These are the pool of people from which the rulers and legistlators and power base of this country comes from.

There is a saying that "the ones seeking power are least qualified to hold it."
This is sooooooo true all along the pyramid of power that we currently have.........SCARY........

If anybody cares...

Just as a curiosity, I tried Günther's test on both my Key and Blitz. The Key gives a random response which does not start the same after powering it down. Hovever the Blitz gives me the same response ( SX-Key7.ý ) every time.

Also thanks to Günther for the SX-Key/Blitz communications test tip.

If anybody cares...

Just as a curiosity, I tried Günther's test on both my Key and Blitz. The Key gives a random response which does not start the same after powering it down. Hovever the Blitz gives me the same response ( SX-Key7.ý ) every time.

Also thanks to Günther for the SX-Key/Blitz communications test tip.

If anybody cares...

Just as a curiosity, I tried Günther's test on both my Key and Blitz. The Key gives a random response which does not start the same after powering it down. Hovever the Blitz gives me the same response ( SX-Key7.ý ) every time.

Also thanks to Günther for the SX-Key/Blitz communications test tip.

Rick,
your results are correct, and I know why, but sorry - I can't disclose the reason here.