Starting the Debug Program

Bill Chennault

All--

How does one actually make Debug DO something? I do not seem to be able to start it after I clike the "bug" icon and the screen shown in the attachment appears, overlaid on my SX/B program.

What am I doing wrong?

Thanks!

--Bill



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.

PJMonty

Bill,

From page 8 of Gunther's excellent FAQ (which can be found by clicking here):

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.

Thanks,
PeterM

Bill Chennault

PeterM--

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.

I think you nailed it. I am using RobotWorkshop's SX48 module which has a 20mhz resonator beneath the socket. I will pull the module and remove the resonator tomorrow.

I'll report back.

Thanks!
--Bill
ps I should get Gunther's book.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.

Ugha

Also check out the Watch command... its quite useful if your used to using BS2's DEBUG command to debug your code [noparse]:)[/noparse]

Bill Chennault

Ugha--

Also check out the Watch command... its quite useful if your used to using BS2's DEBUG command to debug your code [noparse]:)[/noparse]

Thank you for the advice!

I never used the Stamp DEBUG command because my PBasic code was always perfect. (Well, it was very good, at least![noparse]:)[/noparse]·It is only my SX/B code·that well and truly sucks because I am a dummy just trying to learn. Actually, my SX/B code works perfectly and is crystal clear. It just takes up too much RAM because it IS crystal clear. In the microcontroller world RAM is a precious asset.

However, clarity is superior to the RAM asset while learning the fundamentals. After learning the fundamentals, one may then advance to sophisticated techniques and methods that minimize RAM usage much, much easier. The best way to lose a student is to insist on Omega prior to Alpha.

But, you knew all that.

--Bill

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.

JonnyMac

I will lure you to the dark side of proper SX/B programming.... <evil laugh> Subroutines, functions, variables names that make sense -- and your clarity will remain!

Shawn Lowe

Jonnymac, LOL! Something something darkside...something something SX chip. (Reference to family guy) [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe


When all else fails.....procrastinate!

Bill Chennault

JonnyMac--

Dark side? Nah! As soon as I learn the fundamentals, you will lead me to the light!

My Bluetooth setup works well enough for me to begin practicing with RAM saving functions and subroutines. Of course, I already thoroughly know about these things, but have never implemented them in SX/B. And, quite frankly until you pointed it out, I had not realized the space savings one would realize when using a compile-in-place language like SX/B.

--Bill

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.