Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 Interactive debugger — Parallax Forums

Prop2 Interactive debugger

Hi P2 Testers

This may be useful to you folks wanting to play/test the P2.

It's a interactive debugger that allows you to single step through test code and
view flag status, stack contents, cog/lut and hub contents and IO pin states.

It utilizes the debug interrupt and I have found it a essential tool.

The Debugger interface requires a serial terminal @ 1Mbaud.

Included in the code is a sample test program that tests the new nibble instructions.

All FPGA builds will run the demo.

If you want to discover how some of the P2 instructions work this will give you a clear insight.

Have fun!


«134567

Comments

  • Impressed, you have mastered this increasingly complex P2 instruction set better as I will ever do.

    What happened to your great tool to generate dedicated P1V verilog code, is it still available for download?

    Down-under must be a great and creative place to live in, got some space to spare??
  • Thanks nutson,
    The P1V stuff disappeared when the forum was updated.
    I still use the Verilog generator and have updated it a bit since it was last posted.
    I will try and tidy it up a bit on the weekend and post an update.
    BTW What FPGA boards are you playing with?

    P.S Sorry no space available, all available space filled with FPGA's and P2 related stuff. :)
  • Here's a capture of the debugger's output for the included demo code.
  • I own all the P2 supported Terasic and BeMicro boards, none of the Parallax boards, mainly using the BeMicroCV (the -A2 already has plenty of RAM, pins and LE's for my needs)

    The reason for asking is that I might want to implement a P1V booting from internal memory, and I remember your P1V tool having a way of modifying the ROM.

    My vision of your country is one where you can get fined if you don't carry 5 spare fuel cannisters when going to visit your mother in law in the neighbouring town
  • nutson wrote: »
    My vision of your country is one where you can get fined if you don't carry 5 spare fuel cannisters when going to visit your mother in law in the neighbouring town

    I think you watch too much TV, it's not like that at all. As if we would go visit the mother-in-law. The difference between outlaws and inlaws is that outlaws are wanted.
  • cgraceycgracey Posts: 14,133
    edited 2017-03-09 18:34
    nutson wrote: »
    I own all the P2 supported Terasic and BeMicro boards, none of the Parallax boards, mainly using the BeMicroCV (the -A2 already has plenty of RAM, pins and LE's for my needs)

    The reason for asking is that I might want to implement a P1V booting from internal memory, and I remember your P1V tool having a way of modifying the ROM.

    My vision of your country is one where you can get fined if you don't carry 5 spare fuel cannisters when going to visit your mother in law in the neighbouring town

    I took some old tires I found to the dump and they said I was lucky the Highway Patrol didn't notice, because you can get fined $10,000 for carrying ten tires without a special permit. Nine tires is no problem, though. It's so much safer.
  • cgraceycgracey Posts: 14,133
    edited 2017-03-09 18:32
    nutson wrote: »
    My vision of your country is one where you can get fined if you don't carry 5 spare fuel cannisters when going to visit your mother in law in the neighbouring town

    I think you watch too much TV, it's not like that at all. As if we would go visit the mother-in-law. The difference between outlaws and inlaws is that outlaws are wanted.

    That reminds me of something I heard the other day: "It's so crowded that nobody goes there, anymore."
  • Heater.Heater. Posts: 21,230
    Chip,
    I took some old tires I found to the dump and they said I was lucky the Highway Patrol didn't notice, because you can get fined $10,000 for carrying ten tires without a special permit. Nine tires is no problem, though.
    WTF? I would love to hear somebody defend such a regulation as anything other than totally insane !

    But, hey, I gave up wondering about the sanity of the law when we started to have to pay a levy to the copyright MAFIA when buying blank CD's or hard drives. Or listening to the radio in a taxi cab.

    Or was it before that...?



  • TorTor Posts: 2,010
    edited 2017-03-09 21:35
    I used to work in a country where it was illegal to transport more than a certain amount of data by car.. so whenever I had to bring some HDDTs (High Density Digital Tape, 1") from one site to another I had to bring some paperwork along with the reels. The world is funny sometimes.
  • Heater.Heater. Posts: 21,230
    Ha!

    I do recall a little issue back in the 1980's when a package with a few 360K floppy discs in it, destined for the company I worked for, was held up by customs.

    As an import the customs had to impose some kind of duty on it. The question was, should they value it at the couple of pennies the floppy disks were worth. Or, should they value it at the 10,000 dollars per seat of the licence cost for the software on the disks?

    The world had little idea of what software was at the time.

    Perhaps that has not changed much.

  • TorTor Posts: 2,010
    edited 2017-03-10 09:21
    I didn't even cross any borders.. just driving along a road with 'big' data was illegal, without paperworks. Western European country.. as late as in the nineties. I don't know when it changed - if it has, although I think it has.
  • kwinnkwinn Posts: 8,697
    Tor wrote: »
    I didn't even cross any borders.. just driving along a road with 'big' data was illegal, without paperworks. Western European country.. as late as in the nineties. I don't know when it changed - if it has, although I think it has.

    Pretty hard to enforce silly laws like that now that "big data" like that can fit on tiny micro SD cards. Also says something about the intelligence of people that come up with those laws.
  • Heater.Heater. Posts: 21,230
    I'm wondering which Western European country.

    I have never heard of such a law.

  • TorTor Posts: 2,010
    edited 2017-03-10 17:49
    You can figure it out if you look through some old posts of mine, but I won't name it now - the country doesn't deserve negativity like that. I can assure you the law was real though, I got the paperworks done for me many times over the years. Lots. If the law still exists it would be meaningless of course, you wouldn't be able to travel with your mobile phone.

    But wait -- this is the debugger thread. How did we end up here? What I really wanted to write in this thread is that I'm very impressed with ozpropdev's work. Great idea, great project.
  • Heater.Heater. Posts: 21,230
    Oh come on. Name names. It's all history now. Nobody will care. Every country has skeletons in it's closet.

  • Ok, now back to the original topic....

    I needed a way of expanding some pixel data from 8 bits to 32 bits.
    Here's a neat combinations of P2's instructions that do the job nicely. :)
    	mov	pixels,#$c5
    	rolword	pixels,pixels,#0	'copy words
    	mergew	pixels			'merge words
    	rolword	pixels,pixels,#0	'copy words
    	mergew	pixels			'merge words
    

    and here's the test results from the debugger
    /=========================================\
    |  Propeller 2 Interactive Debugger       |
    |  Version 1.8 - Ozpropdev 6th March 2017 |
    \=========================================/
    
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00004: F60414C5              MOV     $00A,#$0C5
    (? for help) >SWL+
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $00000000 %00000000_00000000_00000000_00000000 #0
    00004: F60414C5              MOV     $00A,#$0C5
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $000000C5 %00000000_00000000_00000000_11000101 #197
    00005: F940140A              ROLWORD $00A,$00A,#0
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $00C500C5 %00000000_11000101_00000000_11000101 #12910789
    00006: F9FC1403              SFUNC   $00A,#$003
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $0000F033 %00000000_00000000_11110000_00110011 #61491
    00007: F940140A              ROLWORD $00A,$00A,#0
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $F033F033 %11110000_00110011_11110000_00110011 #4029935667 #-265031629
    00008: F9FC1403              SFUNC   $00A,#$003
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $FF000F0F %11111111_00000000_00001111_00001111 #4278193935 #-16773361
    00009: FD9FFFFC              JMP     #$FFFFC
    (? for help) >
    

    Note that the debuuger displays the MERGEW instruction by it's real name not it's alias.
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    Ok, now back to the original topic....

    I needed a way of expanding some pixel data from 8 bits to 32 bits.
    Here's a neat combinations of P2's instructions that do the job nicely. :)
    	mov	pixels,#$c5
    	rolword	pixels,pixels,#0	'copy words
    	mergew	pixels			'merge words
    	rolword	pixels,pixels,#0	'copy words
    	mergew	pixels			'merge words
    

    and here's the test results from the debugger
    /=========================================\
    |  Propeller 2 Interactive Debugger       |
    |  Version 1.8 - Ozpropdev 6th March 2017 |
    \=========================================/
    
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00004: F60414C5              MOV     $00A,#$0C5
    (? for help) >SWL+
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $00000000 %00000000_00000000_00000000_00000000 #0
    00004: F60414C5              MOV     $00A,#$0C5
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $000000C5 %00000000_00000000_00000000_11000101 #197
    00005: F940140A              ROLWORD $00A,$00A,#0
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $00C500C5 %00000000_11000101_00000000_11000101 #12910789
    00006: F9FC1403              SFUNC   $00A,#$003
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $0000F033 %00000000_00000000_11110000_00110011 #61491
    00007: F940140A              ROLWORD $00A,$00A,#0
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $F033F033 %11110000_00110011_11110000_00110011 #4029935667 #-265031629
    00008: F9FC1403              SFUNC   $00A,#$003
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $0000A: "Pixels"      $FF000F0F %11111111_00000000_00001111_00001111 #4278193935 #-16773361
    00009: FD9FFFFC              JMP     #$FFFFC
    (? for help) >
    

    Note that the debuuger displays the MERGEW instruction by it's real name not it's alias.

    You are turning each bit into 4 identical bits. I had to look at that for a while.

    I think you could do this, too:

    mov pixels,#$C5
    movbyts pixels,#%00_00_00_00
    mergeb pixels
  • Doh!
    That's better again Chip! :)
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $00008: "Pixels"      $000000C5 %00000000_00000000_00000000_11000101 #197
    00005: F9F41000              MOVBYTS $008,#$000
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $00008: "Pixels"      $C5C5C5C5 %11000101_11000101_11000101_11000101 #3318072773 #-976894523
    00006: F9FC1001              SFUNC   $008,#$001
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    COG | $00008: "Pixels"      $FF000F0F %11111111_00000000_00001111_00001111 #4278193935 #-16773361
    00007: FD9FFFFC              JMP     #$FFFFC
    (? for help) >$
    

  • I'm updating the debugger to support the new V17 _ret_, SKIP, SKIPF and EXECF instructions.
    It now looks ahead to show which instructions will be cancelled/skipped.

    It all seems to work Ok, although I have noticed a slight difference in regards to the instruction following the SKIPF block compared to SKIP and EXECF. I'll keep digging.... :)

    /==========================================\
    |  Propeller 2 Interactive Debugger - V17  |
    |  Version 2.2 - Ozpropdev 29th March 2017 |
    \==========================================/
    
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00004: F547F6FF              OR      DIRB,#$0FF
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00005: FD641C31              SKIP    #$00E
    00006: FD644049              OUTH    #$020
    00007: FD644249 <cancel>     OUTH    #$021
    00008: FD644449 <cancel>     OUTH    #$022
    00009: FD644649 <cancel>     OUTH    #$023
    0000A: FD645E59              DRVH    #$02F
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0000B: FD641432              SKIPF   #$00A
    0000C: FD645049              OUTH    #$028
    0000D: FD645249 <skipped>    OUTH    #$029
    0000E: FD645449              OUTH    #$02A
    0000F: FD645649 <skipped>    OUTH    #$02B
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00010: FD645C59              DRVH    #$02E
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00011: FCDC0A02              REP     #$005,#$002
    00012: FD641C31              SKIP    #$00E
    00013: FD645049              OUTH    #$028
    00014: FD645249 <cancel>     OUTH    #$029
    00015: FD645449 <cancel>     OUTH    #$02A
    00016: FD645649 <cancel>     OUTH    #$02B
    00017: FD645A59              DRVH    #$02D
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00018: FD64342A              PUSH    #$01A
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00019: FD603833              EXECF   $01C
    0001D: FD644A49 <skipped>    OUTH    #$025
    0001E: FD644C49 <skipped>    OUTH    #$026
    0001F: FD644E49              OUTH    #$027
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00020: 05440000 _RET_        OR      $000,#$000
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0001A: FD645859              DRVH    #$02C
    (? for help) >
    
  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    It now looks ahead to show which instructions will be cancelled/skipped.

    Looks nice.
    I thought the ..F ones were the HOPS and the SKIP was the one that did what it says ?
    (which seems the opposite of your tags <skipped> <cancel> ?)
  • My understanding is that a "cancelled" instruction is treated as a "NOP" and still takes 2 clocks.
  • jmgjmg Posts: 15,140
    edited 2017-03-29 05:55
    ozpropdev wrote: »
    My understanding is that a "cancelled" instruction is treated as a "NOP" and still takes 2 clocks.
    Hmm, I would call something that still takes 2 clocks, a skipped opcode, whilst one that needs no time, is cancelled (aka null or zero time).

    On other MCUs with SKIP instructions, they treat the SKIP as a NOP.

    This semantic issue is why I prefer HOP over SKIP, for the variant (fast) version of SKIP.
    Words like HOP make it clearer there was a short jump, clear over the opcodes.
  • SKIP is the one that works everywhere because it just cancels the execution making them NOPs.
    SKIPF advances the PC to actually skip past them and won't work with REP well or HUBEXEC.
  • dMajodMajo Posts: 855
    edited 2017-03-29 07:46
    jmg wrote: »
    ozpropdev wrote: »
    My understanding is that a "cancelled" instruction is treated as a "NOP" and still takes 2 clocks.
    Hmm, I would call something that still takes 2 clocks, a skipped opcode, whilst one that needs no time, is cancelled (aka null or zero time).

    On other MCUs with SKIP instructions, they treat the SKIP as a NOP.

    This semantic issue is why I prefer HOP over SKIP, for the variant (fast) version of SKIP.
    Words like HOP make it clearer there was a short jump, clear over the opcodes.

    I am with @ozpropdev
    cancel = cancel the instruction, transforms it in NOP, still take clocks because NOPs are executed
    skip = jump over (advance PC), thus non needed clocks because the instructions are not executed at all
  • jmgjmg Posts: 15,140
    dMajo wrote: »
    I am with @ozpropdev
    cancel = cancel the instruction, transforms it in NOP, still take clocks because NOPs are executed
    skip = jump over (advance PC), thus non needed clocks because the instructions are not executed at all

    The problem with such re-define of skip, as actually a jump-over, is that others before this have used SKIP to mean the opposite (aka treat as NOP).

    The nett result will be general confusion in the user base.

    Here is one example, of existing MCU terminology usage for SKIP. Note the reach, and cycle times == NOPs.

    http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_CPSE.html
  • just name it SKIPF in the debugger instead of SKIP.

    Like the opcode, no confusion.

    I think cancel is OK because that is what chip is referring too, canceling instruction, but still taking the time because it is a nop now

    Great work @ozpropdev, I wish I understand half of the stuff you know already about the P2.

    Enjoy!

    Mike
  • cgraceycgracey Posts: 14,133
    edited 2017-03-29 10:18
    I got the SKIP/SKIPF/EXECF instructions documented tonight. They are in the Google Doc file linked at the top of the 'Prop2 FPGA Files!!!' thread.
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    I'm updating the debugger to support the new V17 _ret_, SKIP, SKIPF and EXECF instructions.
    It now looks ahead to show which instructions will be cancelled/skipped.

    It all seems to work Ok, although I have noticed a slight difference in regards to the instruction following the SKIPF block compared to SKIP and EXECF. I'll keep digging.... :)

    /==========================================\
    |  Propeller 2 Interactive Debugger - V17  |
    |  Version 2.2 - Ozpropdev 29th March 2017 |
    \==========================================/
    
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00004: F547F6FF              OR      DIRB,#$0FF
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00005: FD641C31              SKIP    #$00E
    00006: FD644049              OUTH    #$020
    00007: FD644249 <cancel>     OUTH    #$021
    00008: FD644449 <cancel>     OUTH    #$022
    00009: FD644649 <cancel>     OUTH    #$023
    0000A: FD645E59              DRVH    #$02F
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0000B: FD641432              SKIPF   #$00A
    0000C: FD645049              OUTH    #$028
    0000D: FD645249 <skipped>    OUTH    #$029
    0000E: FD645449              OUTH    #$02A
    0000F: FD645649 <skipped>    OUTH    #$02B
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00010: FD645C59              DRVH    #$02E
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00011: FCDC0A02              REP     #$005,#$002
    00012: FD641C31              SKIP    #$00E
    00013: FD645049              OUTH    #$028
    00014: FD645249 <cancel>     OUTH    #$029
    00015: FD645449 <cancel>     OUTH    #$02A
    00016: FD645649 <cancel>     OUTH    #$02B
    00017: FD645A59              DRVH    #$02D
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00018: FD64342A              PUSH    #$01A
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00019: FD603833              EXECF   $01C
    0001D: FD644A49 <skipped>    OUTH    #$025
    0001E: FD644C49 <skipped>    OUTH    #$026
    0001F: FD644E49              OUTH    #$027
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00020: 05440000 _RET_        OR      $000,#$000
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0001A: FD645859              DRVH    #$02C
    (? for help) >
    

    Are you still seeing anything weird?
  • Chip
    The only thing that's a bit weird is the SKIP instruction seems to include the instruction after the expected 4 instructions in my example.
    SKIPF works as expected with 4 instructions in group.
    Is it a pipeline "cancel" thing?
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00005: FD641C31              SKIP    #$00E
    00006: FD644049              OUTH    #$020
    00007: FD644249 <cancel>     OUTH    #$021
    00008: FD644449 <cancel>     OUTH    #$022
    00009: FD644649 <cancel>     OUTH    #$023
    0000A: FD645E59              DRVH    #$02F     ' <<<< not expected to execute with skip group above
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0000B: FD641432              SKIPF   #$00A
    0000C: FD645049              OUTH    #$028
    0000D: FD645249 <skipped>    OUTH    #$029
    0000E: FD645449              OUTH    #$02A
    0000F: FD645649 <skipped>    OUTH    #$02B
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00010: FD645C59              DRVH    #$02E    '<<<< Ok. The SKIP instruction above should have done the sme.
    (? for help) >*
    
    

    FYI Be aware my debugger is using the "debug interrupt" to single step.
  • If I'm reading that correctly, then it's working as intended. I think. Your skip mask is $00E (%000001110), so it executes the first OUTH instruction, cancels the next three OUTH instructions, then continues executing subsequent instructions. The DRVH instruction should not be cancelled

    Or are you saying that the DRVH was cancelled?
Sign In or Register to comment.