I ran some test code for the debug interrupt with the new vector changes.
All the multi-cog variants work ok but I experienced different behavour from the single cog variants.
Here's a snippet of my code
wrlong isr,##$FFFFC - (test_cog * 4) 'set isr address
coginit #test_cog,##@code_2_debug 'launch cog with code to be tested
nop '??? needed for single cog versions ???
cogstop #0 'stop start up cog
What I have found is that I need to add a dummy instruction after the coginit for the single cog versions.
Without the nop the following cogstop is executed before the cognit fires.
Normally if the selected cog is 0 it never reaches the cogstop instruction.
It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
I ran some test code for the debug interrupt with the new vector changes.
All the multi-cog variants work ok but I experienced different behavour from the single cog variants.
Here's a snippet of my code
wrlong isr,##$FFFFC - (test_cog * 4) 'set isr address
coginit #test_cog,##@code_2_debug 'launch cog with code to be tested
nop '??? needed for single cog versions ???
cogstop #0 'stop start up cog
What I have found is that I need to add a dummy instruction after the coginit for the single cog versions.
Without the nop the following cogstop is executed before the cognit fires.
Normally if the selected cog is 0 it never reaches the cogstop instruction.
It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
It is a GOOD thing you found this!!!
I was worried that something like this could be lurking when the hub can receive an instruction EVERY clock, even though instructions take two clocks.
If I recall, COGINIT first disables the cog to reset it, then enables the cog to start it. I think the enabling and COGSTOP are collIding and the COGSTOP takes priority. I'll fix this.
Meanwhile, could you please confirm that adding a WC after the COGINIT operands makes the problem go away? That should have the effect of adding two clock cycles to the COGINIT, causing ample separation from the COGSTOP.
It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
It's probably wise to fix it while it's freshly noted but that's probably the only reason. I can't imagine a real single Cog Prop coming off the production lines!
Come to think of it, what is that coding trying to do? It's like a soft reset or something.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
Meanwhile, could you please confirm that adding a WC after the COGINIT operands makes the problem go away? That should have the effect of adding two clock cycles to the COGINIT, causing ample separation from the COGSTOP.
I ran some test code for the debug interrupt with the new vector changes.
All the multi-cog variants work ok but I experienced different behavour from the single cog variants.
Here's a snippet of my code
wrlong isr,##$FFFFC - (test_cog * 4) 'set isr address
coginit #test_cog,##@code_2_debug 'launch cog with code to be tested
nop '??? needed for single cog versions ???
cogstop #0 'stop start up cog
What I have found is that I need to add a dummy instruction after the coginit for the single cog versions.
Without the nop the following cogstop is executed before the cognit fires.
Normally if the selected cog is 0 it never reaches the cogstop instruction.
It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
Ozpropdev,
It took me a while to get this straightened out. I'm recompiling everything now, as this involved some changes to the hub logic. I'm sure glad you found this!
I should have a new set of files out tomorrow. Thanks!
I recompiled the BeMicro-A9 image from scratch, but it wound up identical to the image contained in the v24 release. So, there wouldn't be any difference.
It's very puzzling that it identifies, but doesn't run code. The only thing I can imagine is that maybe the clock generation is off from 80MHz. It uses the same PLL file as the the Prop123-A9, though, which has always worked.
I will keep thinking about this, but I don't know what to do. I don't have a BeMicro-A9, myself.
EDIT: Also, loadp2 has different handling of the comport control lines.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
The BeMicro-A9 image would soft reset when D[8] of 'CLKSET {#}D' was high, whereas the Prop123-A9 image would reset when D[25] was high, which was correct. I've updated all the images to use D[25] as a soft reset for 'CLKSET {#}D'. Could this be causing the behavioral difference you're seeing?
I'm recompiling the BeMicro-A9 image now to use D[25] as soft reset, instead of the errant D[8]. I don't know if this will make any practical difference for anybody, yet, though.
Chip
Pnut reports "Hardware lost on COM7" but can ID P2 Ok with Ctrl-G.
I can however load code with Daves loadp2 program fine @3Mbaud. (Thanks for the suggestion @evanh!)
Weird huh?
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
Well, since you asked, and I don't have a solid explanation, but I've been bothered by PNut's comms stability since I got my Prop123 board. Ie: I can't use PNut for my Prop123-A9 board. The data flow is precise and complete but the handshaking is wacky. In particular, the Prop gets a physical reset pulse just when the main binary transmit starts. From memory, it's the third of three resets that occur during the whole process after pressing F11.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
Well, since you asked, and I don't have a solid explanation, but I've been bothered by PNut's comms stability since I got my Prop123 board. Ie: I can't use PNut for my Prop123-A9 board. The data flow is precise sand complete but the handshaking is wacky.
I will look into the comm code in PNut, but what makes no sense is that the Prop123-A9 works, while the BeMicro-A9 doesn't.
Yep, no sense at all.
Pnut works fine with all the boards and has done for quite some time.
Same cables and all.
I've never had to use anything else but Pnut.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
I think there is two parts. First is at 2Mb/s then second part defaults to 115k2. This will be same for PNut.
EDIT: Err, MainLoader.spin2 says 256kb/s for first part.
EDIT2: Wrong again, there is LOADER_BAUD for the whole thing. It is 2Mb/s. The user_baud is only for runtime debug strings.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
Ah, Dave has modified Chip's MainLoader source to precalculate from a couple of constants whereas Chip has hand coded numbers in a few places. Chip's one does say 2Mb/s too.
EDIT: There's no diff in the source between v23 and v24 MainLoader.spin2 from Chip.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
Comments
All V23a images loaded Ok. :cool:
I ran some test code for the debug interrupt with the new vector changes.
All the multi-cog variants work ok but I experienced different behavour from the single cog variants.
Here's a snippet of my code What I have found is that I need to add a dummy instruction after the coginit for the single cog versions.
Without the nop the following cogstop is executed before the cognit fires.
Normally if the selected cog is 0 it never reaches the cogstop instruction.
It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
It is a GOOD thing you found this!!!
I was worried that something like this could be lurking when the hub can receive an instruction EVERY clock, even though instructions take two clocks.
If I recall, COGINIT first disables the cog to reset it, then enables the cog to start it. I think the enabling and COGSTOP are collIding and the COGSTOP takes priority. I'll fix this.
Meanwhile, could you please confirm that adding a WC after the COGINIT operands makes the problem go away? That should have the effect of adding two clock cycles to the COGINIT, causing ample separation from the COGSTOP.
Super. Thanks.
Come to think of it, what is that coding trying to do? It's like a soft reset or something.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
Yes
Adding the WC fixes the problem.
Its has to be configured before launch.
Ozpropdev,
It took me a while to get this straightened out. I'm recompiling everything now, as this involved some changes to the hub logic. I'm sure glad you found this!
I should have a new set of files out tomorrow. Thanks!
This version 24 fixes the COGINIT+COGSTOP collision that was occurring on single-cog FPGA images.
Please try this out and test your code base with it. Thank you!
All the single cog variants work fine now.
All but the BeMicro-A9 image work Ok.
The BeMicro-A9 image identifies Ok with Pnut but doesn't load any code via F11.
Ok. Thanks. I'll fix it.
I recompiled the BeMicro-A9 image from scratch, but it wound up identical to the image contained in the v24 release. So, there wouldn't be any difference.
It's very puzzling that it identifies, but doesn't run code. The only thing I can imagine is that maybe the clock generation is off from 80MHz. It uses the same PLL file as the the Prop123-A9, though, which has always worked.
I will keep thinking about this, but I don't know what to do. I don't have a BeMicro-A9, myself.
Try using Dave's loadp2 to do the transfer instead of PNut. There is config options in the latest version of loadp2 for matching the clock rates. Latest - http://forums.parallax.com/discussion/comment/1416789/#Comment_1416789
EDIT: Also, loadp2 has different handling of the comport control lines.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
I did notice one thing...
The BeMicro-A9 image would soft reset when D[8] of 'CLKSET {#}D' was high, whereas the Prop123-A9 image would reset when D[25] was high, which was correct. I've updated all the images to use D[25] as a soft reset for 'CLKSET {#}D'. Could this be causing the behavioral difference you're seeing?
I'm recompiling the BeMicro-A9 image now to use D[25] as soft reset, instead of the errant D[8]. I don't know if this will make any practical difference for anybody, yet, though.
Pnut reports "Hardware lost on COM7" but can ID P2 Ok with Ctrl-G.
I can however load code with Daves loadp2 program fine @3Mbaud. (Thanks for the suggestion @evanh!)
Weird huh?
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
But why in the world doesn't PNut.exe work with it? It's all crystal/PLL-based, anyway. Same as the Prop123-A9.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
I will look into the comm code in PNut, but what makes no sense is that the Prop123-A9 works, while the BeMicro-A9 doesn't.
Pnut works fine with all the boards and has done for quite some time.
Same cables and all.
I've never had to use anything else but Pnut.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
Hmmm.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
I'm curious, what baud rate does loadp2 run at?
EDIT: Err, MainLoader.spin2 says 256kb/s for first part.
EDIT2: Wrong again, there is LOADER_BAUD for the whole thing. It is 2Mb/s. The user_baud is only for runtime debug strings.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
EDIT: There's no diff in the source between v23 and v24 MainLoader.spin2 from Chip.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
I tried Pnut on two more machines(laptops) and got the same results.
Sorry Chip! You must cringe every time you see me post spmething..