PIC 18F46K80 ADC bug

[Bachman]

Hello!

See the story here: http://www.matrixtsl.com/mmforums/viewt ... 54&t=17014

[Benj]

Hello,

Have you tried playing with the conversion speed setting as part of the ADC component properties. I've looked through the code and can't see many differences between what you posted.

[Bachman]

Hello!

The dataseet says, when using the controller at 64 MHz (because of a GLCD), the conversion speed must be az slow as possible. At this time, i'm far away from my workshop, i'll make more tests to find out, what is the problem.

In the ADC properties, the "Aquisition cycles" parameter what means? Microseconds or cycles of the controller (time depends of the clock frequency)?

[Benj]

Hello,

Ok no problem let me know when you have time.

The acquisition cycles property sets the precharge delay and is in micro seconds rather than an instruction count.

The conversion speed controls how fast the ADC conversion is done.

[medelec35]

Hi Bachman,
to me It looks like adcon2 is not being updated with correct value , so I still believe it is a bug.
Conversion speed is being passed but the acquisition time select bits (3 to 5) are not.
Without these bits set, even with a high Acquisition set in properties od ADC component does not seem to make any difference.
This can be proven by Making a backup of PIC_CAL_ADC.c that's in:
C:\Program Files (x86)\Flowcode 6\CAL\PIC (If 64 bit windows)
or
C:\Program Files\Flowcode 6\CAL\PIC (If 32 bit windows).
Replace with the temporary attached file.
Recompile and see if it works any better.
If it does, it's defiantly not the correct final solution (best left to matrix) as I have only fudged it to work, hence stating only temporary .

Martin

[Benj]

Hello,

Thanks for that Martin, I would be interested to see the difference it makes on hardware.

Martin changed the ACQT A/D Acquisition Time select from 0 TAD to 20 TAD.

Now this is an automatic pre-charge delay that happens after you enable to ADC module and set it going and before the ADC conversion starts.

I always use a value of 0 here as we have our own pre-charge delay before we start the conversion.

Code: Select all

		delay_us(T_Charge);										//wait the acquisition time
		adcon0 = adcon0 | 0x02;									//begin next conversion

The T_Charge value comes from the ADC Acquisition time property.

But I would like to know if this does improve things. Maybe we could drop the software delay altogether on the devices that have the built in pre-charge functionality.

[medelec35]

Hi Ben,
No problem.
I received 18F46K80 yesterday, that's how I could determine if the fix I posted works or not.
I can test tonight when I get home and let you know.

Martin changed the ACQT A/D Acquisition Time select from 0 TAD to 20 TAD.

Now this is an automatic pre-charge delay that happens after you enable to ADC module and set it going and before the ADC conversion starts.

I always use a value of 0 here as we have our own pre-charge delay before we start the conversion.

Ah I understand whats going on now, Thanks for that.

Martin

[medelec35]

Not sure why?
When I add:

Add AQ Delay1.png

(48.94 KiB) Downloaded 6160 times

I get:

Code: Select all

ADC_Test My setup.c
Starting preprocessor: "C:\Program Files (x86)\Flowcode 6\compilers\pic\boostc\pp.exe" "ADC_Test My setup.c" -i "C:\Program Files (x86)\Flowcode 6\compilers\pic\boostc\include" -d _PIC18F46K80 -la -c2 -o "ADC_Test My setup.pp" -v -d _BOOSTC -d _PIC18 -d _CHAR_INDEX 

......................................................
C:\Program Files (x86)\Flowcode 6\CAL\PIC\PIC_CAL_ADC.c(4626:11): error: unknown identifier 'T_Charge'
C:\Program Files (x86)\Flowcode 6\CAL\PIC\PIC_CAL_ADC.c(4626:10): error: arguments of 'delay_us' don't match the parameters of call
C:\Program Files (x86)\Flowcode 6\CAL\PIC\PIC_CAL_ADC.c(4626:2): error: failed to generate expression
..
ADC_Test My setup.c success

failure
Completed BoostC compilation, return = 1

C:\Program Files (x86)\Flowcode 6\compilers\pic\boostc\boostc_18F.exe reported error code 1


FINISHED

This mean the other

Code: Select all

delay_us(T_Charge);

was not accessed so there never was any Acquisition delay?

Another thing that puzzles me if MX_UINT8 is used & I'm guessing the 8 just means it a byte type variable?
Then how comes Acquisition Cycles on ADC component is an integer type variable?

Changing delay_us(T_Charge) to delay_us(200) or delay_us(500) makes no difference ADC is not working with my fudge removed.

Just trying to find where T_Charge is calculated once Acquisition delay is entered within ADC component properties?

Martin

[Benj]

Hi Martin,

The T_Charge variable is a parameter for the Enable function.

I have also found that one of the switch cases did not have a break command, shouldn't be too bad as we use #if's around the code but potentially could cause a problem.

I've also added brackets around the if (Vref != 0) decision to make sure this is not causing the problem.

The delay should never need to be bigger than 255 us. in fact in most cases 1-10us is fine. I can see if we can limit the value your allowed to put in the property to try and make things simpler.

[medelec35]

Hi Ben,
I have replace the file from the above post and ADC does not work with it.
I did notice that you have got:

Code: Select all

else
			iRetVal = adresh;									//8-bit ADC

		adcon0 = adcon0 | 0x02;									//begin next conversion

		return (iRetVal);

Which is what I had before adding:

delay_us(T_Charge); //wait the acquisition time adcon0 = adcon0 | 0x02; //begin next conversion

If I add :

Code: Select all

delay_us(T_Charge);

To the file you just posted:

Code: Select all

iRetVal = adresh;									//8-bit ADC
         delay_us(T_Charge);	
		adcon0 = adcon0 | 0x02;									//begin next conversion

Then I just get same error as before:

Code: Select all

C:\Program Files (x86)\Flowcode 6\CAL\PIC\PIC_CAL_ADC.c(4626:11): error: unknown identifier 'T_Charge'
C:\Program Files (x86)\Flowcode 6\CAL\PIC\PIC_CAL_ADC.c(4626:10): error: arguments of 'delay_us' don't match the parameters of call
C:\Program Files (x86)\Flowcode 6\CAL\PIC\PIC_CAL_ADC.c(4626:2): error: failed to generate expression
..
ADC_Test My set up with ADC comp.c success

failure
Completed BoostC compilation, return = 1

C:\Program Files (x86)\Flowcode 6\compilers\pic\boostc\boostc_18F.exe reported error code 1

THat is why was trying to look in more depth at it.

The T_Charge variable is a parameter for the Enable function.

I'm just trying to see where it's first initialised and where the delay parameter is passed to it.

Martin

[medelec35]

Since getting error with

Code: Select all

delay_us(T_Charge)

placed just above

Code: Select all

adcon0 = adcon0 | 0x02; 

within

Code: Select all

 MX_UINT16 FC_CAL_ADC_Sample (MX_UINT8 Sample_Mode)

With new PIC_CAL_ADC.c again replaced delay_us(T_Charge) with delay_us(150) which is much more than required delay.
Result is same as original support.
Just a fixed value of 127, no matter what the input voltage is.
So far the fix I posted is the only way I have seen ADC component working with both 8 and 12 bits.

[Benj]

Hi martin,

What about if you place the code at the end of the enable function.

Code: Select all

void FC_CAL_ADC_Enable (MX_UINT8 Channel, MX_UINT8 Conv_Speed, MX_UINT8 Vref, MX_UINT8 T_Charge)
{
.....

		adcon0 = (0x01 | (Channel << 2));						//turn ADC on

		if (Vref != 0)											//assign VREF functionality
		{
			adcon1 = adcon1 | ((Vref & 0x03) << 4);				//Mod to allow FVR as VREF
		}
		delay_us(T_Charge);										//wait the acquisition time

		adcon0 = adcon0 | 0x02;									//begin next conversion
}

[medelec35]

Hi Ben,
That particular delay_us(T_Charge); is not causing an issue.
I'm guessing it because it has MX_UINT8 T_Charge within?
:

Code: Select all

void FC_CAL_ADC_Enable (MX_UINT8 Channel, MX_UINT8 Conv_Speed, MX_UINT8 Vref, MX_UINT8 T_Charge)

It's only when the new delay_us(T_Charge); is added to the

Code: Select all

MX_UINT16 FC_CAL_ADC_Sample (MX_UINT8 Sample_Mode)
	{
		MX_UINT16 iRetVal;

		while (adcon0 & 0x02);
		if (Sample_Mode)
		{
			iRetVal = (adresh << 4);							//12-bit ADC
			iRetVal = iRetVal | (adresl >> 4);
		}
		else
			iRetVal = adresh;									//8-bit ADC
             delay_us(T_Charge);
	   adcon0 = adcon0 | 0x02;									//begin next conversion

		return (iRetVal);
	}	

I tried adding void MX_UINT8 T_Charge within

Code: Select all

MX_UINT16 FC_CAL_ADC_Sample (MX_UINT8 Sample_Mode)

But that threw up different errors.

[Benj]

Hi Martin,

The pre charge delay shouldn't be needed for the second sample. The second sample is queued up so that the raw functions will work but as we are not switching channel for the raw functions we shouldn't need to repeat the pre charge. The standard ADC functions simple call the functions in this order so the second sample is essentially thrown away.

Code: Select all

    FC_CAL_ADC_Enable(0, 3, 0, 40);

    FCR_RETVAL = FC_CAL_ADC_Sample(0);

    FC_CAL_ADC_Disable();

Maybe this would work better in the enable function?

Code: Select all

		if (Vref != 0)											//assign VREF functionality
		{
			adcon1 = adcon1 | ((Vref & 0x03) << 4);				//Mod to allow FVR as VREF
		}

		adcon0 = (0x01 | (Channel << 2));						//turn ADC on

		delay_us(T_Charge);										//wait the acquisition time

		adcon0 = adcon0 | 0x02;									//begin next conversion

i.e. setting the VREF before we switch on the ADC peripheral.

[medelec35]

Hi Ben,
Thanks again for your suggestion, but unfortunately still the same results.
ADC value stuck on 127.

Only guessing but maybe the delay has to be done hardware internally by setting adcon2 rather then via software delays?

[Benj]

Yes it seems on this family it is their way using hardware pre-charge or no way. I'll have a dig and see if I have any I can test with. Otherwise I'll get a couple ordered.

There may be other device families with this issue so it would be good to get it bottomed before the pending release if possible. I suppose a simple get out would be to use the hardware pre-charge on any device that has it available but this will likely be a bit of work to go through all the device datasheets and list the settings in the ADC component.

[medelec35]

Hi Ben,
Its very easy to determine which devices has adcon2 registry.
What I just did was run Notepad++
Select Search, Find in files..
Then enter adcon2
Select the usual 3dots for browse and browse to C:\Program Files (x86)\Flowcode 6\compilers\pic
Then find all.
Sample of results:

adcon2 registry.png

(273.65 KiB) Downloaded 6010 times

I guess all those with adcon2 may not be affected.
If I have a diffent device with adcon2 here, I will test it for the ADC issue and will let you know.

[Benj]

Thanks Martin,

Much appreciated.