# Why the ADC conversion causes the analog input pin of PIC to be grounded at the beginning of the conversion?

using MPLAB X IDE v5.35 PIC16LF19176

I used PIC ADC analog inputs several times, the conversion always gives me the proper results. Looking at the input with the scope confuses me.

The scope channel one is attache to the power source for the sensor:

The scope channel two is attached to the sensor output wire indirectly - via analog multiplexer. Multiplexer is at that point switched permanently to channel 5 and enabled (no control signal changes during testing). The scope is attached to the top of the R5 resistor, which is at that point in parallel with the sensor output, thus loading the sensor with 7k87 resistor. Left multiplexer 'brings' the 3V excitation to the sensor via signal MUX5_A (test point TP1), and sensor returns its output via right multiplexer via signal MUX5_B (TP2):

The attached active sensor has three wires: power +3V; GND; and output 0..3V. The sensor output is connected to PIC analog input, which is used for ADC conversion. The sensor power is turned ON-OFF by the PIC via dedicated DC/DC regulator.

After the sensor power is turned ON, I start the PIC ADC conversion. As soon as the GO bit is set (conversion start), the input pin gets grounded for about 10 msec. Then the input is 'released', sensor shows proper values. Conversion is still active for another 17 msec and it appears to return proper result.

In the case you wonder, I did try to debug the code and put various delays. The grounding effect is only when the conversion starts.

The attached picture shows two consecutive conversions (I am calculating an average), both of which start with unwanted pin grounding.

I do not wish to put the sensor's output to this stress. Can someone tell me, why is the PIC input pin grounded this way?

The ADC conversion was actually generated by MPLAB:

adc_result_t ADCC_GetSingleConversion(adcc_channel_t channel)
{
// select the A/D channel

// Turn on the ADC module

//Disable the continuous mode.

// Start the conversion
// Now the scope shows signal gets grounded...

// Wait for the conversion to finish
{
// in the middle of this conversion, signal goes back up...
}

// Conversion finished, return the result
}


It might be useful to see the ADC initialization routine:

/**
* ADC is initialized to highest possible accuracy at the cost of slowness (conversion time 37 msec)
* During the initialization the GIE must be disabled
*
* We are set to:
* - basic mode
* - clock FOSC/128
* - result is aligned to right
* - reference voltage used is VDD of the processor
*
*/
{

// ADC Interrupt disable, clear all its flags:
{
}

// set the ADCC to the options selected in the User Interface
ADREF = 0x00;   // Vref = Vdd (because external DC/DC RT9013-3V3 accuracy is +-2%, internal Vref +-4% => Vdd is more accurate than internal Vref)
ADCLK = 0x3F;   // slowest setting, but most accurate // conversion took about 37 msec
}

• Explain what scope1 is and what scope 2 is connected to. Aug 23 '20 at 10:36
• Do you know the output impedance of the sensor's output pin? Aug 23 '20 at 11:25
• @anrieff: I believe the sensor has an opamp buffer, because when I simply power the sensor with 3V power supply, and it outputs let's say 1V, I can load it with any resistor, like 1kOhm and the output doesn't change. I am aware I am loading it with 7.87kOhm - but I checked that doesn't change its output when powered up separately. Aug 23 '20 at 11:59
• Design is mine, but only after I followed exactly the sensor manufacturer detailed requirement with their schematics - I have added the CPU. Now, I will not be offended... you can freely go and say what you wanted in the first place :) Aug 23 '20 at 16:03

There is an answer for your question but what details you put in your post, and more importantly what you did not put in your post, made finding the correct response a real challenge.

First off you cannot be using any dsPIC, it must be one of the 8-bit controllers. Most likely one of the PIC18FxxQxx types with an ADC function block that supports the Capacitive Voltage Divider (CVD) Feature.

Second the cut and paste job you did of the ADC code you alleged was generated by MPLAB is crap. The initialization sets up the ADC for use in the touch / proximity sensing mode using the CVD feature. This feature does in fact connect the ADC input pin to VSS for a specific period before the conversion begins by setting the ADPRE register to a non-zero value.

Finally the code you posted to setup the ADC conversion clock period is wrong in every possible way it can be wrong and still sort of produce a conversion result.

Did you comprehend any part of the data sheet that describes the ADC function block?

• (Question corrected) I am upvoting your answer just for your expertise. You are correct, it is not a dsPIC :( I often use dsPICs, work on many projects in parallel, sorry for my mistake. You could be a bit nicer with your language, but that is just my opinion. Still, your words are helpful. I am going to look at the code in detail again. I probably do not understand all in the documentation, otherwise I would not need to post the question. The code came from MPLABX, I did not write it - that is not an excuse, because I DID set up the MPLAB MCC forms. So indirectly I wrote the code. Aug 23 '20 at 22:22
• @EmbeddedGuy, I can see that I was blunt in my comments. I do apologize. As an offer of contrition I posted on git hub an MPLABX project created with the MCC that reads an ADC input voltage on pin RC3 then sends an ASCII string of the raw hex value to UART1 at 9600 baud. Aug 24 '20 at 0:36
• This is the best apology - with a gift! I am not only thanking for that, but thank you and Stack exchange: it helps engineers to grow. I learned a lesson and will assume less. The product will be out with a much better code, and will be within the Friday deadline :) I am positive there are others who will do the same mistake - this question will help them, too. Aug 24 '20 at 9:01

As @Dan1138 suggested, the problem was in initializing the ADC with CVD incorrectly activated. The Microchip manual also states: If there is a device attached to (analog input) pin, Precharge should not be used.

The solution was to set both Precharge registers to 0:

// ADPRE 0;
ADPREL = 0x00; // was incorrectly 0xFF