Rolling over from COGRAM to HUBRAM behaves strangely?
moony
Posts: 27
in Propeller 2
..To the point I don't even know what it's doing.
It seems that, when it rolls over from 0x3FF to 0x400 it's not doing what it normally should to configure hubram exec?
I've tried both with and without the FIFO configured and cannot get it to behave, so was wondering if anyone knew what the P2 was doing here, and if the behavior is potentially useful.
My original hope was the P2 would end up using the pre-existing FIFO config for code execution, which would permit fast loops to be contained in hubram using FIFO wrap-around, but that doesn't seem to be the case.
It's also totally possible I'm just bad at testing things like this though, and made some mistake. We'll see.
Comments
Sorry but we'll need more info to help.
What are you trying to do, what language, what compiler, what hardware if relevant, etc.
Code will execute faster and deterministic from cog and lut. Executing from hub (hubexec) is slower.
From an execution point of view, cog is $000-$1FF, lut is $200-$3FF and hub follows ($400 as a long address) ($1000 in byte addressing) -$7FFFF (and $7C000-$7FFFF is dual mapped to $FC000-$FFFFF unless it's protected when it's only $FC000-$FFFFF. The lower hub $00000-$00400 which is really $00000-$01000 (byte addressing) can be used for data but not code.
Mooney is attempting to avoid branching by running off the end of lutRAM and into hubRAM addresses. I doubt it'll work but lets see ...
Wow, it does work. It's not going to achieve what you wanted though. Hubexec kicking in at $400 will certainly be reconfiguring the FIFO, just the same as a branch into hubexec.
setq2 #(lut2 - lut1 - 1) rdlong ($200 - 2), ##@lut1 jmp #lut1 org $400 - 2 lut1 loc pa, #msg1 call #puts lut2 jmp #$ ORGH $400 loc pa, #msg2 call #puts jmp #$ msg1 byte "Start ... ",0 msg2 byte "Stop",13,10,0Ha! No, hubexec doesn't kick in that way. My example above accidentally triggered a branch to hubexec because the instruction at $3ff is a CALL, the returning branch is to $400 and therefore directs the FIFO with a hidden RDFAST.
EDIT: Otherwise, what happens after executing address $3ff is cogexec rolls over to address 0 and starts back at cogRAM address 0. PS: And I've tested this too now.
Falling off the end of LUT like that back to address 0 is probably ideal for paging. I'm going to see if I can use that in my LUTexec model.
Not real paging by the way.
Just wondering now what happens if a fast block move runs off the end of COG or LUT RAM?
I think it just wraps back to the beginning of that memory
That's write.
It's true that hubexec does not get initialized if you roll past $3FF, so this is how I've always visualized it.
Oh, just checked and, Chip, your hint confirms it. The program counter is above $400 when it's back round executing from cogRAM. So cogRAM addressing hardware just ignores the upper program addresses. Makes sense in hindsight.
Picture is worth a thousand words.
So if code wraps around from $3FF to $0 and instruction at latter is a CALL, then return address of $401*4 is pushed onto the stack?
Yes, the subsequent return would pop a hubRAM address which would trigger hubexec using the FIFO.
Any RDFAST/WRFAST in action at the time of the return will be reset by the hidden RDFAST of the returning branch.
Or was that question about SETQ+RDLONG actions?
Not necessarily, if subroutine called from $0 popped and/or modified the return address to point to cog/LUT. Looking at the return address is a way to detect code wraparound, e.g. for cold vs warm boot.
I am talking about a different thing here, not code wraparound.
Lol, if you want to modify the stack then it can be anything.
And that detail fully explains why I needed an absolute call address in my testing. To successfully extract and print the program counter required a call to a routine, which I had sitting in cogRAM, so it would then have a copy of the program counter on the stack. The assembler would normally generate a relative branch between two cogRAM addresses like that, but the hardware is seeing a short branch from cogRAM fetched code that is suddenly wanting to execute from hubRAM. Hubexec triggers and I don't get the tidy printout I wanted.
To prevent that errant path, I coded the call as an absolute branch. This ensures the call destination stays in cogRAM. I could have put the PC extraction routine in hubRAM instead. The assembler would've automatically encoded the call as absolute then.
OT - the rev A board I sent to a friend has a problem. FT231 seems to be not working. Cannot program via PC-USB. Board can be powered by P2-USB but not PC-USB. Not a cable issue.
Evan, did you have this problem? Any suggestions?
One issue is the 500 mA limiting thermistor. It drops too many volts. If that's the only problem then light duties still work.
What seemed to happen quite easy was the USB power switching ICs would die. There is two of them. I destroyed the AUX (P2-USB) one on my board, and it is the most prone. They are very hard to desolder with a soldering iron. EDIT: Err, that's the revB boards. RevA boards were easier to desolder those. RevB/C has tougher switches but I still managed to kill one of mine. I think I might have done in the revB with a stray wire from benchtop power supply.
And bridging out the thermistor works well too.
Here's the schematics and a render of the board layout. I've put a red ring around F401, the 500 mA thermistor, at the top-right, and U501, the USB power switch, top-leftish.