Problem with SincN filtering in smartpins

evanh · 2020-11-08 10:00

Chip,
With smartpin modes %11000 (P_ADC) or %11001 (P_ADC_EXT), problem occurs using WXPIN %01_xxxx (Sinc2 filtering) or %10_xxxx (Sinc3 filtering). I've discovered glitches in the decimation data from RDPIN when one of theses modes is active. It becomes more apparent with longer decimation periods but I think it is present at all times. It appears as sporadic extra bits. They tend to be at particular bit positions for a given setup. I've noted only high order bits so far, but can't rule them out at any position. The weirdest part is their occurrences are repeatable, like its somehow timing related. With Sinc2, 1024, and lower, bits (clocks) per decimation seems okay. Which is three octaves lower than your docs say should work. And I couldn't get any number of bits per decimation to be clean with Sinc3.

I've gone over and over my code to find any of my own bugs. I've even tested/verified my own understanding of the ADC hardware and SincN processing by using WXPIN %11_0101 (32 bit captures of the raw bitstream). Everything checks out so far. In fact I can reliably process right up to the limits of 32-bit registers with my own Sinc3 filtering. Namely, Sinc3 at 1024 bits per decimation sample works out fine.

EDIT: Here's my working code. It requires Fastspin and my wrapper code, so you'll probably want to write your own.
EDIT2: Small code adjustment

Update: As per below, it needs handled in software ... But is not a problem with the smartpin hardware. It is just what happens when summing mismatched integer widths with rollover. The solution is to either post-trim off the high bits in the larger integer or pre-scale the smaller integer up to the larger.

cgracey · 2020-11-08 15:22

Evanh, would it be possible to use the code in the P2 silicon documentation to test these modes?

EDIT: I fixed the error in the programs below, where there were eight zeros in a row, where there should have been seven.

SINC2 Filtering Mode (%01)

This mode performs SINC2 filtering, which requires some software interaction in order to realize ADC samples.

To begin SINC2 filtering:

       WRPIN   ##%100011_0000000_00_11000_0,#adcpin   'configure ADC+filter pin(s)
       WXPIN   #%01_0111,#adcpin                      'SINC2 filtering at 128 clocks
       DIRH    #adcpin                                'enable smart pin(s)

Pin interaction must occur after each sample period, so it may be good to set up an event to detect the pin's IN going high:

       SETSE1  #%001<<6 + adcpin                      'SE1 triggers on pin high

.loop  WAITSE1                                        'wait for sample period done
       RDPIN   x,#adcpin                              'get SINC2 accumulator
       SUB     x,diff                                 'compute sample
       ADD     diff,x                                 'update diff value
       SHR     x,#6                                   'justify 8-bit sample
       'use x here                                    'use sample somehow
       JMP     #.loop                                 'loop for next period

x      RES     1                                      'sample value
diff   RES     1                                      'diff value

Note that it is necessary to shift the computed sample right by some number of bits to leave the ENOBs intact. For SINC2 filtering, you must shift right by LOG2(samples per period)-1, which in this case is LOG2(128)-1 = 6.


SINC3 Filtering Mode (%10)

This mode performs SINC3 filtering, which requires some software interaction in order to realize ADC samples.

To begin SINC3 filtering:

       WRPIN   ##%100011_0000000_00_11000_0,#adcpin   'configure ADC+filter pin(s)
       WXPIN   #%10_0111,#adcpin                      'SINC3 filtering at 128 clocks
       DIRH    #adcpin                                'enable smart pin(s)

Pin interaction must occur after each sample period, so it may be good to set up an event to detect the pin's IN going high:

       SETSE1  #%001<<6 + adcpin                      'SE1 triggers on pin high

.loop  WAITSE1                                        'wait for sample period done
       RDPIN   x,#adcpin                              'get SINC3 accumulator
       SUB     x,diff1                                'compute sample
       ADD     diff1,x                                'update diff1 value
       SUB     x,diff2                                'compute sample
       ADD     diff2,x                                'update diff2 value
       SHR     x,#7                                   'justify 14-bit sample
       'use x here                                    'use sample somehow
       JMP     #.loop                                 'loop for next period

x      RES     1                                      'sample value
diff1  RES     1                                      'diff1 value
diff2  RES     1                                      'diff2 value

evanh · 2020-11-08 17:31

I'd want to add at least some debug printing to that. I'll need to get up to speed on PNut again ... I'm off to work right now ...

evanh · 2020-11-09 04:09

I dropped your Sinc3 example into my wrapper code and added only the print - it has all the hallmarks. It's probably one of the worst cases I've seen yet. Here's a short piece it produced: (Includes the SHR #7)

evanh · 2020-11-09 06:00

Okay, I've now added a buffer so that the loop timing isn't hindered by the print routine:

_main
       WRPIN   ##%100011_00000000_00_11000_0,#adcpin  'configure ADC+filter pin(s)
       WXPIN   #%10_0111,#adcpin                      'SINC3 filtering at 128 clocks
       DIRH    #adcpin                                'enable smart pin(s)

       SETSE1  #%001<<6 + adcpin                      'SE1 triggers on pin high

	mov	bcdlen, #8
	wrfast	#0, ##$2000
	mov	count, #50

.loop  WAITSE1                                        'wait for sample period done
       RDPIN   pa,#adcpin                             'get SINC3 accumulator
       SUB     pa,diff1                               'compute sample
       ADD     diff1,pa                               'update diff1 value
       SUB     pa,diff2                               'compute sample
       ADD     diff2,pa                               'update diff2 value
'       SHR     pa,#7                                 'justify 14-bit sample
	wflong	pa
	djnz	count, #.loop                         'loop for next period


	rdfast	#0, ##$2000
	mov	count, #50
.loop2
	rflong	pa
	call	#itoh
	call	#putnl
	djnz	count, #.loop2
	jmp	#$


diff1  long	0
diff2  long	0
count	long	0

Here's the new output. It's more regular but still stupid readings.

Total smartpins = 64   1111111111111111111111111111111111111111111111111111111111111111
Rev B silicon.  Sysclock 100.0000 MHz
00057580
001aca80
00200000
00200000
00200000
00200000
00200000
00200000
00200000
00200000
00200000
f8200000
08200000
00200000
00200000
00200000
f8200000
08200000
00200000
00200000
f8200000
08200000
00200000
f8200000
08200000
f8200000
08200000
00200000
f8200000
08200000
f8200000
08200000
f8200000
08200000
f8200000
08200000
f8200000
08200000
f8200000
00200000
08200000
f8200000
00200000
08200000
f8200000
00200000
08200000
f8200000
00200000
00200000

Ariba · 2020-11-09 07:42

Here is a testcode that works.
There are erroneous bits in the 2 highest bits of the result, which need to get masked out.
Chips code has en error in the ADC configuration, the second field from left should only have 7 zeroes, not 8.

'' ADC sinc3 Test  by Ariba

  _clkfreq  = 180_000_000
  
  ADCPIN = 0

var
  long  sample

     
pub main()
  coginit(16, @adccog, @sample)                        'start ADC loop in new cog
  repeat
    waitms(300)
    debug(udec(sample))                                'show adc values in buffer

DAT
        org  0
adccog  WRPIN   ##%100011_0000000_00_11000_0,#ADCPIN   'configure ADC+filter pin, gain 1
        WXPIN   #7+32,#ADCPIN                          'SINC3 filtering at 128 clocks
        DIRH    #ADCPIN                                'enable smart pin

        SETSE1  #%001<<6 + ADCPIN                      'SE1 triggers on pin high

.loop   WAITSE1                                        'wait for sample period done  1.4 MHz!
        RDPIN   x,#ADCPIN                              'get SINC3 accumulator
        SUB     x,diff1                                'compute sample
        ADD     diff1,x                                'update diff1 value
        SUB     x,diff2                                'compute sample
        ADD     diff2,x                                'update diff2 value
        SHR     x,#7                                   'justify 14-bit sample
        AND     x,##$3FFFF                             'remove erroneous high bits
        WRLONG  x,ptra                                 'use sample somehow
        JMP     #.loop                                 'loop for next period

x       RES     1                                      'sample value
diff1   RES     1                                      'diff1 value
diff2   RES     1                                      'diff2 value

Andy

evanh · 2020-11-09 07:46

Thanks Ariba. I'd not even tried to go over any of that. It brings the output back to a more recognisable state now. It has the glitches still but now it also has meaningful values in the mix too. eg:

Total smartpins = 64   1111111111111111111111111111111111111111111111111111111111111111
Rev B silicon.  Sysclock 100.0000 MHz
0000ce1f
000d1917
0018432e
0017ae08
0016b904
0015e3d6
00152ad0
0014832f
0013f310
001374c6
0013075a
0012af33
00125a41
00120e58
f811cde7
081195ba
001167f7
00113c4e
00111333
0010f6f2
f810daed
0810c0f1
0010a9c7
001095f0
001084ef
f8107821
08106abd
00106052
001056cd
f8104d41
081045dd
001041c4
00103cdc
f81036b6
0810322a
00102f29
f81029c8
081027e0
001023c0
f8101f70
08101e45
00101da9
f8101eae
08101ccf
00101b5e
f81018ee
08101897
f81015bf
08101474
0010172e

evanh · 2020-11-09 07:55

Ariba,
How to pass hubRAM buffer address with your example? I'd want to print consecutive samples like I've done with mine.

EDIT: Oh, I think all I have to do is change "sample" into an array of longwords.

Ariba · 2020-11-09 08:00

Just make 'sample' an array: sample[1024] for example.
You get the address in PTRA when you start the cog with @sample as 3rd parameter in coginit, as I have done.

Have you added the AND instruction into the sinc3 filter loop?

Andy

evanh · 2020-11-09 08:14

Ariba wrote: »

Have you added the AND instruction into the sinc3 filter loop?

It's up to 5 high bits for me. That I can see anyway.

evanh · 2020-11-09 08:43

Wow, that's cool, DEBUG() works inside the pasm code too!

cgracey · 2020-11-09 22:30

So, is there a problem, still?

It sounds like I have a documentation error, at least.

cgracey · 2020-11-09 22:33

I got rid of the extra 0's in the Google Doc example programs.

evanh · 2020-11-10 03:48

The smartpins are still producing glitches, that hasn't changed. Andy's idea of masking them seems to work because, for Sinc3, they appear to only be in the five most significant bits. As long as those high bits aren't needed then it can work with an AND instruction tacked on.

Ariba · 2020-11-10 04:20

You can't go higher than 18 bits resolution, so the highest 5 bits will never be used. But I also wonder where this erroneous bits came from.

Andy

evanh · 2020-11-10 04:49

Right, yeah, it's starting to fall into place for me now. So the smartpin's Sinc3 accumulators are 27 bits each. And Sinc3 means the maximum decimation period is 2^(27 / 3 = 9) or 512 bit-clocks.

So, I guess there is some kind of 27-bit vs 32-bit roll-over mismatch at play here. And the simple fix is to mask out the most significant five bits of the resulting 32-bit sample.

evanh · 2020-11-10 04:52

And I presume Sinc2 is 26-bit accumulators, therefore that will need the most significant six bits masked out.

EDIT: Corrected the size.

evanh · 2020-11-10 05:04

So, hardware is probably okay after all. I guess we never tested a mismatch in register sizes when simulating SincX.

I did test "pruning" the lower bits, which produced increased granularity, but not the upper bits.

EDIT: Ha, I'll try just that, shift the decimated data up by five bits before diff'ing ...
EDIT2: Yep, works without the mask then. No surprise I guess. Six of one, half a dozen of the other.

evanh · 2020-11-10 05:16

Well, that mapping could have been integrated in the smartpin. That would've been nice if we'd been paying attention at the time.

Cluso99 · 2020-11-10 06:13

There's always something that slips past. At least it's not a show-stopper. Just a minor quirk

evanh · 2020-11-10 15:59

Intriguing ... further testing reveals Sinc2 seems to produce 27-bit wide decimations, same as Sinc3. Same masking works for both modes.

This means the Sinc2 decimation period can be a little more than the upper listed 8192 bit-clocks. I calculate up to 2^(27/2 = 13.5) or 11585 bit-clocks. This can be set with a WYPIN ... which I did without trouble.

evanh · 2020-11-10 16:52

Chip,
How was the effective number of bits calculated?

evanh · 2020-11-11 08:56

My issue with pins P0-P3 has gone away - https://forums.parallax.com/discussion/comment/1502628/#Comment_1502628
I figure it was an artefact of this glitch. Not that I can remember exactly what code I used at the time.

TonyB_ · 2020-11-11 10:15

So, apart from too many zeros in a row in the Sinc2 program (now fixed) there is nothing wrong with SincX?

evanh · 2020-11-11 18:12

The software also needs to mask or bit-shift (normalise) the sample/decimation data.
Using snippet of Chip's example:

.loop  WAITSE1                                        'wait for sample period done
       RDPIN   x,#adcpin                              'get SINC2 accumulator (27-bit wide)

       SHL     x,#5                          'justify/normalise to most-significant-bit
       SUB     x,diff                                 'compute sample
       ADD     diff,x                                 'update diff value
       SHR     x,#11                                  'justify 8-bit sample
       'use x here                                    'use sample somehow
       JMP     #.loop                                 'loop for next period

Or:

.loop  WAITSE1                                        'wait for sample period done
       RDPIN   x,#adcpin                              'get SINC2 accumulator (27-bit wide)

       SUB     x,diff                                 'compute sample
       ADD     diff,x                                 'update diff value
       AND     x,##$7FF_FFFF                 'remove erroneous high bits
       SHR     x,#6                                   'justify 8-bit sample
       'use x here                                    'use sample somehow
       JMP     #.loop                                 'loop for next period

TonyB_ · 2020-11-12 10:07

evanh wrote: »

The software also needs to mask or bit-shift (normalise) the sample/decimation data.
Using snippet of Chip's example:

.loop  WAITSE1                                        'wait for sample period done
       RDPIN   x,#adcpin                              'get SINC2 accumulator (27-bit wide)

       SHL     x,#5                          'justify/normalise to most-significant-bit
       SUB     x,diff                                 'compute sample
       ADD     diff,x                                 'update diff value
       SHR     x,#11                                  'justify 8-bit sample
       'use x here                                    'use sample somehow
       JMP     #.loop                                 'loop for next period

Or:

.loop  WAITSE1                                        'wait for sample period done
       RDPIN   x,#adcpin                              'get SINC2 accumulator (27-bit wide)

       SUB     x,diff                                 'compute sample
       ADD     diff,x                                 'update diff value
       AND     x,##$7FF_FFFF                 'remove erroneous high bits
       SHR     x,#6                                   'justify 8-bit sample
       'use x here                                    'use sample somehow
       JMP     #.loop                                 'loop for next period

Saving one long and two cycles:

Or:

.loop  WAITSE1                                        'wait for sample period done
       RDPIN   x,#adcpin                              'get SINC2 accumulator (27-bit wide)

       SUB     x,diff                                 'compute sample
       ADD     diff,x                                 'update diff value
       ZEROX   x,#27                         'remove erroneous high bits
       SHR     x,#6                                   'justify 8-bit sample
       'use x here                                    'use sample somehow
       JMP     #.loop                                 'loop for next period

evanh · 2020-11-12 10:55

Cool, I'd never learnt ZEROX. I'll keep that one in mind for similar situations.

evanh · 2020-11-13 02:08

Detail correction, it's ZEROX x,#26

And I do still have issues with me beleaguered glob-top part. When heated, it is exhibiting loss of VIO on certain pin groups. The ADC bitstream changes to either all high or all low. The normal packaged prop2 is giving good results when heated so I know it's not the software.

I don't think it is a solder joint problem, or at least not at the prop2 package. I've tried a number of times now to touch up those supply pins, and the nearby VDDs too. And it's not the LDO regulators either since the other group of four pins supplied by each of those LDOs doesn't have an issue.

Pity, since I was hoping to compare the two parts when mapping out all the ADCs.

EDIT: Here's a piece of a report showing pins P48-P55. All powered from the same LDO regulator. P48-P51 are flatlined, while P52-P55 are normal. The values across the report alternate between GIO and VIO input source for the ADC. Each pair across uses a different method of sampling.

  P48    262144    262144  33553056  33553056         0         0  33554432  33554432
  P49         0         0         0         0         0         0         0         0
  P50         0         0         0         0         0         0         0         0
  P51         0         0         0         0         0         0         0         0
  P52     41909    213960   5363048  27389198   5368593  27388633   5386802  27401617
  P53     45927    220955   5880889  28275544   5884516  28275423   5875670  28264824
  P54     48958    223988   6269300  28668312   6266466  28669109   6265835  28647257
  P55     42524    215505   5445405  27587886   5448878  27584620   5436067  27598580

jmg · 2020-11-13 04:28

evanh wrote: »

I don't think it is a solder joint problem, or at least not at the prop2 package.

Could the higher thermal expansion of the glob, have stressed an inner bond wire to the point it has lifted, to be touching only ?
That would match your symptoms.

evanh · 2020-11-13 04:36

jmg wrote: »

Could the higher thermal expansion of the glob, have stressed an inner bond wire to the point it has lifted, to be touching only ?
That would match your symptoms.

Yeah, that's how I'm thinking too. I cooked the whole board pretty bad a while back when desoldering one of the USB power switch chips. The solder under the prop2 reflowed, and the board has a brown tint now.

evanh · 2020-11-13 09:55

Temperature signal of ADC drift from the VIO input is about 0.4% of full scale. So, down 8 bits to start. First brush, it's not particularly linear either. The slope gets shallower at higher temperatures. EDIT: It's in the region of 200 uV per degree centigrade.

Problem with SincN filtering in smartpins

Comments