I am having trouble getting the ADC to work on a Z8F042A chip.

I initialize the ADC with:
ADCCTL1 = 0x80;
ADCCTL0 = 0x08;

I also configure PB3 for Alt function and AFS1 = 0x08

The problem is I can't set CEN to 1 in ADCCTL0 register.
the command ADCCTL0 |= 0x80; does not set the bit
Also ADCCTL0 = 0x88; does not set CEN
When viewing the register in the debug watch, nothing happens

I have tried to used App. Note AN0284 as a reference, but it has been very confusing for me. The port, peripheral setup, and comments seem to be inconsistent.

The following code is from adc.c in AN0284 where the ports and ADC are initialized:

********************************************************
void Init_ADC(void)
{
PBAF = 0x23; //PB0 as ANA0 and PB5 as Vref
PBAFS1 = 0x23;

ADCCTL0 = 0x30; //internal 2V vref, ANA0
ADCCTL1 = 0x81; //Single-ended, buffered input with unity gain
}
************************************************************

1. If the ADC is being setup for internal 2V ref, then why does the comment say "PB5 as Vref"?

2. Shouldn't ADCCTL0 = 0x31 instead of "ADCCTL0 = 0x30;" to select ANA0 for analog input?

Now here's part of the code from adc.c where an analog conversion is started:

***********************************************************
/***********************************/
/***** get sample ADC from Vin *****/
/***********************************/


ADCCTL0 |= 0x80; //enable ADC
while (ADCCTL0 & 0x80); //wait for conversion to be completed
VInHigh=ADCD_H; //ADC high byte
VInLow=ADCD_L; //ADC low low byte
ADC_data = (VInHigh <<8)| (VInLow); //ADC output word

ADC_data = (ADC_data >> 3) & 0xFFF; //12-bits ADC
*************************************************************

It appears that the ADC is initialized for continuous conversion with the code "ADCCTL0 = 0x30;" , but the "get sample" code appears to be operating with single shot conversions. From what I have read in continuous conversion mode the ADCCTL0 CEN bit (bit 7) is only 1 for the first conversion and after that point it remains 0.

So, can anyone explain these discrepencies in the code from Application Note 0284?

One additional note: I have an old rev B part. SHould I just use ZDS II 4.9.2 that I have?

Hi Chris
The PB5 is being used as a Vref out pin. If you look at the settings for the ADCCTL0, bit 5 controls the VREF OUT capability. This this bit is set, the internal ADC reference buffered and driven out to the Vref pin (PB5).
According to the product specifications, bits [3:0] should be 0000b for ANA0.
The CONT bit is set, which puts it in a continuous mode, although it is using a single shot conversion technique. I would set ADCCTL0=0x20.

As Tom pointed out I was not using the ADC channel I though. However, I am still having issues with fluctuating ADC values. They fluctuate by around 20 counts (out of 10 bits).

So, I have a specific question regarding app note AN0284 ADC Compensation. In table 4 it shows a 0.1V input even though the ADC is setup for 1x Buffered, but on the part datasheet it says not to use less 0.3V input in buffered mode.

So, is it possible to measure 0.1V in buffered mode? Could buffered mode help my ADC fluctuations?

Well, I figured out that my ADC fluctuation was on the actual signal. So, I just needed to add a low pass filters.

However, I am having trouble getting an accurate ADC value. I have implemented the "built-in" ADC-Offset and ADC-Gain compensation, my ADC counts are low by ~40 counts. This is using 2V internal reference in either buffered or unbuffered.

Anyone have any suggestions? Is a manual ADC calibration going to get better results?

I also had problems with fluctuations in the data, but it had to do with my data types. You might want to double check how your data types are declared.

ADC_data = (VInHigh <<8)| (VInLow); //ADC output word

Here, if VInLow is defined as a char instead of unsigned char, you will not get the expected result. The compiler will promote VInLow to a signed int, and will pad the high byte with the MSB of VInLow. Since VInLow's MSB contains bit 4 of the actual ADC value, you will sometimes get 0x00 for the high byte, and others will get 0xFF. Of course, you'd want it to always be 0x00 so you can properly do the bitwise OR.