PASD problem
Harley
Posts: 997
I'm having some strange problem with PASD, version 4. Like it doesn't work.
Attached is my Spin file. I have the 'cog to debug' last of 4 cogs; but PASD wants to start stepping through the middle of a first cog's code! It steps for several instructions, then jumps to the DAT line and 'hangs' there. This version of PASD has worked months ago.
I have a number of lines commented out; thinking it was 'out of cogs' and was in the midst of some changes. Now want to debug the cog code and NO GO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Attached is my Spin file. I have the 'cog to debug' last of 4 cogs; but PASD wants to start stepping through the middle of a first cog's code! It steps for several instructions, then jumps to the DAT line and 'hangs' there. This version of PASD has worked months ago.
I have a number of lines commented out; thinking it was 'out of cogs' and was in the midst of some changes. Now want to debug the cog code and NO GO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
spin
70K
Comments
PASD is not really made for several cogs in one spin file. Earlier versions accidentally excuted the last cog.
In version 0.4 I have changed PASD to execute only the first cog, which is more expected by a user.
I have attached your source with included PASD handling.
Your way of merging the cogs is dangerous. You should not have RES instructions in the middle of Assembly code.
This confuses not only PASD, but also may not work correctly.
Andy
I will study what's changed in PASD ver: 0.4. My understanding was that each block of assembly had to have its separate RES 'instructions'. So they can be combined; probably at the end of the PASMs, yes?
Thanks, Andy, for the heads up on the rather big change to PASD. I assumed it just cleaned up ver: 0.3; my bad.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
OK, putting the PASM block first, rather than last as used to be, PASD now works.
But, I'm wondering WHERE was the info about this change documented? The user manual is still dated Version 1.1 09/04/07 and in the PASD folder I find no 'read me'.
Where may one find info on this latest version? Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
The manual says: "PASD currently only supports debugging a single assembly module executing in a single COG."
There is no word about several DAT sections and several cogs in 1 Spin file, so no need to change the manual.
The changes to 0.4 are mostly in the GUI (saving the Viewer windows). Because I had the problem of several cogs in one source file on my ToDo-List, I also changed that, but it's still experimental and may have some issues.
Andy
I never thought about needing to debug more than one cog at a time. However, it is obvious a user's program might use many more than one PASM cogs, no?
I have one project with has a pcb with two Props (because of I/O need of more than 32 interface signals) and each Prop uses several cogs because of the speed of the interface. So there is a high need IMHO for a debugger that can work with ONE of several PASM cogs at a time. Earlier versions of PASD were used on that project to verify each instruction was working properly in the system.
I still like PASD. Once working, then Viewport allows for debugging these PASM cogs at normal speeds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Why won't PASD allow using a breakpoint a second time? (Maybe I'm expecting it to run differently.)
A breakpoint is set, then Run key pressed and it stops at the breakpoint. OK, here's where it goes 'wrong'. I would expect to be able to either step a bit then do another Run and then hit the breakpoint again, but it just keeps running. NO BREAKPOINT on further attempts to breakpoint.
I note, if on the first breakpoint stop, the Run key lets it 'step' to next instruction. But a next Run never hits a breakpoint again. Am I expecting something not intended? Since I'm trying to debug a loop, I'd expect to hit the breakpoint within the loop EVERY TIME. Is that expecting too much?
Further, once Running, a second press of Run stops it, but if press Step or Step Over, it will step, but pressed a second time it resumes Running. I'd expect Step or Step Over to not allow it to run, no matter how many times they are pressed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 1/31/2010 8:38:50 PM GMT
As you expect, PASD should stop every time it it hits a Breakpoint. If you have one in a loop, it has to stop every loop.
After stopping, the first Run command only makes a SingleStep a second Run runs then the code again. You can also single step thru the code after a Break and press Run later.
If it not stops every loop, I guess the loop is left, or this instruction with the Breakpoint is not executed because of conditions. Perhaps you can blink a Led or watch a pin with a scope to test if the loop is really executed.
When running you should only press F6 for stopping, other Keys should have no effect, but they send some bytes over Serial connection, this can have an effect depending of the debugged code.
I have noticed the Pin viewer can have problems, it stops showing the Pins but the Propeller is still running.
Andy
I finally found I had an instruction without a '#' character which caused a wild jump address, and prevented PASD from seeing the breakpoint after the first break.
Now I'm getting a 'crash' which clobbers the .binary file. And finally have found a improper value for one of the variables after that. Now the ball is in my court for me to find out why that is happening. After several iterations around the major loop, something isn't right. That's not PASD's fault.
I do have another question. I note when the binary file is loaded, there is a red highlighting in the first unitialized data (variable) line. And it remains there. Does that have a meaning? That also is the variable which is apparently being clobbered. I didn't note any reference in the user manual about that (I wasn't trying to set a breakpoint).
I do find the RUN operation working OK now. It was that '#' missing character that was making it appear to not work correctly. There are many, many instructions involved in the three loops I have; which make it slow to debug the errors out of this seeming short code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
If normal assembly instructions follow a RES instruction, then the RES line is highlighted in red. If you have only 1 cog code in a file, then this would be an error. In your case the following code goes in another cog, so it's not an error, but PASD is not intelligent enough to detect that. You can just ignore this red RES line(s).
Andy
Good, that red highlight is due to more than one cog. Understand. Will add that to my copy of the manual.
I also understand the difficulty to include documentation of ALL cases a user would need to know of such details.
Side question, do you and Eric Moyer still work with each other? Cool, if so. Hope he's aware how much PASD users appreciate this debugging tool.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (steprog) : 2/13/2010 9:58:37 AM GMT
T o n y
I have experienced exactly what you are describing, and somehow discovered that the following procedure works...
Your code must include the following:
OBJ
dbg : "PASDebug" '<---- Add for Debugger
PUB main
dbg.start(31,30,@MainProg) '<---- Add for Debugger
cognew(@MainProg, 0)
PUB stop
if Cog
cogstop(Cog~ - 1)
and the following kernel right after the statement:
MainProg ORG 0
long $34FC1202,$6CE81201,$83C120B,$8BC0E0A,$E87C0E03,$8BC0E0A
long $EC7C0E05,$A0BC1207,$5C7C0003,$5C7C0003,$7FFC,$7FF8
.... not sure iif it can reside anywhere else, but I suspect not.
While in the PropellerTool window, press F10 to compile the program.
Then from your desktop click the PASD.exe icon to start the debugger.
Then... and this is not documented... I need to click in the white blank code space of the debug window (in my case to the right of the PropTool winwdow) and press F2.
That loads the program into the debugger window, and you're set to go.
F5 then starts execution, F6 stops it, and F8 single steps.
Normally I also enable the COG Ram Viewer to wath variables change when single stepping.
Cheers,
Peter (pjv)
Also, need to create a binary file:
Run -> Compile current -> View -> Save Binary File -> Save
A bit of a chore to remember including this part.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
I have never done that.
Does pressing the F10 take care of that automatically?
@stepprop..... now I don't know what's going on. What I described I do all the time, and it works for me!
Cheers,
Peter (pjv)
What version of PASD do you have?
If you use a COM number greater then 6, you need version 0.5, downloadable here:
www.insonix.ch/propeller/prop_pasd.html
Some other tips:
- be sure you run no terminal that occupies the COM port
- select the right Tab in PropTool
- let the PropTool window open while using PASD
- you need no binary, just press F10 in PropTool to load the Prop, switch to PASD and press F2 to transfer the source.
(or activate PASD and press F11 to do both steps in one).
- later you just need to minimize PASD, edit the source code, load it with F10, and restore PASD - the new version should be
transfered to PASD automatically.
Andy
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
If you have several objects for a project, then the file with the Assembly code to debug must be selected in PropTool
when you press F2 in PASD.
The Debug-Demo has all in one file, so this should not be the problem.
The error message you described comes when PASD has no connection to the cog, this can have several reasons:
- The Serial (USB) connection does not work (wrong COM port set?)
- The clock settings in the source code are wrong (wrong baudrate)
- The Debug Kernel is not in the cog code to debug
Andy
Greg