Compiler / P2 oddity

kbash · 2018-12-30 21:04

I posted the following in the NEWBIE discussion but didn't get a response. I think this is the sort of oddity that those of us who purchased the eval board are looking for, I wanted to verify whether it is something I just don't know about the P2 or if it is something odd in the behavior of either the compiler or the P2 itself:

I'm trying out my first code changes with PNUT on my P2 eval board.

I started off with Chips original blink program. Instead of initializing a group of cogs with a loop ( which works fine) I changed the code to initialize a single cog with the blink function, then initialize a second cog with another blink routine. These functions work fine UNLESS the first cog initialized is either cog 0 or cog 2. In this case, only the first cog seems to be functioning.

( Change cognum1 to 0 or 2 to verify in the attached code )

Is this something I don't understand about the P2, the Eval board or something odd about the compiler itself?

Any ideas?

Rayman · 2018-12-30 21:21

I think you need to stop cog #0 (or put it in infinite loop) after it starts those two cogs...

Otherwise it keeps executing stuff you probably don't want it to...

kbash · 2018-12-30 21:39

Ah... that explains why it stops after initializing cog 0... it must be overwriting the set-up code that should be going on to initialize the second cog. That makes sense. Any idea of why it would fail when the first cog value is 2 ?

msrobots · 2018-12-30 22:46

0 makes sense since your program is actual running on cog 0 so your program kills itself after the first coginit and never reaches the second one.

I modified your example to use P56 for blink and P57 for blink2 because adding 56 to the cogid can not work with cog 7 since pin 63 is used for serial.

I also put your starting cog 0 into a loop at the end so that it does not run into your data

dat
		orgh	0
'
'  seperate initialization of two cogs to blink on the Eval board 
'
		org
 

		coginit	cognum1,#@blink  ' init a single cog to use the blink program 

		coginit	cognum2,#@blink2 

wait		jmp	#wait

cognum1		long	4
cognum2 	long    0



 
'
' blinkS



		org
 

blink		mov	x,#56
		drvnot	x		'output and flip that pin
		shl	x,#16		'shift up to make it big
		waitx	x		'wait that many clocks
		jmp	#blink		'do it again


blink2		mov	y,#57
		drvnot	y		'output and flip that pin
		shl	y,#16		'shift up to make it big
		waitx	y		'wait that many clocks
		jmp	#blink2		'do it again





x		res	1
y		res	1

Enjoy

Mike

ozpropdev · 2018-12-30 23:12

BTW those "cognum" longs would be processed as

cohnum1    long 4

P2 sees as

_ret_ ROR 0,4

kbash · 2018-12-31 01:24

Hi Mike and Oz,

I already found out that reversing the order of the cog startups seems to work fine. There's not a problem with GETTING the blink program to work with both the 0 and cogs 1-7.

I also understand now why initializing cog 0 first would clobber the code that was currently running on cog 0 and fail to initialize more code.

What I DON'T understand is why initializing cog 2 first would clobber the code the same as initializing cog 0 first. I can't think of anything that would be running on cog 2 that would lock up the rest of the sequence.

I'm fine with "leaving it alone " since I can get around it... but if it is an unknown bug in either the compiler or the silicone... it needs to be understood.

It is more likely a problem with my understanding of the way things work, like starting cog 0 first. I get that one now. ... but what's the problem with starting cog 2 first ?

msrobots · 2019-01-01 02:04

I have no problem with 2 as cognum1 and 0 as cognum2, what are you experiencing?

Mike

kbash · 2019-01-01 05:34

Hi msrobots , I don't have a problem with that setup either. It's only when the first cog (cognum1) is initialized to 0 or 2. Rayman helped me figure out what was happening when I initialized cog 0 first. Since the setup code is running on cog 0 at startup, the new code was overwriting the setup code and never going on to initialize the second cog.

What I DON'T understand is why initializing cog 2 first would do the same thing. The initialize code is running on cog 0. It SHOULD initialize cog 2 to blink then go on to initialize the other cog whatever it's number is. It operates as if initializing cog 2 is clobbering the setup code exactly like it does with setting up cog 0 first. All other combinations I've tried seem to work fine.

msrobots · 2019-01-01 05:53

I tried the code with cognum1 as 2 and cgnum2 as 0 and it works fine here, is your cog2 broken?

Mike

Peter Jakacki · 2019-01-01 07:00

Just post your code exactly the way you have it so that anyone can try it and spot the error. It costs nothing to post it each and everytime and if everyone comes back and goes "oh yeah, that is strange" then we may have some fun but I think you have a simple typo error or something since I init multiple cogs all the time without any problems.

kbash · 2019-01-01 17:16


dat
		orgh	0
'
'  seperate initialization of two cogs to blink on the Eval board 
'
		org
 

coginit	cognum1,#@blink  ' init a single cog to use the blink program 

coginit	cognum2,#@blink2 


'coginit	cognum1,#@blink  ' init a single cog to use the blink program 





' ************  The following cog combinations all work fine:  


' cognum1	long	1
' cognum2 	long    4

' cognum1	long	3
' cognum2 	long    5

' cognum1	long	4
' cognum2 	long    0

' cognum1	long	5
' cognum2 	long    2

' cognum1	long	1
' cognum2 	long    4

'*************  etc.  any combo that doesn't have 0 or 2 initialized as cognum1 works 


' *************   These combinations only blink the cognum1 led :   

' cognum1	long	0
' cognum2 	long    4

' cognum1	long	2
' cognum2 	long    5

' cognum1	long	2
' cognum2 	long    6


' this following combination only blinks 1 led (p58) on my  P2-EV board

cognum1		long	2
cognum2 	long    5

 
'
' blinkS

		org
 

blink		cogid	x		'which cog am I, 0..7?
		add	x,#56		'add 56 to get LED pin  
		drvnot	x		'output and flip that pin
		shl	x,#16		'shift up to make it big
		waitx	x		'wait that many clocks
		jmp	#blink		'do it again


blink2		cogid	y		'which cog am I, 0..7?
		add	y,#56		'add 56 to get LED pin  
		drvnot	y		'output and flip that pin
		shl	y,#16		'shift up to make it big
		waitx	y		'wait that many clocks
		jmp	#blink2		'do it again


x		res	1
y		res	1

That's my program exactly as I'm running it. On my P2-EV board, compiled as is, only LED 58 blinks

Does it work the same way on another EV board or is it only mine?

pilot0315 · 2019-01-01 17:49

I am getting pin 61 and pin 58

kbash · 2019-01-01 19:04

Thanks Pilot. My board is sitting here blinking only one LED using the same code. If somehow cog 0 and cog 2 are cross-linked on my chip only, then not a problem for most users. If anyone else tries it, I'd appreciate the feedback.

By the way... what do you fly?

msrobots · 2019-01-01 19:27

@kbash,

look at my listing I provided as example 9 posts up.

You are running into your data.

Your first cog (cog 0) does the two coginits and then runs into your definition of cognum1 und tries to execute it.

After your coginits you have to stop your cog from running into your data.

wait    jmp   #wait

would do it

Mike

kbash · 2019-01-01 20:06

Thanks Mike,

That gets rid of the problem when cog 2 is initialized first. I don't quite understand why all the other combinations work and that one doesn't but I've got a very long way to go to fully understand the P2 so we're good. Thanks!

ersmith · 2019-01-01 20:32

Is it possible you have a defective LED? Are you able to blink LED 61 with any program at all?

marsman2020 · 2019-01-01 20:42

Really strange things happen when any CPU starts trying to run data as code.

kbash · 2019-01-01 21:25

Yes ersmith... all led's blink fine. ( and in any other combination) I agree with Marsman if that's whats going on... and I suspect it is just my lack of understanding, not a P2 problem. However... it does strike me as a bit strange that Mike (msrobots) said his board worked fine with the code that mine hangs up on. I would expect all the P2 chips and boards to be the same.

marsman2020 · 2019-01-01 21:43

kbash wrote: »

Yes ersmith... all led's blink fine. ( and in any other combination) I agree with Marsman if that's whats going on... and I suspect it is just my lack of understanding, not a P2 problem. However... it does strike me as a bit strange that Mike (msrobots) said his board worked fine with the code that mine hangs up on. I would expect all the P2 chips and boards to be the same.

I'm pretty sure he fixed your code so it wouldn't run into the data in his first post. So what worked was the fixed code.

jmg · 2019-01-01 21:45

kbash wrote: »

.. I would expect all the P2 chips and boards to be the same.

Usually,. yes, but the RAM contents will not be the same across all boards. That depends on what was loaded in the past, and power up is random.

msrobots · 2019-01-01 23:58

no, the problem was simply running into the data and executing as code, and as @ozpropdev explained cognum1 as long 2 is the assembly instruction

_ret_ ROR 0,2

which sends the executing cog into nirwana land somewhere since it rotates memory position 0 right by two bits and then does a ret without a call first.

I think your misunderstanding is the use of coginit. It is not a assembler directive meant that you want to start one cog for blink1 and one cog to start blink2.

You are already running on cog0 and these are assembly instructions carried out by cog0.

And cog0 now starts the other cogs and after that it is running into long 2 which is the instruction above.

Mike

kbash · 2019-01-02 02:01

Thanks Mike, I'll spend some more time with the docs on the P2 boot sequence. If the people who KNOW what's going on are good with what I found I won't worry about it. I know some of what those of us who got the Eval board are doing is looking for things that might be unusual with the P2 or the tools. If YOU'RE good... I'm good.

Ken

Compiler / P2 oddity

Comments