Cluso's LMM Serial Debugger (hubexec serial driver for your code with char, string, hex, etc output)
Cluso99
Posts: 18,069
in Propeller 2
Attached is my LSD (Cluso's LMM Serial Debugger).
It can be included in your code so that you can output to the serial port (P62 & P63) using smart pins, by using simple calls in your program. It is a re-hash of my earlier LSD for the old P2 (2013) pre P2Hot.
Currently I am using the internal fifo/stack for calls. I later plan to save the stack, but this is not implemented yet.
Currently COG RAM $1E0..$1EF is required for LSD parameters.
Examples of the calls are included.
The serial driver remains separate from the main debugger so that alternative I/O drivers will be able to be substituted later.
It can be included in your code so that you can output to the serial port (P62 & P63) using smart pins, by using simple calls in your program. It is a re-hash of my earlier LSD for the old P2 (2013) pre P2Hot.
Currently I am using the internal fifo/stack for calls. I later plan to save the stack, but this is not implemented yet.
Currently COG RAM $1E0..$1EF is required for LSD parameters.
Examples of the calls are included.
The serial driver remains separate from the main debugger so that alternative I/O drivers will be able to be substituted later.
zip
7K
Comments
Not everything is running yet, although it was on the original P2 so it's only a matter of conversion time
=== Cluso's P2v10a Debugger v.102? === ------------ Help ----------------------------------------------------------- [[#]xxxxxxxx][.yyyyy][,[$]ccccc]z[m]<cr> <-- command format -----1----- ---2-- -----3--- 4 5 --6- <-- parameter no. ...where... 1: # xx xx xx xx = an immediate byte/word/long value (spaces optional) # xxxxxxxx = stored as a long (spaces mean little endian order) xxxxx = from address (hex) where <$200 is in cog, else hub 2: . yyyyy = to address (hex) where <$200 is in cog, else hub 3: , $ ccccc = (hex) count/length , ccccc = (decimal) count/length 4: z = (single char) command ( ? - G L M P Q V ) 5: m = (single char) command modifier (command specific) 6: <cr> = <enter> key ? HELP: Show this text - STORE: to {addr1} the following {byte(s)}|{word(s)}|{long(s)} G GOTO: Goto cog {addr1} (if {addr1} omitted, return to user program) COGINIT {addr1}:{par2} for COGID {m5} {m5} omitted = this cog; 0..7 = cog 0..7; * = next avail cog L LIST: from cog/hub {addr1} to {addr2} from cog/hub {addr1} for {count3}|{length3} L = L0 = bytes + ascii; L1 = bytes; L2 = code; L3 = long M MOVE: from cog/hub {addr1} to cog/hub {addr2} for {Count3}|{length3} FILL #{immediate1} to cog/hub {addr2} for {count3}|{length3} P PORT: Show port status Q QUIT: Quit user program and run the Rom Monitor V VIEW: View the variables (special for Sapieha) ------------------------------------------------------------------------------<teaser>
Here is a link to what I had running on the original P2 (that I am now converting)...
http://forums.parallax.com/discussion/146688/lmm-p2-debugger-uses-serial-tx-rx-for-debugging-single-cog-programs
and a few snippets of that output...
Here is a listing from cog ram (hub ram can also be done)
Here is the disassembler output from the old Rom Monitor that Chip did
_hubList working for _MON/_SMON/_LONG now working.
COG, LUT & HUB (from $400+) can be listed.
Here is a sample of the output...
I will be reducing the usage of cog memory later.
Much of the disassembler is now working. Here is a sample of the output..
Most instructions disassembled (except ALTI..SCL). Please report any errors.
Nexton the list is to work as a monitor (ie read operator input to display hub/cog/lut)
Here is a sample output... (note there is currently a debug char being displayed before the operands)
For the LIST command, previously I used...
[[#]xxxxxxxx][.yyyyy][,[$]ccccc]z[m]<cr> L LIST: from cog/hub {addr1} to {addr2} from cog/hub {addr1} for {count3}|{length3} L = L0 = bytes + ascii; L1 = bytes; L2 = code; L3 = long Some examples of LIST use would be 100,10L0<cr> ' list bytes+ascii from cog $100 for 10 (decimal count) lines 100,10L1<cr> ' list bytes from cog $100 for 10 (decimal count) lines 33333,10L2<cr> ' list code (disassemble) from hub $33333 for 10 (decimal count) lines 33333,10L3<cr> ' list long from hub $33333 for 10 (decimal count) linesMy thoughts are that it would be preferable to put the LIST command first, and use an alpha descriptor rather than numeric, like..
z[m][[#]xxxxxxxx][.yyyyy][,[$]ccccc]z[m]<cr> L LIST: from cog/hub {addr1} to {addr2} from cog/hub {addr1} for {count3}|{length3} L = LL = bytes + ascii; LS = bytes; LC = code; LD = long Some the above examples of LIST use would now become LL100,10<cr> ' List Long (bytes+ascii) from cog $100 for 10 (decimal count) lines LS100,10<cr> ' List Short (bytes) from cog $100 for 10 (decimal count) lines LC33333,10<cr> ' List Code (disassemble) from hub $33333 for 10 (decimal count) lines LD33333,10<cr> ' List Dump from hub $33333 for 10 (decimal count) linesWhat are your thoughts/preferences?
I will go with something similar and see how it goes. It is easy enough to change if necessary anyway.
All opcodes should be successfully decoded excluding the WR/WM/RDxxxx instructions using PTRA/PTRB. The PTRA/PTRB is not decoded, but shown as an immediate hex value.
Bug reports welcome
Please report any bugs
In writing the ROM code, I made a few modifications to the instruction coding, as you suggested, to get things grouped better. After I do a full compilation, we'll have a version 11, which will have the final encodings.
I am not sure whether you found a couple of others. I will update here shortly.
Here are how I had to group the instructions for disassembling. Just ask if you cannot follow the grouping. Just ignore the 8th char of each instruction. Where there are instructions that are broken down, they are marked as "*******" or "**alt**" etc.
It was mainly the order of the group 2 opcodes so that similar decodings are grouped together.
Not sure if you did the change to the group4 (POLLINT etc with no operands) to use D=001000000 so they fall out of being in the middle of group 2 (currently between SETHLK and SETINT1).
While the SETNIB-ROLWORD & SETBYTS-MOVBYTS didn't quite fit the mould, they really fit nicely where they are.
Do you think one needs a different name???
Do you feel like dropping some debug code into the ROM?
I have RX and RXSTRING working so I would just need to update the instruction table and we could call all these routines I have in my debugger from user programs???
No. The assembler will pick which one.
If the 2nd operand is 'S', instead of '#', or D is not $1F6..$1F9, then it must be the 'CALLD D,S/#rel9'. Otherwise, it's 'CALLD reg,#abs/#rel'.
Here's the problem:
The ROM can only be reliably read at boot time, since other cogs doing CLKSET instructions can mess up the ROM address counter. It uses the CLKSET instruction to read the ROM, one byte at a time. The idea is only to read the data into $00000..$03FFF and then do a 'COGINIT #0,#0' to execute the cog program starting at $00000. I could change the way that it works, somewhat, so all cogs could access it, but I don't know that there's much benefit to that.
This means that the ROM image is fleeting, and not permanently mapped into the RAM, unlike Prop2-Hot. It also means you get more RAM. Being there only at boot time means that you can't just call up a debugger any time from ROM. That could change. Or, the ROM could become maybe only 2KB, instead of 16KB, because that's all we actually need. Well, 4K would afford a nice monitor, in case no fancy tools are available and you just want to shoot it an image via text, or poke around.
Here is my latest code v0.110 which has RX and RXSTRING working with a hub buffer. <bs> works to edit, echo char too.
The user cog code can be removed as its only a test. All code runs in hubexec mode. Currently requires cog $1D0-$1EF for registers until I save on a hub stack.
On an early version you had a ROM monitor built-in. I had presumed you were going to do similar for this version.
Would it be possible on bootup to load the internal ROM into hub somewhere? That way, if the user wants it, its there. Otherwise he can overwrite it with code from the external SPI Flash.
If so, could you just place this in the pseudo ROM and load up on boot. At least it will go a long way to help debug the P2 even if its not in the final P2 ROM???
I will take a look at how big it is - what is pnut option to see the listing?