Can't get the debug to work, all the buttons are greyed out
dave_f
Posts: 10
Hi, this is probably a bit of a rookie question, I've just started usin SXB. Programs compile and run fine, but debug doesn't seem to function. All the buttons related to running or stepping through the program are greyed out. I'm just running the COUNT.SXB example program, with an sx28 chip and an sxKey. Any ideas? I'm assuming I've done something stupid...
Thanks
Thanks
1920 x 1200 - 264K
Comments
do you have a resonator, or any other clock device connected to the SXes OSC pins? Debugging only works when at least the OSC1 pin is not connected to anything else but the SX-Key.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
In any event, it is easier to first try to reload while you wait for a reply.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
The manual says to debug I need: SXkey Rev E or greater, SX chip 9825 or later, no external clock, sxkey connected and sx system powered.
I have all of these (apart from the date code on the chip, how do i check that? Only just bought it though...)
It does mention it may be interfered with by background software, I'll try that, but i'm not running much. any other ideas?
Thanks,
dave
To correctly enter the Debug mode, you need to select "Run" - "Debug" from the IDE menu, or click the shortcut button with the bug, or enter Ctl-D via the keyboard. A dialog with a progress bar should come up with the message "Programming for Debug". Following these steps makes sure that your application program plus some overlay code required for debugging is transferred into the SX you want to debug.
If you had programmed the chip via "Run - Program", and then would launch the Debugger via "Run - Debug (reenter)" the debugger will come up with exactly the greyed buttons because the IDE can't communicate with the SX.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Did you install a pull-up resistor (10 kOhm is fine) between the /MCLR pin and Vdd ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
How many volts are you running to the chip? There are complications if you are running less than 5V. Sounds like your wiring is good, thought maybe you were trying to debug using low voltage.
Dan
the picture you have added to your first post shows the debugger displaying the "Sleep" state. The other two possible states are "Running", and "Idle".
When the debugger is active, the communication between the SX-Key and the SX under test is performed via the OSC2 pin in a "tricky" manner. The SX under test generates a special hi-low pattern on the OSC2 pin, and the timing of that pattern tells the SX-Key which of the thee modes is active on the SX under test. When there is no signal on the OSC2 pin at all, this means the SX is sleeping. So, when the IDE displays "Sleeping" it does not "see" any transition on the OSC2 pin. The reasons for that could be: 1. The SX is really in sleep mode (I don't think this is true in your case), 2. The SX does not get a clock signal from the SX-Key, and 3. The OSC2 input on the SX-Key is defective.
If you have an O-scope on hand, you might check if there is a 4 MHz clock signal on the OSC1 pin. Should there be no clock singnal, it is most likely that the SX-Key is broken. When there is a clock signal, the OSC2 input on the SX-Key is possibly damaged. So, you better contact Parallax support for further assistance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
Kramer - I'm definitely using the SX Key so it should support debug.
Guenther - Hmmm maybe you're right, sounds like it might be a hardware issue. I've included another screenshot which, strangely enough, seems to say it's "running" but everything is still greyed out and nothing seems to run. I don't have an oscilloscope, I'll ask around see if anyone i know has one.
After reading a post of someone with an identical problem at http://forums.parallax.com/showthread.php?p=669372 , i've tried the following:
replaced the lines
with the line
but that didn't help either :-(
The guy on that other post found a solution - he had incorrect firmware. Is there any way to check/remedy this without sending the key back to the manufacturer?
Otherwise I guess I'm just gonna have to return my new toy, and see if they can fix it...
Also, can you get Debug to operate properly with an SXasm program rather than the SX/B? If the problem exists in both, it is more likely that it is a hardware issue.
And, if you want to use the SX-Key IDE help you, you can just select all the hardware features from the DEVICE window and it will create the correct DEVICE directive. Eliminate any duplications.
The Device directive can be confusing. Are you confusing information from the old Parallax Assembler [noparse][[/noparse]Chapter 8] or the prefered and newer SASM[noparse][[/noparse]Chapter 7]? Your STACKX, OPTIONX options are redundant on the SX28, either one alone will do fine. On the SX48/52, that can apparently be completely omitted as the stack is always 8 levels. Many older programs assembly are problematic. Use Guenther's programs for testing in SASM as they are all good. Of course, SX/B isn't that old, but try to make sure some one vouches for the program's lack of problems for trials.· Just a blinking LED may be a better bench test than driving a 7-segment display as the wiring might be in error.
Since you appear to have the ability to program the device, it isn't likely to be the Vdd and Vss are the problem as the power for the SX-Key comes from those pins. And since the two oscillator pins power are used to actual program the E2/Flash with a higher programing voltage, they aren't the problem either. But the power may be drained somewhere once the programing cycle is complete, maybe a small unseen solder bridge or diode in wrong polarity. Last ditch is to try the bare minimum circuit on page 13 of the SX-KEY Development System Manual.
If that doesn't help, I could very well be a hardware failure in the variable oscillator that is on the SX-Key. Does the programed chip function predictably in a simple·test circuit? And does the program run in SXsim? If so, that would begin to point to the SX-Key being the problem.
Please forgive the rambling presentation, but I'm out of ideas as I think this covers nearly all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
Post Edited (Kramer) : 2/28/2008 4:56:24 PM GMT
As has been written elsewhere, *programming* the chip with dirty/poor connections may work, but the higher comm. speeds involved in debugging may fail.
Just another possiblity....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
What you say indeed makes a lot of sense.
Either alcohol or a aerosol product such as CONTACT may clean up the problem. Some people don't like to use alcohol as it is a bit corrosive on metals [noparse][[/noparse]it oxidizes the lead in solder and forms a white lead oxide].
There are oddities in the program's DEVICE directive, but none affect the operation in DEBUG. You don't need to provide both STACKX and OPTIONS as they mean the same thing.
And, that OSC4MHZ designation presumes that the internal ocsillator will be used, not a resonator or crystal. One does NOT select that option when using a 4MHZ resonator or crystal. Also, the FREQ directive must say 4,000,000 HZ or you end up with 50Mhz as a default in DEBUG due to the absence of the FREQ directive. FREQ is only needed for DEBUG. It does nothing during normal operation as the resonator or crystal controls the actual frequency generated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
sorry, I can't agree - the OSC??? directive is completely ignored by the SX-Key IDE when it programs a chip for debugging, so it does not matter how it is set is set in this case.
Also, it is not correct that the FREQU directive must say 4_000_000 Hz, or 50 MHz will be used as default. The IDE will set the SX-Key to generate any frequency you specify together with the FREQ directive. It only does select 50 MHz when your program code does not conatain a FREQ directive at all but you will receive a warning message in this case.
It is important to know that whenever you change the frequency specified with the FREQ directive in your program, it is necessary to select the "Debug" option from the IDE menu, and not the "Debug (re-enter)" option. Debug (re-enter) will change the clock frequency but the SX chip will not be re-programmed, and the debug code attached to the user code in the chip will not be adjusted to the new frequency in this case. The result will be that the debugger comes up showing "Sleeping", or "Running" together with greyed-out buttons due to the wrong timing between the SX-Key, and the chip under test.
Yes, you are right, the FREQ directive is only needed for debugging, but also for the "Run" command. In this case, the SX is programmed for stand-alone operation (without debugging) but the SX-Key will supply the clock to the chip with the frequency specified with the FREQ directive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
With several generations of PDFs through Senix, Ubicom, and Parallax and with two assemblers, it seems easier to rely on the DEVICE window to get it all right rather than the reference material. It does seem to work with SX/B
As always, your knowledge and practical experience is of much greater depth than mine. I just have never have the time as it is a hobby with me.
Still the SX Key Manual is a bit hard to read though it is an important reference. The DEVICE directives were revised and it is up to the reader to sort out which actually were abandoned from the old Parallax Assembler. Also, it doesn't include any introduction to SX/B.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
So - I've solved the problem. The SX-key was FAULTY! It worked for programming, but not for debugging. I just got a replacement from Parallax today (actually my third key - the previous one was faulty as well!) and it worked first time, no problems. I can't believe I wasted a week trying to figure out the bug in the software and it was a hardware problem all along
Thanks for all your help, though!
Cheers,
Dave