In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Hi WoF,

sorry for my late answer.

Thanks for the kudos - I'm glad to hear that you like my SX book. Yes, there are still some errors in the book - even more than you have found so far. As usual, such errors show up only after the latest revision has been printed. I hope, I'll find the time to prepare a third release in the near future.

Good to hear that there is at least one more programmer around on this globe who likes programming the SX and other controllers in Assembly :-). Since Bean has published his SX/B compiler, it seems as if SX/B is the only programming language for the SX that people are using because about 99% of the current programming threads in this section deal with SX/B. Please get me right - I don't complain about this fact. IMO, SX/B has inspired many people to use the SX. Without SX/B, they might never have touched an SX at all.

Regarding the SX-Key, you should know that I was involved in the development of the new SX-Key USB. Therefore, I know a bit about the internals.

In general, the communication between the SX-Key and the IDE via either a COM port, or a virtual USB COM port (i.e. for both, the "old" RS-232 SK.Key, and the "new" SX-Key USB) is a bit critical. On the PC side, changing the port options, like using a FIFO buffer, or not, or increasing the buffer size can help to stabilize communications. For example, on my desktop machine, I get an "SX-Key not found" message about one out of twenty tries when launching the debugger, where on my laptop computer I practically never come across such an error. Both machines (fortunately) run Win XP. (My place is an almost Vista-free area, except my daughter's desktop and laptop.)

Another critical area is the connection between the SX-Key and the SX under test. The communication between both parts is performed via the OSC2 pin, and the OSC1 pin is used to feed the SX under test with the clock signal which may be varying between 20 MHz, and the value specified with the FREQ directive in the application code, as I had mentioned in an earlier post. I found out, that the length of the leads between the SX-Key and the SX under test can dramatically influence the stability of this communication. The shorter the leads are, the better the stability is. Longer leads cause more stray inductance and capacitance which deform the signals, causing the SX-Key to misinterpret the responses from the SX unter test from time to time.

Regarding your observation that the port registers change values at random, I think this is not normal. It is important to make sure that no port pins configured as inputs remain floating, i.e. either external pull-up, or pull-down resitors should be connected to those pins, or the internal weak pullups should be activated. You mentioned that you did activate the pullups on all inputs which is exactly what should be done, so I have no explanation why port states still are changing at random in your environment. Could you try external pullups instead, just to figure out if this makes any difference?

The WALK mode problem you have described seems to be related to the communication stability I had mentioned before. From time to time, it may even show up while single-stepping.

In case you want to discuss some details in German, please feel free to directly contact me via g.daubach@mda-burscheid.de

---------- End of Message ----------


You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=338530#m340611

Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com

The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)