Code works when object added, how possible?
Rayman
Posts: 14,762
Here's another strange behavior, that I thought I'd share.
Not asking for help with the code, just wondering how it is possible...
This FSRW, sd reading code, worked a couple years ago, but now has a problem with the assembly version of the low level driver. The cogless, inline assembly version seems to work.
So, the assembly version is broken badly and can actually destroy the filesystem.
But, trying to troubleshoot was proving difficult. It breaks debug commands too.
So, I added "jm_serial" as an object in the assembly driver, hoping I could use it for debugging.
But then, it started working!
Obviously, something is broke, but how can adding an extra object fix it?
Anyway, a bit of a mystery at the moment...
Comments
BTW: I'm not sure adding "jm_serial" to the low level driver actually changes the binary size because it's already included in the top level...
I've seen odd things like this with the P1. It came down to some section of RAM being long aligned or not. I know the P1 needed the par to be a long sized value (when launching a PASM cog).
I can't think of anything which needs to be long aligned with the P2 but maybe there's something similar happening here?
Thanks, interesting idea.
I do remember seeing an alignl command in the dat section…
Maybe that is broke…
I wondered about that as well.
Am I correct that ptra doesn't need to be long aligned? I see that this special register is used a lot.
I barely felt like I was getting the hang of the P1 when the P2 came out. I haven't caught up with all the new stuff in the P2 yet.
Think I found the problem...
The assembly is using a variable (delay1s) that is declared using "RES", but not given a value anywhere.
Guess it's just winding up with a value from whatever code comes after the defined assembly...
Kind of amazing it worked at all, this is part of a timeout scheme using pollct1...
Not exactly sure how this is breaking debug though. Also, not clear why behavior is different in FlexProp.
But, this is clearly bad code and I guess anything can happen...
Ok, I see that you can't use "jm_serial" output along with debug. Guess that makes sense.
If the RES is at the end of the file's last DAT block, the actual value that ends up there is undefined and depends on what the compiler chooses to put after the DAT block. In particular, in Chip's compiler this will be the bytecodes of the first function in the object (going from Spin1 experience. Might be different in Spin2). In Flexspin it will be the next object's static data (by order of ????) or VAR space if it ends up as the last DAT section.
@Wuerfel_21 I checked your version of this driver and see you fixed this there, right? Or, maybe you found a version where it was already fixed?
Indeed, I remember now that some "timeout scheme using pollct1" was something stupid I had to fix.
Moral of the story: please don't post Smile code without declaring it as such
Looks like serial output, like with "jm_serial", works alongside debug commands in FlexProp.
Both outputs get dumped to terminal.
Kind of wish Prop Tool was like that. Appears that it hangs if you try to have both going...
The debug code is identical, IDK why it wouldn't work in proptool
Looks like prop tool debug window gets confused by other serial output