Hi,

I must program the sx trought a pld. The the data sheets, are obsolete and the command list is not complete. I try to log the sxkey and find much more commands. For example is possible read/write sequential .

Where can i find this command list or an update sheet??

Goffi,
Have you seen the attached in-system programming specification? This document should help you achieve ISP.

Ken Gracey
Parallax, Inc.

Ken beat me to it. The document he's given provides all the information nessesary to do ISP, the chip is static, so it does not matter how old the document is, it still applies.

tnx for the answer, but this sheet is my first download :P   unlucky it is too old!! it is not complete. sxkey use much more commands not listed.

in the list, you have the commands from 0 to 7 + 0xf (above are for future expansion).    
sxkey use command like 0x8 0x9 0xa 0xb 0xc 0xd 0xe  ,  what are it?  some of it is like read/write sequential, but i'm not sure.

no one has this complete list??

sorry for my lame english.

The SX-Key not only will program an SX, but it also performs in circuit debugging. Perhaps the tokens you are witnessing are in relation to that function. However, I don't understand how debugging would benefit your desired CPLD programming application. The chip has not changed since the release of the document we have pointed to. Parallax Im sure has the full command set, but I don't know if they will part with it, I beleive it was given to them under NDA (non-disclosure agreement) so they could develop the SX-Key. They own the chip now, so the NDA (if there was one) is no longer valid, but again they are commands related to ICD and wouldn't give you anymore usefull functionality in your desired application.

i'm working to understand sxkey -> sx protocol. it is not easy  can be the stream crypted? :O   and why crypt it?   why i want investigate more? easy.. why must i use only 7 commands , when there are better commands? why i must load,program,increment if is possible send sequential the datas?   I hope there is not any nda  and some one from parallax can help me.

I believe you are misunderstanding what I am trying to say. The SX-Key has two different purposes; the first which is what you want to do, is program an SX, the information needed to do this is all in the pdf we pointed to, nothing hidden, its all there. The second function the SX-Key does is debugging of a program on the SX itself, this means establishing breakpoints retrieving register contents etc. None of the features benefits the programming of an SX whatsoever.

There are a number of secret SX instructions directly pertaning to the in circuit debugging capability, and as of 1 year ago, you could only get them through a NDA with ubicom. Those instructions are laid out in detail in this thread: http://forums.parallax.com/forums/default.aspx?f=7&m=56795
Now if I were Parallax, I wouldn't disclose how exactly the secret instructions are used to implement the degugging used in the SX-Key. Why? because the SX-Key represents years of development and refinement, costing alot of resources, and its the only commercial SX-programmer that does this additional functionality. That doesn't mean you can't reverse engineer a debugging solution using the instructions in the above thread, but it still raises the question: Why? A CPLD wouldn't need to debug the SX, just program it.

i understand what you are saying.. but now i'm very curios and want understand this.  I'm not debugging a program. In this case i can understand and find strange informations.  
I'm only programming (ctrl-p) a little program.  What it sent to sx is completly different from the 'standard' commands.  Sx has a 'secret' instructions and now pheraps also  also a 'secret'  isp protocol .

Well if you can figure out what is going on that is different from the protocol stated in the pdf, by all means share with the community. But Im not aware of anyone outside of Parallax that has figured it out.

Goffi,
Other tool providers (such as Nurve) have successfully implemented the ISP protocol from the document I provided to you. If you have a production programming problem and need to support a manufacturing issue then we can provide further assistance. If you are simply trying to get an inexpensive tool built for your own use I can't be of much help as managing these requests is not cost effective. It would be much easier for me to send you a batch of programming tools.

Goffi;
I'm positive the ISP programming protocol works EXACTLY as described in the document indicated by Ken. I can't understand why you're so insistent that it's different, because i't NOT.

As indicated by Paul, the DEBUG protocol is different, and THAT one is not in the public domain.

for the sceptical persons...  this is a little part of the log of the communication between sxkey and sx.

1110:110011101000<-CE8
1110:110010111011<-CBB
0001:110000100001<-C21
0101:011100110011<-733
0011:011011100100<-6E4
0010:110111110010<-DF2
0110:010111110010<-5F2
0101:010011111110<-4FE
0011:001110100101<-3A5
1000:110100000110<-D06
0110:000111111000<-1F8
1111:000010101111<-AF
0010:011011110101<-6F5
1001:010010010000<-490
1100:111111101101<-FED
1101:101010000100<-A84
0000:100101001001<-949
1000:010101001000<-548
1001:111100010010<-F12
1000:000011100010<-E2
0111:110000010101<-C15
0011:010001101111<-46F
1111:000000010100<-14
1001:100101110101<-975
0000:000110101101<-1AD
1101:011100011001<-719
1111:101010001000<-A88
1011:111101001011<-F4B
1010:100011001001<-8C9
1100:110101101101<-D6D
1100:001001010111<-257
1101:101110110110<-BB6 i don't understand why parallax use a secret way to program sx and others persons must to use a 'free' way. i can understand they pay and spent money to develop sxkey but why they use other way? is it better? is it too fast?

Hmmm, If it's a secret why are there so many SX device programmers here
http://www.sxlist.com/techref/ubicom/devprogs.htm

Bean.

Is that log you quoted generated by pressing Ctrl-P or are you using some other method?

i have logged it, during the chip programming ctrl-p (init+erase+program+verify) and this is only a little part of it.

Until recently, there were a few undocumented commands that were used in SX debugging, including by our SX-Key.  We (Parallax) sought and obtained permission from Ubicom to release information on these commands, but there has been no wholesale updating of older documentation(i.e.,  that you cite).  Nobody is trying to trick or deceive you.  If you do a search through this forum you will find information about the previously undocumented commands and how some advanced forum members are putting them to use.

Have you tried a extremely simple program such as ":loop jmp loop". Instead of trying to decifer a huge command stream from a large program, start out simple.

Goffi,
As I indicated above, if you're a tool manufacturer we'll help you. If you have a production programming problem we can help you. If you are a hobbyist who needs help implementing the ISP to save some expense you'll be on your own with our published documentation. I will assume you are the latter by lack of positive reply to my prior post and will advise our main SX engineering staff not to assist unless you contact me off-line. If this is the case we can't cost effectively support your needs. I've got to be honest and straightforward with our position and your request.  
There are no secrets of which I'm aware, only some tricks in regards to implementing the debug portion of the SX-Key which are not published (because we don't want to support such requests as evidenced by this thread). Again, if you are a tool manufacturer then there's even a way to help you in this regard.

Ken Gracey
Parallax, Inc.

i have 3 sx-key. my first buy is in 1999 from you and sent my sx28/48/52 (some at 100mhz!!)  plus a little gift (parallax screwdriver).  much time ago..

i know you want protect your interest. is not my intection make a similar sxkey programmer.  
i'm not interested in your debug routine.

sx is not a secure chip... if some one wanna clone your programmer, you know... it is very easy.  but i repeat, i only ask about this strange protocol. not other.

you can advise your staff now, no problem for me.

Goffi,
The data stream between the SXKey IDE and the SXKey is encrypted.  Why?  I don't know and I don't care.  It just is.  However, the documentation for programming the chip is available.  If you want to do create your own programmer then why do you even care how the SX-Key and the SX IDE communicate?  You won't be using them, so don't waste your time trying to figure them out.  Spend your time on getting your own programming system working since that is what you want to accomplish.

Theres a window into what to do goffi, sniff the output of the SX-Key (between the Key and the SX) rather than the serial data between the PC and SX-Key. They are two completely seperate issues, since Parallax uses an SX on the SX-Key itself to translate data from the PC into a programming sequence for the target SX, they are not constrained on the PC->SX-Key protocol since they control both sides of the link (SX-IDE and SX-Key). There is nothing preventing them from redefining the programming command 0011 to 1101 or any other command mapping. You seek to understand how an SX is programmed, the only way of accomplishing that is by analysing the actual data sequence between the SX-Key and target SX. Trying to understand by analysing the serial com between the PC and SX-Key is like trying to learn French by reading a German translation of a French novel.

PJMonty: my english is very bad... i mean the communication between SX<->SX-Key.
Paul Baker: i continue to investigate. i find some good trick here http://www.sxlist.com/techref/parallax/sxkey/SXBLITX_SXKEY.htm and in the source code gsxprog.  but these are related to pc<>sxkey.

As has been pointed out the communication between the PC and the SX-Key is proprietary to Parallax; but this certainly doesn't stop you from building your own SX programmer -- it just stops you from making a clone of ours that you could sell (against us and our support) for use with the SX-Key software.

ufff.... i repeat again.  i don't wanna make any clones !!  you know very well... there are other fast ways to make a PERFECT clone of your sx-key, without know any technical informations about your proprietary protocol.  now i'm only curios.

goffi,
 I know exactly what you mean. Yesterday I called Microsoft and they wouldn't provide me with the source code for Microsoft Office. Then today I called Coke, and they wouldn't provide me with their formula for Coke. I cannot believe the rudeness of these companies. I mean I'm just curious...
Bean.

i'm not asking any things now.   in my first post i ask because i don't know any things about this 'secret' way and think in some my mistake.  now i'm studing it without any question.

So the information provided in DeviceProgramming.pdf, is actual for modern Parallax marked SX chip(e.g. date code 0616,0621).

And what about parallel programing?

The only thing that has changed is the packaging, so all of the information in the document is still valid.

Hey all, wait a second...

seems as if some are messing up two protocols: The one between the SX-Key IDE, and the SX-Key or SX-Blitz, and the protocol between the SX-Key/Blitz and the SX to be programmed.

The IDE-SX-Key/Blitz protocol is Parallax proprietary stuff, and in case of the SX-Key it is encrypted. Nevertheless, If you want so set up your own SX programmer, it does not help monitoring the data exchanged between the IDE, and the SX-Key/Blitz, as this has nothing directly to do with programming the chip.

Instead, follow the instructions given in the DeviceProgramming.pdf document. This describes the "official" methods how to communicate with an SX chip for programming/verifying. In the end, the SX-Key/Blitz devices do nothing else. They receive commands from the IDE (via the "Parallax" protocol), and convert them into the required serial sequences for communicating with the SX chip via the OSC pins, and they also provide the required programming voltage Vpp when necessary.

So, my suggestion is to study the DeviceProgramming document in detail instead of trying to analyze the internal IDE-SX-Key/Bliz communication.