AM3358: ADC causing input to drift up consistently

Hello Walter, 

Thank you for the query,

Looks like you are  looking to use the ADC0 as ADC - is that correct, Did you try measuring the same with ADC5..7?

Walter Cromer said:

We are using a BeagleBone Black. 

Pls help me with the version you are using.

Regards,

Sreenivasa

Thanks for your reply. 

That's a good question.  So, this particular sensor interfaces to the BeagleBone black which runs on the AM3558 SOC.  We have a custom PCB that the sensor interfaces to the BeagleBone through so it is actually a fixed attachment to ADC channel 0.   I can't move it without ripping up the PCB and patching it over to another channel.   That said, we did recently change the microcontroller out.

Also, we see the drift by monitoring the analog sensor output with a separate data acquisition system and have always had the input go into the same channel on it.  I can easily move this input to a different channel on the DAS to see if there might be an issue with the DAS channel.  I will try this.

I am suspecting that the problem lies in how the ADC is configured by the ARM/Linux kernel driver and the direct register configuration we perform when the PRU sets up the ADC and reads it.  This morning we did the following.

The Linux kernel for the ADC loads when the MCU boots and remains enabled.

In our PRU C code, we have a procedure called ADC_Configure that configures three channels of ADC to be run in one-shot mode, 4 averages and three steps.  We don't change any other parameters.  

Hello Walter, 

Thank you.

Walter Cromer said:

Also, we see the drift by monitoring the analog sensor output with a separate data acquisition system and have always had the input go into the same channel on it.  I can easily move this input to a different channel on the DAS to see if there might be an issue with the DAS channel.  I will try this.

Ok, so the drift you are seeing is at the sensor output (analog value) if i understand correctly.

Walter Cromer said:

Also, we see the drift by monitoring the analog sensor output with a separate data acquisition system and have always had the input go into the same channel on it.  I can easily move this input to a different channel on the DAS to see if there might be an issue with the DAS channel.  I will try this.

Please let me know if you see any difference.

Is there a filter you have at the input and help me understand the sampling frequency set and sampling rate set.

Regards,

Sreenivasa

We visually see the drift on a real-time display from the independent data acquisition system and the values measured by it closely match the values measured by the AM3558's TSCADC channel 0.   That said, because of an impedance matching issue, there is a unity gain / voltage follower circuit between the point where the sensor output connects to the AM3558s TSCADC channel 0 and the input channel on the independent data acquisition system.   It has always been in place and is in place when the first two tests mentioned above are executed.  So I don't think the voltage follower is causing this problem.   I am very suspicious of that the problem is something with a difference in how the ADC is configured by the PRU vs. the ARM program.

We do not have a filter on the input.

Hello Walter, 

Thank you.

I came across the below thread that you could read through 

(+) AM3352: AM3352 TSC_ADC_SS(Touch Screen Controller-ADC-SubSystem) module config all channels for use in general ADC , when sampleing channel 1 and channel 7 will occur some sharp impulse noises， is any wrong somewhere ? how can i solve this problem ? - Processors forum - Processors - TI E2E support forums

(32) AM3354: Inquiry about ADC (Linux SDK) - Processors forum - Processors - TI E2E support forums

(+) AM3358: ADC_CLK spec change - Processors forum - Processors - TI E2E support forums

Pls help me understand if you are terminating the un used ADC channels. There is a ADC errata.

(33) AM3356: AM3356 Unused Analog input and ADC - Processors forum - Processors - TI E2E support forums

Regards,

Sreenivasa

Sreenivasa, 

I'll review these carefully soon.  Thank you for them.

As for terminating the unused ADC channels, we do not do that.  

Walter

Hello Walter, 

Thank you.

In addition to changing the ADC, you might want to also try doing some filtering.

Regards,

Sreenivasa

How would filtering change the dc offset drift.  I don't understand how that applies here.

Hello Walter, 

Thank you.

Since i am not familiar with the implementation, I do not have a explanation other that the thought that the input switching of the S/H cap could be affecting that the filter could isolate or an additional test case.

Regards,

Sreenivasa 

pardon, me, but what is "S/H cap".  (It's been a long day already)

Hello Walter, 

Thank you and no worries.

Refer data sheet for the ADC features:

– 12-Bit Successive Approximation Register (SAR) ADC

– 200K Samples per Second

– Input can be Selected from any of the Eight Analog Inputs Multiplexed Through an 8:1 Analog Switch

– Can be Configured to Operate as a 4-Wire, 5- Wire, or 8-Wire Resistive Touch Screen Controller (TSC) Interface

This is the internal muxing of the ADC inputs and capturing the analog input and the process of converting to digital.

Please refer below sections of the TRM

12.2.3 TSC_ADC Pin List

12.4 Operational Modes

We have an FAQ that provides links to the key collaterals including the data sheet and TRM that you could use.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1189177/faq-am3351-am3352-am3354-am3356-am3357-am3358-am3359-custom-board-design-collaterals-to-get-started

Regards,

Sreenivasa

Thank you very much!

Hello Walter, 

Thank you and no worries.

Regards,

Sreenivasa