BMA Multi-COG PASM Debugger V1.91 Now Available
jazzed
Posts: 11,803
Here is a simple on chip PASM debugger. The BMAdebugger does not use a GUI.
Debugging is most effective when used in conjunction with BSTC compiler .list files.
You do not need previous versions. The latest version is the one to download/use.
Debugging is most effective when used in conjunction with BSTC compiler .list files.
- Small and simple on chip PASM debugger
- No Windows or other PC program required
- Feature rich command set
- Multi-COG debug ability
You do not need previous versions. The latest version is the one to download/use.
BMADebugger Version 1.91: Compiles with Propeller Tool Can still be used with SPINSIM with minor edits.
BMADebugger Version 1.9: new features * fixed: bug where jmp instruction would not clear wz. * fixed: bug where djnz was post decrementing. djnz pre-decrements. * changed: made multicore example more interesting. * changed: default baudrate to 115200. * changed: rx method so either $a or $d indicates end of line.
BMADebugger Version 1.8: new features * added: animate command * changed: go command so it prints breakpoints if hit within a second. * changed: iterate command so it prints correct D values. * changed: default xinfreq 5_000_000
BMADebugger Version 1.7: new features
* added: support for multi-cog debugging.
* added: task command "tx" which sets the COG task to debug.
* updated: demo program to show how multi-cog debugging is started.
{{
Example
}}
con
_CLKMODE = XTAL1 + PLL16x
_XINFREQ = 6_000_000
obj
bu : "BMAutility" ' BMA debugger utility routines
s : "FullDuplexSingleton" ' required for single stepping with main/stepDump
pub main | n
{{
This is the main debugger entry point.
}}
waitcnt(clkfreq*1+cnt) ' wait a second for user to start terminal
s.start(31,30,0,115200) ' start the default serial interface
readptr := @readbuf
' bu.debug(@entry,@command) ' start single cog task debugger utility
bu.taskstart(@entry, @command, string("Main Task"))
bu.taskstart(@entry2,@command, 0)
bu.start ' start multi cog task debugger
repeat
dat
'-------------------------------------------------------------------------------
' stepper and test code ... the entry point for your PASM
'
entry org 0 ' THE ENTRY ORG LABEL
long 0 [noparse][[/noparse]8] ' debugger stub space ... if no debugger, these are nops
' your PASM goes here.
'-------------------------------------------------------------------------------
dat
'-------------------------------------------------------------------------------
' stepper and test code for second cog "task"
'
entry2 org 0 ' THE ENTRY ORG LABEL
long 0 [noparse][[/noparse]8] ' debugger stub space ... if no debugger, these are nops
' your PASM goes here.
'-------------------------------------------------------------------------------
BMADebugger Version 1.6: new features * added: next command "n" which steps over call/jmpret subroutine bodies. * added: iterate x command "ix" which steps through instructions showing execution at PC = x. * changed: list command "l" without arguments prints PC + 16 lines or prints from last list end PC + 16.
BMADebugger Version 1.5: list and special registers update * changed: list command "l" without arguments prints PC + 16 lines * changed: no longer necessary to start debugger before starting utility * fixed: special register values now print correctly in stepper list output
Version 1.4: Bugfix for DJNZ and NOP instruction detect. * Essentially, this is the same as version 1.3 * added: Example of tight HUB buffer write with djnz.
Version 1.3: Some fixes and enhancements. * added: StefanL38's list/step explanation to BMAdebugger_Demo.spin * added: Expanded command user guide to BMAdebugger_Demo.spin * added: "R" command that allows restarting a COG * added: "f" command for filling HUB data with various type width values * added: "h" command for dumping HUB data with various type widths * added: "?" for only syntax/command help summary * changed: Special register addresses $1f0-$1ff in listings now show as mnemonics * changed: "p" commands now show the COG special registers (not shadow) * changed: "s" command lets you change the COG special registers (not shadow) * changed: Method for calling the debug utility has changed * fixed: "c" command was totally broken; works now
Version 1.2: Added real-time run to breakpoint * changed: debugger stub needs 8 words now for realtime run to breakpoint. * changed: "L x n" to "l x n" and "l" to "L" ... upper case lists all * changed: "D x n" to "d x n" and "d" to "D" ... upper case dumps all * added: "PC xcogadr Ok> " so it's easier know where we are during debug * changed: Method for including the debug stub has changed.
Version 1.1: Added debug features
* added breakpoint toggle and clear.
- "b x" toggles breakpoint at address x.
- "c" clears all breakpoints.
* added "D x n" to allow cog dump of n longs from register x.
* added "l" print disassembly list for entire COG.
* added "L x n" to allow disassembly list n instructions from address x.
* added "s x n" to allow setting register at address x with value n.
* added code so that "z" prints Z and C states.
* debug step now shows full and correct resultant state of destination register.
* debug result destination register is delimited by "D=".
* added current instruction word to step list temporarily for confidence.
Comments
Go on then, what was so terriable with V0.3 that you deemed that it should never see the light od day ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 8/23/2009 6:53:19 PM GMT
If only that grass would stop growing, or the beer can powered mover would fire up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
> in the spirit of Mr. Rogers
" Can you say no bugs ?"
LOL - I'm sure I've posted here before about one of the (huge) programs we had to maintain from a long-departed coder. The guy happened to be enamoured with Mr.Rogers. So he named all of his routines after something in the 'neighborhood'.·· Mr. Rogers still haunts my nightmares.
Seriously... thanks for your efforts ... I'll try it out as soon as I get a breather!
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please download V1.0, try it out, and provide feedback. Bugs will be fixed when identified. Feature requests will be considered.
Howard, this is a different program. SPUD will integrate spin and cog selectable pasm debugging into one package.
If you look hard enough, you can find the real meaning of BMA in the source
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 8/27/2009 3:32:41 AM GMTI've enhanced the features of the BMA debugger. They are described above and are in the V1_1 .zip package.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 8/27/2009 3:32:59 AM GMT▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Also, I will create a Java Application (cross platform) GUI version of this later to make debugging easier.
Note that you the way the stub is added has changed. Now you only need to add long 0 [noparse][[/noparse]8] to the top of code for debug. No more copy paste the stub, the debugger will do that for you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I have done some PASM-programs a some months ago.
and I have some experience in 6502 ASM a long time ago.
If I start your Democode I can single-step through the code.
I'm almost completely stumped by the output
I'm sure by taking 2-3 days 12 hours a day time I can figure out what all the debug-output means.
But I would like to ask if you can post an explanation of it all
concrete questions
1.) what is the meaning of "6CFFE801" ?
2.) what is the meaning of "D:" ?
3.) what is the meaning of "1F4" ? (COG-RAM adress ??
4.) what is the meaning of "00000000 " (part of the long value containing the xor-value which bits ?)
5.) what is the meaning of "S#001" ? (# immediate value ?, 001 the value itself ? what is the "S" for ?
6.) what is the meaning of "D=1F4" ? another COG-RAM adress ? which one ?
7.) what is the meaning of "00000001" ? (again the value "#1" from the sourcecode ?
as you can see from these many questions I understand almost nothing.
I would find it very ineffective to check all my assumings by a lot of try and error-experiments
with variing the democode
So I would really appreciate if somebody could answer my questions
best regards
Stefan
Thanks for taking time to try this out. I'll answer questions in line and add the Q&A in some form to the demo source.
1.) what is the meaning of "6CFFE801" ? A. "6CFFE801" is the instruction for "xor $1f4, #1" ... otherwise known as "xor OUTA, #1" 2.) what is the meaning of "D:" ? A. "D:" is the destination field of the before the instruction executes. 3.) what is the meaning of "1F4" ? (COG-RAM adress ?? A. Yes, it is the address of OUTA ... note to self, use mnemonics where possible. 4.) what is the meaning of "00000000 " (part of the long value containing the xor-value which bits ?) A. "00000000 " is the value of D:address before the instruction executes. 5.) what is the meaning of "S#001" ? (# immediate value ?, 001 the value itself ? what is the "S" for ? A. "S#001" is the immediate value the instruction will use when it executes. "S 001" would be the source address for the instruction to use. 6.) what is the meaning of "D=1F4" ? another COG-RAM adress ? which one ? A. "D=1F4" is the destination address after the instruction executes otherwise known as OUTA. 7.) what is the meaning of "00000001" ? (again the value "#1" from the sourcecode ? A. "00000001" is the result in the D register after the instruction executes. > as you can see from these many questions I understand almost nothing. Actually, from your questions, you appear to have guessed quite a bit.
CheersEdit: 1F4 is OUTA not DIRA
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 9/12/2009 8:13:25 PM GMTthank you very much for the explanation
I would like to make a suggestion how to comment this in the file
explanations (1)(2) (3) (4) (5) (6) (7) (8) (9) (10) (11) PC 00A Z : mov A0E85011 D:028 00000000 S#011 D=028 00000000 C PC 013 . : mov A0BC5028 D:028 04C4B400 S:028 04C4B400 D=028 04C4B400 Z original line of code in the propeller-tool if_z mov t0, #$11 mov t0, t0 (1) program-counter (2) flag-condition (at PC 00A "if_z" at PC 013 ".") (3) mnemonic of the PASM-command (at PC 00A "mov" at PC 013 "mov") (4) 32-bitvalue of long at PC (at PC 00A "A0E85011") (5) Destination-adress of command BEFORE executing the command (at PC 00A "028") (6) Value of destination BEFORE executing the command (at PC 013 "04C4B400") (7) Source_adress of the command (at PC 00A "S#011" at PC 013 "028") [noparse][[/noparse]S#011] means immediate value NO dest-adress (8) Value of Source (at PC 013 "04C4B400" (9) Destination-adress of command AFTER executing the command (at PC 013 "028") (10) Value of destination AFTER command has executed (at PC 00A no value as it is immediate at PC 013 "04C4B400") (11) status of C and Z-flag (if mentioned flag is SET (at PC 00A "C" carry-flag is set at PC 013 Z-flag is set)did I explain that right ?
your demo is written from a POV of functionality of the code (blink LEDs)
to explain the debug-output I think it would be very useful
to have some lines of code that show changes in EVERY columm that can easily be calculated in anyones head
have three "variables" like "t0"
load them with values $10, $05, $03
and code something with command "add" and "sub" where source and destination have different but easy to find values
a second example could show self modifying code
an explanation like this would drop down the hurdle for learning PASM to 1 feet (as anybody can easily step over it)
best regards
Stefan
You have explained it very nicely. If you don't mind I'll include a version of this in the next release.
I'll come up with more examples to include in the package. If you have something else to contribute, I'll add it too.
Thanks for your effort Stefan!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
Very Nice indeed. When I did my debugger, I only re-displayed the destination if it was changed. Makes it easier to see where something is changed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Previously the "pr" command would only print the special register shadow values. This has been corrected ... now you can see the COG value of DIRA/OUTA for example; you can still look at the shadow values with the dump and list commands. I added a COG restart command for times when the go command causes the debugger to lose control. This allows user to reload the debug session without having to re-download the code. The clear breakpoint command was horribly broken [noparse]:)[/noparse] Other details have changed: see the top post. I've tested all commands before posting V1.3 to make sure they behave the way are described in the expanded user guide.
Ray (@Cluso99), I think each of us has preferences. I found only printing changes to be somewhat annoying because I didn't have a "step-record" of the changes to look at during debug. Of course a GUI would not have a step-record either unless the underlying "debug server" contents are captured in an optional console window.
There are many wonderful things that can be done and options that can be satisfied with a GUI that an on-chip debugger can not do. This is why I'm ultimately committed to writing a GUI client ... just not today [noparse]:)[/noparse]
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
I will give it a try when I receive back my hardware
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
BMA Debugger V1.6 is now available. New commands:
n : steps over call/jmpret subroutine bodies. ix : steps through instructions until keyboard hit showing execution at PC = x.
See the demo file for full command help. BMA is run completely on the Propeller - a GUI is not provided or planned.The tool is most effective when used in conjunction with the BSTC compiler/list output.
The task command lets you switch between cog debug sessions.
The cogs can be run in real-time and stop at break-points or be stepped.
Only the active debug task can be stepped or dumped.
Tasks can be named at startup for user convenience.
The old single-cog debug still works as task 0 if started the old way.
Here is a sample console session with two cogs.
Oh, that is dead sexxxxxxxxxxxxxxxxxxxy. Well done indeed!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
The BMAD PASM Multi-COG debugger is updated to version 1.8 in the first post.
Added animation, fixed some bugs.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Fixed in version 1.91. Propeller Tool is also limiting
than you very much for the comparison table.
best regards
Stefan
I have an object written in PASM that when i debug with PSAD seems to be working fine, however when I connect it to the driving spin program, It crashes and burns! Wil BMA allow me to see what is happening in my object when I start it and pass the variables to it from the top spin file?
Thanks
Jim
Jim,
The approach I take is to breakup the SPIN program into 3 pieces in the first PUB function.
Here is a simple example of splitting up a program.
CON _CLKMODE = XTAL1 + PLL16x _CLKFREQ = 80_000_000 OBJ s : "FullDuplexSingleton" d : "BMAUtility" PUB main ' ' 1. start the serial object ' s.start(31,30,0,115200) waitcnt(clkfreq+cnt) ' wait a second for user to start terminal ' ' 2. cognew the rest of the program that will use the PASM ' cognew(myprogram, @stack) ' ' 3. start the debugger ' d.debug(@entry,@command) ' ' if we don't want the debugger to run replace steps 2 and 3 with this ' cognew(@entry,@command) myprogram VAR long stack[100] ' stack space for myprogram PUB myprogram ' main program loop goes here repeat command := 1 repeat while command VAR long command long data DAT '------------------------------------------------------------------------------- ' test code ' entry org 0 ' THE ENTRY ORG LABEL long 0 [8] ' debugger stub space ... if no debugger, these are nops '------------------------------------------------------------------------------- ' main cog program loop ' CmdDone ' ' let the user program know the command is done ' wrlong zero, par CmdLoop ' ' wait for a command ' rdlong cmd, par tjz cmd, #CmdLoop ' ' process command ' PASM takes action on command request then jumps back to main loop ' jmp #CmdDone zero long 0 cmd res 1BTW: PST has no way to control input echo to the console, so you will see command input echoed there. It is better to use a program that doesn't echo. I've attached the "uterm" .net program that works nicely in a "cmd" window.
I use uterm with BSTC which provides a very nice listing to help with debugging.
BST can be used for all of this debugging stuff too.