Smartpin "Quadrature Encoder" mode returns erratic values

ozpropdev · 2016-04-18 14:39

Chip
I been experiencing weird behaviour of the smartpins in quad. enc mode.
At first I thought it might be faulty encoders, so I replaced them.
The issue persisted so I have removed them and implemented fake ecoders in another cog.
The issue remained so I did a few tests and found that the issue seems to be related to the period between PINGETZ instructions.
in the included code the fake encoder cycles back and forth at low speed and displays the Z value spaced by its lower bits.

If the WAITX instruction @ main is enabled the following output is returned (Correct).

When the WAITX @ main is removed erratic behaviour is observed.

The results vary on each download.
The test code has been running on a P123-A9 board.

cgracey · 2016-04-18 16:26

I'm glad you found this!

I'm looking into it right now.

cgracey · 2016-04-18 22:24

It seems to work okay on my end. Try this A9 program and see if it works okay. Use PB3 and PB2 to simulate the encoder inputs:

dat		org			'cog program

.init		pinsetm	pm,#7		'smart pin 7 is encoder (reads 8 and 9)
		pinsetx	#0,#7

		or	dira,##$3FF	'enable smart pin 7 and pins 9..0
.loop
		testb	inb,#27 wc	'copy pushbutton 3 to pin 9
		setbnc	outa,#9

		testb	inb,#26 wc	'copy pushbutton 2 to pin 8
		setbnc	outa,#8

		pingetz	x,#7		'read encoder and output to pins 7..0
		setbyte	outa,x,#0

		jmp	#.loop


pm		long	%0001_0010_000_0000000000000_01_10000_0
x		long	0

jmg · 2016-04-18 22:37

cgracey wrote: »

It seems to work okay on my end.

You mean you checked the code in #1 and it ran 100% ?

Looking at the code, the delay patch seems to be in an unexpected place, (ie the loop has already taken many cycles sending data, why should a few more matter ? ), and it seems the counter itself is ok, just the read sometimes gets 00 by mistake.
The patch is right after a jump, could there be some interaction between pipeline and opcodes like pingetz ?
Is there enough timing margin in the FPGA's ?

OzPropdev: What range of delays is a fix, and does one or more NOP also fix ?

Addit: I also notice that failure seems periodic - it is always NYNYYYY ?
Could the loop time not be N*16 and so a variable phase on COG slot is occurring ?
( that would mean some NOPs could fix, and more NOPs could break again )

ozpropdev · 2016-04-18 23:44

I ran some more tests this morning and might have another clue.
I fired up my DE2-115 board just as a point of reference.
Because the DE2 only has 8 snartpins and no smartpin on pin 62(Tx) I replaced the Tx code with a bit bang variant.
Code works fine with/without WAITX delay.
At first I thought this might be a Cyclone 4/5 timing difference.
Running the bit bang variant back on the A9 board and now everything works.
It seems to be a smartpin message issue from the async tx mode that upsets the quad mode smartpin?

jmg · 2016-04-18 23:51

ozpropdev wrote: »

It seems to be a smartpin message issue from the async tx mode that upsets the quad mode smartpin?

You mean interleaved pingetz's get confused ?
The loop delay is likely also not exactly the same, so you could try inserting back dummy pingetz, and see if that
always breaks, no matter where it is inserted ?

ozpropdev · 2016-04-19 00:42

Huh?
I setup another smartpin in async mode but only ever reference it wuth a PINGETZ.

		pingetz	dummy,#tx_pin2 wc
		pingetz	temp,#fake		'read encoder count

Works fine but

		pingetz	temp,#fake		'read encoder count
		pingetz	dummy,#tx_pin2 wc

does not (erratic quad. enc values), but a combination of the two

		pingetz	dummy,#tx_pin2 wc
		pingetz	temp,#fake		'read encoder count
		pingetz	dummy,#tx_pin2 wc

works fine. ?????
I'm still thinking it's some sort of smartpin messaging issue.

jmg · 2016-04-19 00:48

Is that failing case still the first opcode after a jump ? (aka jump destination)

ozpropdev · 2016-04-19 00:54

jmg wrote: »

Is that failing case still the first opcode after a jump ? (aka jump destination)

Yes, but I have placed a bunch of instruction before the PINGETZ and it made no difference.

jmg · 2016-04-19 01:29

Does this simpler test, also fail the same way on the DE2 ?

ozpropdev · 2016-04-19 01:53

jmg wrote: »

Does this simpler test, also fail the same way on the DE2 ?

Same result on DE2 as A9.

One thing I did discover is that if I assign my dummy async Tx smartpin to a non existant smartpin the issue goes away.
So the code combination #2 now works on DE2-115.

jmg · 2016-04-19 01:59

ozpropdev wrote: »

Same result on DE2 as A9.

Starts to look less like some marginal FPGA issue....

ozpropdev wrote: »

One thing I did discover is that if I assign my dummy async Tx smartpin to a non existant smartpin the issue goes away.

Maybe that just becomes a NOP ? - Chip will know how different a no-pin-there opcode is.

If you do 2 consecutive 'read encoder count' pingetz's, do they both have a failure pattern, or only the first one ?

ozpropdev · 2016-04-19 03:16

Chip
I modified your test code slightly to display the encoder value on the A9's green leds.
By adding a async smartpin into the mix breaks your code too.
Particulary on rollover.

con
	sys_clk = 80_000_000
	tx_pin = 62
	baudrate = 115_200
	nco_baud = round(float($1_0000) / (float(sys_clk) / float(baudrate)))

dat		org			'cog program

.init		
		pinsetm	#%1_11110_0,#tx_pin
		pinsetx	##$8000_0000 | nco_baud << 16 | %1_00000 | 7,#tx_pin
		setb	dira+tx_pin>>5,#tx_pin

		pinsetm	pm,#7		'smart pin 7 is encoder (reads 8 and 9)
		pinsetx	#0,#7
		setb	dira,#7
		setb	dira,#8
		setb	dira,#9

		or	dirb,##$ffFF	'enable green leds
.loop
		testb	inb,#27 wc	'copy pushbutton 3 to pin 9
		setbnc	outa,#9

		testb	inb,#26 wc	'copy pushbutton 2 to pin 8
		setbnc	outa,#8
		pingetz	x,#7		'read encoder and output to pins 7..0
	'	pingetz	adra,#tx_pin wc   '<<<< causes invalid encoder values
		setword	outb,x,#0

		jmp	#.loop

pm		long	%0001_0010_000_0000000000000_01_10000_0
x		long	0

Edit: Same outcomes are observed using the three variants mentioned above.
As long as there is a Async PINGETZ before the ENC PINGETZ it works?

cgracey · 2016-04-19 04:05

I didn't realize there was an initial program posted, as jmg pointed out. Anyway, now that we know what circumstance elicits the problem, it will be much easier to identify. I'll be on it shortly.

cgracey · 2016-04-19 06:23

Okay!

Ozpropdev, I got it to fail using your last program posted.

I see the problem. On the first clock of the GETPINZ instruction, it's reading the smart pin that was the object of the prior PINSETM/PINSETX/PINSETY/GETPINZ instruction. If that smart pin happens to be outputting a message header, the cog starts reeling in a message, starting on the next clock, from what is then the correct smart pin. So, it's sometimes using a wrong message header with the right pin, causing registration and sizing errors. Sorry about this. I should have thought this through better.

I'm fixing it now.

I'm sure glad you guys find things like this.

Jmg, you have the scariest imagination - a pipeline bug! There could be such things lurking, but, hopefully, we've weeded those out, already. Good guess, anyway.

jmg · 2016-04-19 06:29

cgracey wrote: »

Jmg, you have the scariest imagination - a pipeline bug! There could be such things lurking, but, hopefully, we've weeded those out, already. Good guess, anyway.

The symptoms did not quite fit a simple alternate-read / leading hangover issue, so I had to imagine deeper...
Good if you have nailed it.

cgracey · 2016-04-19 07:17

It's fixed.

I'm starting up an A9 compile now.

ozpropdev · 2016-04-19 07:41

cgracey wrote: »

It's fixed.

I'm starting up an A9 compile now.

Thanks Chip.
It's nice when it's a quick fix.

cgracey · 2016-04-19 07:55

ozpropdev wrote: »

cgracey wrote: »

It's fixed.

I'm starting up an A9 compile now.

Thanks Chip.
It's nice when it's a quick fix.

The fix was maybe 10 minutes, but the compile takes 2 hours.

cgracey · 2016-04-19 20:47

Here is a new Prop123_A9_Prop2_v8a.rbf:

https://drive.google.com/file/d/0B9NbgkdrupkHby0xV0tsU3ZJZXM/view?usp=sharing

jmg · 2016-04-19 20:55

cgracey wrote: »

Here is a new Prop123_A9_Prop2_v8a.rbf:

Any summary of what else changed ?
Dual-port LUT ? Better capture-mode controls ?

cgracey · 2016-04-19 23:22

jmg wrote: »

cgracey wrote: »

Here is a new Prop123_A9_Prop2_v8a.rbf:

Any summary of what else changed ?
Dual-port LUT ? Better capture-mode controls ?

Dual-port LUT and phase setting in NCO mode. I'll document these things as soon as they are done and I'll make a new release.

ozpropdev · 2016-04-19 23:30

cgracey wrote: »

Here is a new Prop123_A9_Prop2_v8a.rbf:

https://drive.google.com/file/d/0B9NbgkdrupkHby0xV0tsU3ZJZXM/view?usp=sharing

Thanks Chip.
V8a running very nicely.
Cheers
Brian

Smartpin "Quadrature Encoder" mode returns erratic values

Comments