Debug Windows Not Working Properly (run, step, "grayed out")

Zoot

I've been using my SX-Key for a few months now on SX28 dips, and believe it or not had never debugged with BREAK and WATCH. I'm working on a longer partial-ASM program, and needed to debug, but all the "run" options and such are grayed out.

Guenther's FAQ says:

said...
The Debugger starts in running mode

Q: On my SX 28, when I choose Debug, the debug window comes up RUNNING and the options for Poll-
ing, Run, Stop etc. are gray and I cannot single-step through my program.

A: One reason might be that you have previously programmed the SX selecting “Run – Program” and
then selected “Run – Debug (reenter)”.

The reason is that there is a difference between “Program” and “Debug”. When you choose “Program”, the
only code sent to the SX is the code you wrote. When you select “Debug” instead, not only is your code
sent, but a little piece of special code is also appended. This additional code is required to enable the SX-
Key to properly control and communicate with the chip while debugging.

The option “Run – Debug (reenter)” is meant to continue a previous debugging session, assuming that no
changes have been made to the code in the meantime. Therefore, the code is not sent into the SX device
again, saving the time required to do this. The IDE expects that the required debugging code is available
in the chip, though. When this is not the case (because the chip was not programmed for debugging), the
debugger can’t communicate with, or control the chip. Therefore, it indicates “RUNNING” only, and does
not allow any other options.

Another reason for the debugger starting in running mode is that a resonator, crystal, or an external clock
source is connected to the OSC1 and OSC2 pins in parallel to the SX-Key. Although the chip can usually
be programmed in this configuration, debugging is not possible. Remove or disconnect the external
clocking device to allow for debugging.

Another cause for the debugger to display the “RUNNING” status is when the MCLR* pin is pulled low by
some reason. In this case, the SX is definitely not running but held in reset state. It seems as if the De-
bugger reports “RUNNING” whenever it cannot communicate with the SX.

None of the above are the case. The chip (and basically bug-free) program run fine with a 50mhz resonator or with the SX-Key clock (RUN-RUN).

I also have tried closing all my open applications, etc. as the SX-Key Manual suggests.

Ideas? This is a WIN98 machine.

Also, a handful of times I have accidentally RUN-RUN instead of RUN-PROGRAM when the 50mhz resonator was connected (I quickly powered down and removed it when this happened). Will that damage the SX-Key? I know that the SX-Key needs to be connected without external clock generators for debugging.

Thanks in advance.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Bean

Zoot,
You can program and run WITH the resonator connected (but not with an external clock source like a TCXO or something active).

If you try to DEBUG with a resonator, or with a frequency too high(110MHz I think) or too low (300KHz I think), all of the debugging buttons will be grayed out.

Or you could have a defective SX-Key.

Bean.

Post Edited By Moderator (Chris Savage (Parallax)) : 11/2/2007 3:55:12 PM GMT