MCU-PLUS-SDK-AM263X: ADC increasing values on high measurement frequency

Hi Oleg,

That is definitely an interesting behaviour. Unfortunately, when I tried to reproduce this on my setup, I am seeing consistent  ~100 code word, on both 10ms and 1uS frequencies. Could you please help me understand your setup, I have the following questions.

1. when "By request", how is the trigger on the SOC changing from ePWM to RTI? 
   1. Is it software that is changing the SOC trigger? or are these 2 different SOC's triggered from different sources, sampling on same channel ? 
2. What is the ADCCLK prescaler and S/H window in both cases ?
   1. ADCCLK prescalre should be  >=3, and the S/H window (Acquisition window) should be >= 16 for AM263x ADC. Otherwise, the code words may not accurately represent the input voltage
3. Do you observe the input to the ADC increasing when probed to a scope while the high frequency sampling (where the code words increased from 100 to 320)?
4. What is the part number for the AM263x.

Thanks and regards,

Madhava 

Hi Madhava!

1. It is not changing, I have two different SOCs on one line. The first one is triggered by ePWM with constant frequency. The second (SOC 0, Hi priority) is triggered by RTI timmer by request, it does measurement 32 times and stops.

2. ADCCLK prescalre 4, Sample Window 16. All measurements are performed in the scope of one ADC module.

3. We did test, but we could not detect the peak.

4. part number am2632c DFHMZCQ1 33cg26W G1

I want to remind. This behavior I observe on lines where in the final I measure current.

Lines, where I do the measurement of voltage, works well.

Regards!

Hi Madhava!

I have updated the answers.

Regards!

Hi Oleg!

Thanks for sharing this info. I have tried to replicate this, but I am not able to observe this behavior on my setup. would it be possible to meet at discuss this over a call ?  

Thanks and regards,

Madhava

I do not mind.
When you will have the possibility to conduct a call?

Hi Oleg, 

It was nice interacting with you. As discussed, the SW part of the ADC usage is clean, and the possibility of ADC samples corruption is expected to be a ADC front end issue.  I have assigned this thread to a HW Expert, to help integrate the system with ADC inputs. 

Thanks and regards,

Madhava

Hi Madhava!
We did another test, and we observed peaks on the oscilloscope.

Hi Oleg, 

A few initial questions: 

• Can you correlate the conversion results you are getting to oscilloscope measurements at the AM263x ADC pins? 
• Can you please describe the input signal chain into the ADC pins of the AM263x? 
• Is the current sense you are measuring expected to ramp or oscillate or stay steady state within a few of the faster 1uS measurement periods? 
• What max conversion time do you need? The fastest this SAR will operate is 250ns/conversion  (4Msps). 

Can you please describe your full ADC setup again? I don't think the numbers above make sense. To be clear, can you quote the exact ADC control register values applied? 

• What is the ADCCTL2.PRESCALE value? 
• What is the ADCSOC0CTL.ACQPS value? 

Oleg Chaichenko said:

ADCCLK prescalre 4, Sample Window 16. All measurements are performed in the scope of one ADC module.

I read that as:

• ADCCTL2.PRESCALE = 0x4. This results in a pre-scale ratio of 3 applied, resulting in ADC_CLK of 200 MHZ / 3 = 66 MHz
• ADCSOC0CTL.ACQPS = 0x16. This results in a  sample and hold (t.sh) of 17 ADC_CLK cycles, or 85ns

That setup results in too fast of a total conversion time. Checkout the AM263x TRM, 7.4.2.12 ADC Timings. And the table below (this will be in an updated TRM shortly). 

Note: SYSCLK in this context is the  chip-level SYSCLK /2 that the whole Control Sub-System receives from the clock tree. So each SYCLK period is 5ns. 

Using that table, ADCCTL2.PRESCALE = 0x4 would result in a Prescale Ratio of 3, and a tEOC of 31 SYSCLK cycles or tEOC = 155ns.

This results in tSH + tEOC = 85ns + 155ns = 240 ns < 250 ns. 

If you want to keep the same ADC Prescale Ratio of 3 (with tEOC of 31 SYSCLK cycles), can you try increasing your sample and hold window to 19 cycles or more (ADCSOC0CTL.ACQPS > 0x18)? With a 19 cycle, or t.SH = 19 x 5ns = 95ns, this will reduce your total conversion time to exactly 250ns, which should function correctly. Based on your fastest sample trigger periods above (1us) you could decrease conversion time by a lot and still be within those limits. Slow conversion time results in lower bandwidth requirements for the rest of the acquisition signal chain as well. 

Please confirm. 

Thank you,

-Randy

Hi Randy!

Randy Rosales said:

• Can you correlate the conversion results you are getting to oscilloscope measurements at the AM263x ADC pins?

Yes, absolutely. I changed the frequency of sending command and I observed increased peaks appearing on the diagram.

Randy Rosales said:

Can you please describe the input signal chain into the ADC pins of the AM263x?

The signal goes from Current-Shunt Monitor NCV213* pin6 via low pass filter to ADC*_AIN*

Randy Rosales said:

Is the current sense you are measuring expected to ramp or oscillate or stay steady state within a few of the faster 1uS measurement periods?

Yes, this is after the initial condition of the boards, and it did not perform any loads.

Randy Rosales said:

What max conversion time do you need? The fastest this SAR will operate is 250ns/conversion  (4Msps). 

The fast measuring we use only for debugging, it is not a normal operation mode. I need to perform measurement each 1.1 uS  (1 / (32 * 28000))

Randy Rosales said:

Can you please describe your full ADC setup again?

Randy Rosales said:

• What is the ADCCTL2.PRESCALE value? 

Randy Rosales said:

What is the ADCSOC0CTL.ACQPS value? 

Randy Rosales said:

ADCCTL2.PRESCALE = 0x4.

It is 0x6

Randy Rosales said:

ADCSOC0CTL.ACQPS = 0x16

it is 0xF  -> "it is 16 system clock cycles wide"

Randy Rosales said:

ADCSOC0CTL.ACQPS

Hi Oleg, 

Thank you for the further info. 

With ADCCTL2.PRESCALE = 0x4 and ADCSOC0CTL.ACQPS = 0x16, I am seeing that that will set a total conversion time of 240ns. That is still too short for this SAR.

Can you try backing off on the conversion time some more? Can you try setting ADCSOC0CTL.ACQPS = 0x19 or higher? With DCCTL2.PRESCALE = 0x4, this should give you a tSH of 100nS, raising your total conversion time to 255nS, which should be fine. Let me know if that improves anything. But with 1.1uS sampling rate, you should be able to increase that tSH much more. The longer the tSH, the lower the bandwidth requirements of the amplifier system feeding the SAR - that might improve the results here.

Oleg Chaichenko said:

The signal goes from Current-Shunt Monitor NCV213* pin6 via low pass filter to ADC*_AIN*

That current shunt amp only has a 90 KHz 3dB bandwidth, so you might need to drop the conversion rate to be pretty slow to get accurate values. Do you have any series R or parallel C element at the ADC pins? For SAR ADC, when they turn on, the inrush ends up being pretty high bandwidth and an additional RC element, or charge-bucket filter can supplement the op-amp drive bandwidth. 

Our C2000 MCU apps teams have released a nice app note and training series on these SAR input circuit concepts - this is all applicable to the Sitara AM263x devices as well. See here: https://www.ti.com/lit/an/spract6a/spract6a.pdf

Oleg Chaichenko said:

Yes, absolutely. I changed the frequency of sending command and I observed increased peaks appearing on the diagram.

Which commands are you referencing here? Is there a correlation between commands being sent on another interface and noise coupled to the ADC channels? 

Thank you,

-Randy

Hi Randy!

Randy Rosales said:

With ADCCTL2.PRESCALE = 0x4 and ADCSOC0CTL.ACQPS = 0x16, I am seeing that that will set a total conversion time of 240ns. That is still too short for this SAR.

Let me clarify:

1. You wrote in hex format. I provide info in decsimal format. (the divider is 4 and the sample window is 16)

2. My chip is the C revision, you provided a screenshot from the E revision, can I refer to the provided table?

3. 

Randy Rosales said:

Do you have any series R or parallel C element at the ADC pins?

Oleg Chaichenko said:

low pass filter

I got info from hardware resources, it is tau = 22K*1nF=22us

4.

Randy Rosales said:

Which commands are you referencing here? Is there a correlation between commands being sent on another interface and noise coupled to the ADC channels? 

It is our internal command

Oleg Chaichenko said:

By request, with a different frequency, at a short period. SOC trigger is the RTI timer. 

It is doing 32 measurements every 1.1 uS and stopped. I repeat this procedure with some frequency and observe peaks on oscilloscope.

for example, DUT is measured every 25ms, and I observe peaks on the oscilloscope.

Regards!

Hi Oleg, 

Oleg Chaichenko said:

You wrote in hex format. I provide info in decsimal format. (the divider is 4 and the sample window is 16)

OK - so that is:

• ADCCTL2.PRESCALE = 0x6, or ADCLK/4
• ADCSOC0CTL.ACQPS = 0xF, or 16 SYSCLK cycles

Sets up a total conversion time of 285nS, which should be fine. I would still slow this down as much as possible based on the restricted bandwidth of your op-amp. Can you experiment with higher pre-scale factors and longer tSH windows? 

Oleg Chaichenko said:

for example, DUT is measured every 25ms, and I observe peaks on the oscilloscope.

Are each of those high pulses when the ADC is sampling? That looks like it might be some kind of transient effect caused by the SAR operation. Can you zoom in on those transient peaks and see what is going on with more detail?

I implemented the equations referenced by https://www.ti.com/lit/an/spract6a/spract6a.pdf. For a 95nS tSH we need at least 38MHz BW amplifier. This matches with the implementation in the Analog Engineer's Calculator as well (https://www.ti.com/tool/ANALOG-ENGINEER-CALC). See the ADC SAR drive section. Insufficient bandwidth on the driving op-amp might account for the issue you are seeing. 

How are you driving the sense lines that are showing the correct conversion results? 

Hi Randy!

I got a little bit confused:

1.

Randy Rosales said:

OK - so that is:

• ADCCTL2.PRESCALE = 0x6, or ADCLK/4
• ADCSOC0CTL.ACQPS = 0xF, or 16 SYSCLK cycles

Sets up a total conversion time of 285nS, which should be fine.

From my calculation it is (S+H) + (conversion time) --> (16 * 5ns) + (11.5 * (5ns * 4prescale)) --> (80ns) + (230ns) --> (310 ns)

2. I am curious about, where you get the acquisition time (95ns) and  the Csh (15nF)

Regards!

--------

UPD:

I increased the  acquisition window from 16 (min) to 512 (max): (512 * 5ns) + (11.5 * (5ns * 4prescale)) --> (2560ns) + (230ns) --> (2790 ns)

Configure RTI SOC trigger for 3 us period. And observe the same issue:

Oleg Chaichenko said:

The lines where I measure current, I observe the next situation:

Oleg Chaichenko said:

When I request measurements on the high frequency with 1 uS, I observe the next behavior: each next measurement gives me higher values than previous, for example, 100, 120, 140,160...300 I have 32 measurements, and the last one gives me three times larger than the first.

Hi Oleg, 

Copying the meeting summary here as well. 

Issue summary

• Two different ADC trigger modes used to sample various analog signals throughout the system:
  • A slower, millisecond scale, periodic trigger and one on a faster (microsecond scale) on-request trigger)
  • Slow trigger would start a conversion every millisecond or so and report back conversation data over CAN to telemetry software
  • Fast trigger starts a 32 sample conversion (RTI triggered), with around 1uS/sample period between RTI ISR. The 32 sample vector of results sent over CAN to telemetry software
• Data from the periodic, slow triggered conversions appeared as expected – averaged, sample data, small variations in LSB, seemed to correlate to activity on the board
• Data from the on request, fast 32 sample conversion was showing ramps in the dataset that did not initially make sense
• One of the specific ADC channels being looked at was responsible for system current, and another for MCU current
• Had an open question of whether these ramping ADC measurements might just be properly capturing the power ramp
  • Oleg had noticed previously that the slow, periodic captures resulted in transient, increased current being captured on the oscilloscope 

Debug summary

• Stepped through the on request, fast conversion ISR ADC conversion/read functions in CCS
  • Stepping through the ISR showed that the resulting conversions appeared steady state, with small LSB variations (as expected)
  • Did not seem to be any problem with ADC pre-scale or sample window setup either
• Setup a few different RTI ISR periods – starting with the 1.1uS default setting be used. This would reduce the total 32-sample time window, but result in a faster sample rate.
  • 1.1uS showed clear ramping
  • 3us showed some ramping
  • 6us showed initial samples ramping, but most of the 32 samples appeared steady state
• Some oscilloscope data was able to be captured in sync with one of the on-request, faster data – looked like it was hard to setup good trigger using the LeCroy viewer software to remotely control the scope
• Looked like these scope shots followed the RTI ISR starting up for the ADC measurements
• My conclusion: this is expected operations. I think we are just “zooming” in and out of the initial current ramp by setting different RTI ADC trigger periods. With the shorter 1.1uS, we are capturing the rising edge of current as the RTI interrupts start firing.

Actions:

• Oleg to get better scope measurements that are synchronized with the on request or periodic measurements and verify that the ADC conversion results are matching expectations.

Thank you,

-Randy