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?)
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.
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."
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 @)
@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.
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.
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.
@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?
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.
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.
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.
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.
@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.
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.
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.
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.
Comments
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?)
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.
[deleted]
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, youorghinstead oforgcat 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 @)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
labeland@labelto be the same.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
@: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
@: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.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?
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
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.
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 !!!
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.
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.
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.
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.
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.
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_andclkfreq_. These two have the property of always existing, whereas_clkmodeand_clkfreqonly 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.
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++) debugWonderful, 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!
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.