Shop OBEX P1 Docs P2 Docs Learn Events
PNut/Spin2 Latest Version (v44 -Data Structures Added, New Methods for Memory Testing/Manipulation) - Page 50 — Parallax Forums

PNut/Spin2 Latest Version (v44 -Data Structures Added, New Methods for Memory Testing/Manipulation)

1474850525363

Comments

  • Wuerfel_21Wuerfel_21 Posts: 4,351
    edited 2022-03-05 20:36

    Just noticed a slight issue with the debug system: if memory is being corrupted, another cog running code from hub (including a Spin cog idling in infinite REPEAT) can and will kill the debugger in strange ways, with a bit of delay from where the issue is actually located. I get that the serial pin could get misconfigured, but how can it ever start trying to print an infinite array of zeroes? (there isn't a debug code with a ubin_byte_array in the code, so it's not like it's just triggering some other BRK - actually, are out of range BRKs handled?)

    [...]
    Cog1  DSP write dsp_addr = $5D, sp_memv = $03
    Cog1  DSP write dsp_addr = $5C, sp_memv = $00
    Cog1  DSP write dsp_addr = $0C, sp_memv = $3F
    Cog1  DSP write dsp_addr = $1C, sp_memv = $3F
    ÿ;[@ՂúԆø?Ԗü>Ԗüõÿ;û䘠= %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, [...]
    
  • Wuerfel_21Wuerfel_21 Posts: 4,351
    edited 2022-03-05 21:12

    Unrelatedly, here's a genuine compiler oddity:

    PUB main()
    repeat
    DAT
            orgh
            byte "START"
    label
            byte 0[$10000+(@label-$)]
            byte "STOP"
    

    If you look at the binary file, there should be $10000 zero bytes between START and STOP, right? But there aren't. It seems there's a discrepancy between labels and the assembly PC. Oddly enough, if I remove the @, it seems to do the right thing? WHAT? So there's some intentional difference there? The principle of least astonishment sends its regards, for I am astonished.

  • JonnyMacJonnyMac Posts: 8,910
    edited 2022-03-06 17:53

    [deleted]

  • @Wuerfel_21 said:
    Unrelatedly, here's a genuine compiler oddity:

    PUB main()
    repeat
    DAT
            orgh
            byte "START"
    label
            byte 0[$10000+(@label-$)]
            byte "STOP"
    

    If you look at the binary file, there should be $10000 zero bytes between START and STOP, right? But there aren't. It seems there's a discrepancy between labels and the assembly PC. Oddly enough, if I remove the @, it seems to do the right thing? WHAT? So there's some intentional difference there? The principle of least astonishment sends its regards, for I am astonished.

    I'm not sure what you are trying to achieve with +(@label-$) but I think "$" doesn't have any valid context except in Cog RAM (as the address of "here" in PASM code) and, of course, as the hex indicator leading hexadecimal values; however, you orgh instead of orgc at the top of your code (origin hub rather than origin cog) so who knows what $ will end up equating.

    If you just change that line to be byte 0[$10000] then you indeed get $10000 zeros in-between "START" and "STOP."

  • @"Jeff Martin" said:

    @Wuerfel_21 said:
    Unrelatedly, here's a genuine compiler oddity:

    PUB main()
    repeat
    DAT
            orgh
            byte "START"
    label
            byte 0[$10000+(@label-$)]
            byte "STOP"
    

    If you look at the binary file, there should be $10000 zero bytes between START and STOP, right? But there aren't. It seems there's a discrepancy between labels and the assembly PC. Oddly enough, if I remove the @, it seems to do the right thing? WHAT? So there's some intentional difference there? The principle of least astonishment sends its regards, for I am astonished.

    I'm not sure what you are trying to achieve with +(@label-$) but I think "$" doesn't have any valid context except in Cog RAM (as the address of "here" in PASM code) and, of course, as the hex indicator leading hexadecimal values; however, you orgh instead of orgc at the top of your code (origin hub rather than origin cog) so who knows what $ will end up equating.

    If you just change that line to be byte 0[$10000] then you indeed get $10000 zeros in-between "START" and "STOP."

    The point is that if there is other data between label and that slightly odd line, the fill count will evaluate such that that it zero-pads it to $10000 bytes. As said, it does seem to work when I use byte 0[$10000+(label-$)] (without the @)

  • AribaAriba Posts: 2,682

    @Wuerfel_21 said:
    ...
    The point is that if there is other data between label and that slightly odd line, the fill count will evaluate such that that it zero-pads it to $10000 bytes. As said, it does seem to work when I use byte 0[$10000+(label-$)] (without the @)

    It works because 'label' gives you the cog address (1 here) and $ also returns the current cog address.
    '@label' is the hub address, but not the absolute address but the relative address to the object begin.

  • yeah, but in ORGH mode, there isn't really a cog address, so I'd expect label and @label to be the same.

  • evanhevanh Posts: 15,091

    Flexspin with @:

    006e8                 | _dat_
    006e8                 |     orgh
    006e8     53 54 41 52 
    006ec     54          |     byte "START"
    006ed                 | label
    006ed     AA AA AA AA 
    006f1     AA AA AA AA |     byte $aa[8]
    006f5     05 00 00 00 |     long @label
    006f9     ED 06 00 00 |     long label
    006fd     00 00 00 00 
          ...             
    106e5     00 00 00 00 
    106e9     00 00 00 00 |     byte 0[$10000+(@label-$)]
    106ed     53 54 4F 50 
    106f1     00 00 00    |     byte "STOP"
    

    Pnut with @:

    00000- 19 FC 00 80 27 FC 00 00 53 54 41 52 54 AA AA AA   '....'...START...'
    00010- AA AA AA AA AA 0D 00 00 00 05 04 00 00 00 00 00   '................'
    00020- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   '................'
    ...
    0FC00- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   '................'
    0FC10- 00 00 00 00 00 53 54 4F 50 04 50 0D 7F F0 D0 87   '.....STOP.P.....'
    0FC20- 65 80 BC 81 12 79 04 00                           'e....y..'
    

    Flexspin without @:

    006e8                 | _dat_
    006e8                 |     orgh
    006e8     53 54 41 52 
    006ec     54          |     byte "START"
    006ed                 | label
    006ed     AA AA AA AA 
    006f1     AA AA AA AA |     byte $aa[8]
    006f5     05 00 00 00 |     long @label
    006f9     ED 06 00 00 |     long label
    006fd     00 00 00 00 
          ...             
    106e5     00 00 00 00 
    106e9     00 00 00 00 |     byte 0[$10000+(label-$)]
    106ed     53 54 4F 50 
    106f1     00 00 00    |     byte "STOP"
    

    Pnut without @:

    00000- 11 00 01 80 1F 00 01 00 53 54 41 52 54 AA AA AA   '........START...'
    00010- AA AA AA AA AA 0D 00 00 00 05 04 00 00 00 00 00   '................'
    00020- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   '................'
    ...
    0FFF0- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   '................'
    10000- 00 00 00 00 00 00 00 00 00 00 00 00 00 53 54 4F   '.............STO'
    10010- 50 04 50 0D 7F F0 D0 87 65 80 BC 81 12 79 04 00   'P.P.....e....y..'
    
  • evanhevanh Posts: 15,091
    edited 2022-03-08 14:18

    Spin behaviour of the @ is different from pure pasm assembly. Even Flexspin has a difference, albeit handled accordingly. I'm not gonna try to decipher it myself.

  • Wuerfel_21Wuerfel_21 Posts: 4,351
    edited 2022-03-08 15:29

    Another funny, though I think that's an issue with all loaders: The memory that isn't actually used doesn't seem(?) to get cleared, which leads to strange issues that seem to make no sense if you aren't aware of this.

    Or maybe I'm just going insane.

  • Jeff MartinJeff Martin Posts: 751
    edited 2022-03-08 16:59

    @Wuerfel_21 said:
    Another funny, though I think that's an issue with all loaders: The memory that isn't actually used doesn't seem(?) to get cleared, which leads to strange issues that seem to make no sense if you aren't aware of this.

    Or maybe I'm just going insane.

    Perhaps @cgracey can confirm this one, but I think the P2 loader works just like the P1 loader with regards to unused memory. The ".binary" or ".bin" memory image (the file, and what is maintained in memory in Propeller Tool if it was only compiled (not saved yet)) contains only the data up to the start of the stack. When transmitted to the Propeller, that data is all that is transmitted (to save time) and the loader (resident in the Propeller or delivered as part of the loading process) takes that image and copies it to RAM (and EE/Flash, if requested) and then automatically fills the rest of said memory with zeros before it executes the first executable statement from the image.

    Note that Spin variable memory is part of the .bin image and is set to zeros in that image, but PASM "reserved" (RES) registers are not emitted into the image and thus are not cleared or set to anything when the PASM is read into Cog RAM... so RES registers will end up being various initial values (whatever just happens to be the next values in the application image, immediately after the target PASM code) that got pulled into Cog RAM upon launching that code.

    Maybe the problems you're having are related to an unintended address/literal reference?

  • evanhevanh Posts: 15,091

    Jeff,
    I got a Proptool feature request: Add another button for saving the text formatted "Hex" view of data from the object info panel.
    And a question: Is there command options for compiling from shell? I'm not seeing much docs on just Proptool itself.

  • @cgracey

    Hello,
    I ran into this:

    I was fiddling with some possible code from Nuts and Volts taking small steps. When this happened I had to use the windows task manager to kill Pnut. Escape would not work.
    Can you explain the error.
    Thanks
    Martin

  • @evanh said:
    Jeff,
    I got a Proptool feature request: Add another button for saving the text formatted "Hex" view of data from the object info panel.
    And a question: Is there command options for compiling from shell? I'm not seeing much docs on just Proptool itself.

    Thank you.

    There are no options on Propeller Tool to compile from the shell. For the P1, the Propellent executable has extensive CLI support; however, that has not be brought up-to-date with the Propeller Tool yet to support P2.

  • evanhevanh Posts: 15,091

    @pilot0315 said:
    Can you explain the error.

    It's a classic crash. Pnut has a bug.

    Probably a separate issue, but I've noted if I externally modify the source code and then recompile, without dropping the update into Pnut, then Pnut attempts to reload the source code before compiling. This mostly works but can lock up and I need to kill it.

  • @evanh

    Thanks for the info.
    Martin

  • @cgracey
    Chip, when can we try the new debug window you showed in the propeller live forum ? I want to have it !!!

  • Chip, when can we try the new debug window you showed in the propeller live forum ? I want to have it !!!

    If you're referring to the version with mouse and keyboard input, that's available in 2.7.0 beta
    -- https://www.parallax.com/package/propeller-tool-software-for-windows-spin-assembly-2/

  • No, I mean the 'real' debug-window at 1:01:50 in the video 'Time of Flight Sensors with TeamOz' from March 23.

  • JonnyMacJonnyMac Posts: 8,910
    edited 2022-03-29 21:28

    As with all versions, Chip will announce when he releases PNut with that code, and later Jeff will integrate that into Propeller Tool.

  • I'd like to report a minor cosmetic bug of Propeller Toool V2.7.0:
    1When I start the software it comes up with a blank editor window and the left side shows the explorer tab with the directory tree and file list. But the OBJ dependency tree which is normally displayed top left is missing. Even after loading a source file and compiling it's still not displayed.

    I have to select "Hide explorer" and "Show explorer" from the menu or resize the window for it to appear.

  • @ManAtWork said:
    I'd like to report a minor cosmetic bug of Propeller Toool V2.7.0:
    1When I start the software it comes up with a blank editor window and the left side shows the explorer tab with the directory tree and file list. But the OBJ dependency tree which is normally displayed top left is missing. Even after loading a source file and compiling it's still not displayed.
    I have to select "Hide explorer" and "Show explorer" from the menu or resize the window for it to appear.

    Thank you, @ManAtWork

    I've seen this before but wasn't able to duplicate it or find what caused it. Thank you for your workaround tip. I'll make note of this and will look into it again.

  • cgraceycgracey Posts: 14,131

    @dnalor said:
    @cgracey
    Chip, when can we try the new debug window you showed in the propeller live forum ? I want to have it !!!

    It's coming along very nicely. Still working on it.

    I've got the entire breakpoint process down to 6ms, with only one serial turn-around, which creates a single latency delay. Keeping the communications short means that other cogs have plenty of time to report their own DEBUG messages.

  • cgraceycgracey Posts: 14,131

    @pilot0315 said:
    @cgracey

    Hello,
    I ran into this:

    I was fiddling with some possible code from Nuts and Volts taking small steps. When this happened I had to use the windows task manager to kill Pnut. Escape would not work.
    Can you explain the error.
    Thanks
    Martin

    Not sure. Sometimes I get stuff like that during development, and it's usually caused by a bad pointer. I will be on the lookout.

  • evanhevanh Posts: 15,091
    edited 2022-06-12 23:32

    Chip,
    I just realised I've been depending on something that is valid at the top level compile but not valid when used as an object. But I'm thinking there's no particular reason other than it just happens to be that way.

    What it is is the compile time symbols clkmode_ and clkfreq_. These two have the property of always existing, whereas _clkmode and _clkfreq only exist if defined in the source code.

    Except they don't exist within objects. :( Any chance of making them exist for objects too?

    EDIT: DOH! It works in Pnut. It's Flexspin that needs fixed .... LOL.

  • cgraceycgracey Posts: 14,131
    edited 2022-06-23 23:53

    I've got the debugger almost done.

    Here is a video of it single-stepping all 8 cogs at once:

    _clkfreq  = 300_000_000
    stacksize = $40
    
    var stack[8*stacksize]
    
    pub go() | i
    
      repeat i from 7 to 0
        cogspin(i, instance(i), @stack + i * stacksize)
    
    PRI instance(i) | j
      repeat
        pinw(i << 2 addpins 3, j++)
        debug
    

  • Wonderful, Chip

    All of a sudden, having 3 huge portait monitors makes perfect sense

    I'm going to have to show some non-P2 people that video...

  • cgraceycgracey Posts: 14,131

    @Tubular said:
    Wonderful, Chip

    All of a sudden, having 3 huge portait monitors makes perfect sense

    I'm going to have to show some non-P2 people that video...

    I just uploaded a better video and picture, and then updated the links.

  • It's going to be so cool to have such a useful debug environment for P2. Well done!

  • cgraceycgracey Posts: 14,131
    edited 2022-06-24 01:26

    Thanks, Guys.

    Each cog has a separate conversation with the host PC, so there's no extra resource required for debugging.

    Also, DEBUG() messages work the same as before. This debugger activity goes on silently over the serial connection and is started with a simple DEBUG without parentheses.

    Here is a clear picture of the debugger. To see memory, you just move the mouse pointer over things. For action, you select the trigger (INT1..3 entry or ISR code, a break address, an event (CT1..QMT), a plain DEBUG instruction (DEBUG compiles to 'BRK #0'), or MAIN code (non-ISR code). Then click 'Next' to execute to the next trigger or 'Auto' to automatically execute through triggers and animate the display.

Sign In or Register to comment.