SX-Key not found/Clock frequency changing...

Comments

• Zoot Posts: 2,227

  2009-03-27 06:04 edited 2009-03-27 06:04

  Sounds like dirty header pins or poor connection w/Key. I have had a number of instances where dirty pins or dirty connections cause total lack of comm. with the Key (which would also affect clock speed when the Key is generating the clock for you).
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  When the going gets weird, the weird turn pro. -- HST
  
  1uffakind.com/robots/povBitMapBuilder.php
  1uffakind.com/robots/resistorLadder.php
• WoF Posts: 10

  2009-03-27 17:39 edited 2009-03-27 17:39

  Thanks for your reply, Zoot. I shall check and clean the contacts. But the kit was fresh from the factory so contacts should be alright.
  After observing the device today during my experiments it seemed to work better. No SX-Key not found or chip connection failed messages.
  But after loading a program in run mode it seemed slower than expected. I clicked on the clock-symbol and the slider and window were showing lowest position.
  (I estimate the clock frequency to be 20 MHz or so)
  After reloading and checking again it said 50MHz and the device was running like expected.
  I suspect there an issue in setting the SX-Key to create a certain clock frequency.
  I shall observe and report more, when I have more insight.
  
  Again, thanks for responding.
• Guenther Daubach Posts: 1,321

  2009-03-27 21:39 edited 2009-03-27 21:39

  Whenever the SX-Key IDE communicates with the SX under test, the clock frequency generated by the SX-Key is changed to 20 MHz to make sure that the timing between the SX-Key and the SX under test matches. When program execution is continued, the clock frequency is switched back to what the FREQU directive in your application specifies.
  
  The current IDE beta version seems to mess up this frequency setting from time to time. As a workaround, you may consider running the SX under test at 20 MHz if this is fast enough for your application - it definitely will be fast enough for the LED blinker . With 20 MHz, there is no need for switching the clock frequency, so it can't be messed up.
  
  To my knowledge, a revised version of the SX-Key is going to be released soon with such problems fixed, so please stay tuned.
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Greetings from Germany,
  
  G
• WoF Posts: 10

  2009-03-27 23:23 edited 2009-03-27 23:23

  Oh, thank you G
• Guenther Daubach Posts: 1,321

  2009-03-28 21:55 edited 2009-03-28 21:55

  WoF,
  
  ja, ich bin Deutscher .
  
  yes, I'm German .
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Greetings from Germany,
  
  G
• WoF Posts: 10

  2009-03-28 23:23 edited 2009-03-28 23:23

  Wie nett.
  Und wenn ich das richtig sehe, sind Sie auch der Autor des wunderbaren Buches, das ich grad durcharbeite.
  Woher sind Sie denn?
  
  Ok, for common sense I shall continue in English, I think.
  I presume, you are the Author of the wonderful book I'm working through at the moment.
  Except for some errors, where some symbols in the code do not match the references in the text (e.g. WKPND_B to WKPND_W in the text) I have to say, that this book is very well structured and easy to understand. It's real fun to go through the chapters, even if you do not enter the code literally, but already do your own stuff (like I do). All concepts are described in detail and layed open very comprehensively in a step by step basis.
  Congrats to that great publication. It helps marvelously to dig into the matter whithin a couple of days.
  
  Admittedly I'm not new to microprocessor programming (always in assembler) and I've seen different concepts yet, but with a beginners guide like this you could do anything with a processor within practically no time, even if it has some strange concepts and restraints like the SX28.
  
  What makes me a little unsure are observations like:
  Sometimes while loading a code to the processor (mostly in debug mode) the program says SX-Key not found on COMx and aborts. I have to unplug everything and retry, before everything works as expected.
  Or:
  For interrupt studies I entered the very simple program from page 107 of your great book.
  Escept for the phenomenon that the interrupt is not always cought by the debuuger (which was mentioned in the book),
  I observed the port registers PA, PB and PC changing values at random. Is that normal?
  I tried to activate the pullups on all inputs, in cas they catch random noise, but still there were unexpected changes in the port registers.
  And sometimes in WALK mode the program suddenly enters "undeclared territory" running through address spaces where no program was defined...
  
  
  Post Edited (WoF) : 3/28/2009 11:29:36 PM GMT
• Guenther Daubach Posts: 1,321

  2009-04-03 20:48 edited 2009-04-03 20:48

  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
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Greetings from Germany,
  
  G
• WoF Posts: 10

  2009-04-06 13:06 edited 2009-04-06 13:06

  Hello, G
• Guenther Daubach Posts: 1,321

  2009-04-10 22:10 edited 2009-04-10 22:10

  Hi Wolfgang,
  
  continuing our conversation in English via the forum is fine with me, so let's go ahead.
  
  Could you test the external pullups, and did they make any difference? Actually, they should not as the internal pullups are fine enough to pull unused inputs up to high level. When activating the internal pullups by writing %00000000 to an !Rx register, make sure to set the mode register to $0e (SX20/28) or $1e (SX48) before, in order to select the pullup config registers.
  
  Regarding your observation about the FREQ directive and the actual clock frequency supplied to the SX unter test, I found similar problems with the current SX-Key Beta version, and I'm sure it will be fixed in the next version.
  
  One general information about debugging and clock frequencies:
  
  When you program the SX under test for debgugging, some additional code is transferred to handle the communication between the IDE and the SX under test. To make sure that the timing for this communication is correct, the IDE modifies parts of the additional code depending on the clock frequency selected with the FREQ directive. This means that after changing the clock frequency by modifying the FREQ directive's parameter, you need to re-program the SX under test, i.e. select "Run-Debug" to launch the Debugger. Selecting "Run-Debug (reenter)" instead, will fail due to wrong timing. You may use "Debug (reenter)" only when you did not make any changes to the source code. The only exceptions to this rule are setting/changing watch variables, or setting/changing the BREAK directive.
  
  In general, the FREQ directive only specifies the clock frequency to be generated by the SX-Key while debugging the SX under test, or while supplying the clock to the SX under test when you select the "Run-Run" option.
  
  Which clock frequency is used in stand-alone mode depends on the external component attached to the SX (crystal, resonator, clock generator, or RC-network), or on the internal clock generator. Make sure you have included a matching DEVICE OSC??? directive to select the clock source for the stand-alone SX.
  
  Well, the NOT W instruction is a bit tricky. Its instruction code is $FFF. On the other hand, an unused, i.e. empty or erased cell in the SX program meory also reads $FFF. This is why, the IDE interprets program memory cells containing $FFF as "unused".
  
  Regarding my book, I'm glad that you like it, and that it helps you getting used to the SX controllers. Well, the I2C routines are a bit off the standards published by Philips. Nevertheless, I published these modified routines as I had used them for one of my very first SX projects. The state machine concept is well-suited for many SX applications, especially when you run several tasks in an interrupt service routine, or in the main loop with timer control generated by an ISR.
  
  Hey, seems as if our processor background is pretty similar. My first microprocessor was the 6502 on a KIM-1 single board system. Next, I got in touch with the Motorola 6800, the Intel 8080, the Zilog Z80. I also did some projects with the Intel 8051, and did a lot of application development for the 80x86 processors. Like you, most of my code is in Assembly. I like this way of programming because I "personally know each bit inside the controller/processor" .
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Greetings from Germany,
  
  G
• WoF Posts: 10

  2009-04-14 14:44 edited 2009-04-14 14:44

  Hello Guenther,
  
  thanks for responding.
  I have OSCHS2 because I plan to use a 40MHz crystal in the end. I hope this is the right choice.
  Although, I think these cermaic resonator thingys are precise enough for the purpose.
  
  At the moment it seems I cannot reproduce the changing-port-pin-situation. Everything seems stable as would be expected. I will try to trace back to the situation where this happened.
  
  Although I have to adapt the I2C routines massively, they show well the concept of the state machine AND the concept of I2C communication.
  My Implementation would consist of a slave which will only be written to. Messages are 5 bytes long, first of which will be an ID, as specified in I2C. The SX will respond to 5 consecutive addresses and receive 3 bytes of information for them, plus a checksum to verify the transfer.
  Your book was very helpful in understanding the state machine implementation, but also in grasping the "queer" concepts of the SX, like memory mapping in banks and pages, and pointing out all the footfalls.
  
  Glad to hear about your programming background. That makes me confident, that we have an understanding.
  I had KIM-1, too, but only borrowed for a week. After that I bought a NASCOM, which was a Z80 system with a TV interface already (16x64), making everything more transparent. I wrote Mastermind and Game Of Life for this board. After that I designed an EPROM programmer to attach to it and from this time on it had a fixed purpose.
  I had a CP/M system with Z80 a little later, writing many fine tools in assembler.
  Did little 6800 and 8051 projects, too. And later got a Commodore C64 for playing with the 6502.
  
  Last projects since 2000 were with an 80C535/515, which is 8051 family. This will be the I2C master for the SX28 in the new project.
  
  I shall be happy to keep in touch with you.
  
  Best regards
  
  Wolfgang