Forbidden values in ADC output

Sure -

1. Unfortunately I don't have a way to vary the voltage systematically for this test (or if it's possible to do using the debugger I don't know how), so I'm slowly increasing the stimulus to the sensor that's being read from (nearly) nothing to saturation. 
2. The sensor is being taken from (nearly) no stimulus to saturation over the course of a minute or two.

3. The External Vref is set to 2.000V with negative input Vss

4. The firmware samples at 20Hz, but in fact every 1/20s it calls ADC_Wakeup(), _getADC() three times in succession, then ADC_Sleep().  (The data I've provided is the third reading at every 1/20s interval).  I've tried adding a 10us delay between _getADC() calls and also calling _getADC() only once but that doesn't solve the problem.

Unfortunately I won't be able to provide the project.

thank you, and let me know if I can provide any other information to help solve the problem!

-Reinier.

Rajiv,

The firmware runs a loop which starts a timer, takes a measurement, prints it to console, then waits until the timer hits 50000 (for 20Hz sampling).  I've rerun the experiment and included a timestamp with each measurement, and attached it here.  Unfortunately it only has second resolution, but there are neatly 20 samples per second so I don't think timing is the issue.

Also unfortunately it's not straightforward to hook my test board up to a controlled voltage source.  But as you say I don't think there's a problem with the sensor.

What's most striking to me is that the blocks of allowed values (with few exceptions) are 64*k+1 .. 64*k + 16+8+4+2, with k=0, 1, 2...  See the histogram where I've drawn red and green dotted lines at these boundaries.

The issue also becomes apparent when I plot the binary representation of the ADC output: the 32s bit doesn't flip when I expect it to.

All in all to me it looks like the summation in the ADC Sequencer isn't working as expected.  Is there any reason this can happen?  I don't think I'm pushing the system too much - only one channel, not sampling too fast, etc.

thanks,
Reinier.

Hi Rajiv,

I've recently been able to come back to investigating this issue, and I'm still no closer to understanding what's going on.

My recent tests have used 32x averaging with the Accumulate averaging mode.  I'm using a PSoC 4200BL series device, and I found those registers at 0x403axxxx:

1. SAR_ANA_TRIM (0x403a0f00): 0x00000012

2. SAR_DFT_CTRL (0x403a0030): 0xa0000002

I've attached a number of recent tests that show the strange behavior very clearly.  These tests involve a light sensor pointed outside during sunrise, i.e. a very gradually increasing sensor voltage.  The project samples the ADC at a sampling rate of 79Hz, and in fact runs _getADC() (see original post) 3 times for each sample.  I save the 3rd sample, and that's the measurement you see in the first column of the attached .csv files.

I've also included the binary representation of the measurements.  If you plot these bitwise you can get a better sense of the strange behavior (see attached example of capture 08)  In particular, bit 9 doesn't flip as expected.  In fact bits 12..10 behave more like I expect bits 11..9 to behave (or conversely bits 8..0 look like they should be upshifted to 9..1).  I've stared at these bits for days but have not managed to figure out what the rhyme or reason is in the bit flips.

I noticed that the ADC getResult16() method actually peeks at a 32bit register and takes the low 16 bits.  I also took a look at the upper 32 bits for any clues.  I saw values of 0x8000, 0xa000, 0xe000.   Does this make sense, or should they never change?

I'm working on a version of our project that you'll be able to run, but maybe in the meantime can you have a look at these samples and see if you can make anything of it?

thanks,
Reinier.

Hi Rajiv,

I am using the ADC SAR SEQ P4 component v2.50, and programming my device with PSoC Creator 4.2.

-Reinier.