Mega164 -- ADC affects pin change?

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a weird one for me. It's not like I've never used pin-change interrupts over the years, and sometimes as critical parts of the app.

A four-channel "signal processing" app with a Mega164. Original boards had ATmega164PV-10AU. Also tried were A and PA with the same symptoms as below. 5V; 7.37MHz.

Each input channel has a small daughter board to handle a variety of input signals. The module in question handles 0-5VDC, 0-10VDC, 4-20mA, and pulse inputs from a flowmeter--typically up to 100Hz full-flow.

(Below, "protdiode" refers to DLPT05 "TVS DIODE 5VWM 9.8VC SOT23-3" to/from rails)

Rough description of signal chain: input terminal -- gain resistors -- RC -- opamp -- protdiode -- main board -- protdiode -- RC -- ADCpin.

The four input channels go to ADC pins PA0-PA3. I'm set up to do continuous round-robin ADC conversions on the four channels, with an ADC clock of 57.6kHz, and conversion-complete ISR that starts the conversion on the next channel. I've done this on many many AVR production apps.

To address the flowmeter "Hz" input, I sez to myself: "Self, let's do a bank of pin-change, with a mask for the channel(s) that are configured as Hz inputs."

Fire up the code, and the Hz input and processing and display worked--except that the Hz value is about 15% too high. Further instrumentation and inspection with 'scope and such indicates that there are spurious pin-change hits. A 100Hz input signal expects 200 pin change hits per second. Actual is about 230.

Indeed, due to the RC the falling edge has a time constant. But the time to fall between e.g. logic high and logic low is fast enough--about 50us to 100us. The signal looks dead clean on a 'scope trace. Right at the AVR pin.

NOW HERE IS THE FUN PART:

Let's take the PA0 channel that is getting 230 when 200 is expected. If the ADC operation is changed so that no conversions are done on ADC0, the symptoms [mostly] go away. Instead of about 30 extra hits every second, it drops to a spurious hit every 5 to 10 seconds.

The 'A seems marginally better than the 'PV.

I've convinced myself that there is "something" inside the AVR, at least on this model series, where pin-change is affected by ADC. I'd speculate that during the sample-and-hold on PA0 it affects the pin-change internal level somehow.

All speculation. Any other ideas?

I'm going to fall back to fast-poll of the signals...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
I've convinced myself that there is "something" inside the AVR, at least on this model series, where pin-change is affected by ADC. I'd speculate that during the sample-and-hold on PA0 it affects the pin-change internal level somehow.

All speculation. Any other ideas?

I'll see your speculation and raise you wild conjecture.

I've Never worked with the 164 (or friends), but a while ago I started to do some deep digging into the ADC on the 328P.

One of the things I found which in hindsight was not really surprising is that charge accumulated by the S/H cap during a conversion on one channel will be dumped onto the pin for the next channel converted.

This charge is of course in the range of pico-coulombs, but depending on the input circuit path this can produce a significant voltage change on that channel. Although you might have a relatively low impedance on the last leg of the signal chain into the AVR's ADC channel (a few K?), the 14 pF S/H cap and the 2-5 pF pin capacitance will come into equilibrium pretty rapidly, causing a small but sharp local voltage change on that pin. If that voltage change crosses the pin-change detection threshold, it could trigger an interrupt.

For example, imagine you've just sampled a channel sitting near AVcc, and next you sample a channel sitting slightly below the rising edge pin-change threshold (accounting for hysteresis). The S/H cap will be sitting near AVcc, and when the MUX switches to the new channel it will dump charge into the new channel's pin, perhaps crossing the pin-change threshold.

I suppose you could validate/invalidate this theory by contriving a test that controlled for the input voltage of your various channels. Trigger MUX changes and observe any pin-change events.

If this proves to be contributing factor, and depending on the slope (rising or falling) of the guilty 'spike', a solution might be as simple as inserting a sample of channel 31 (GND) to bias the S/H cap to 0V, or to a 'dummy' channel tied to AVcc.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you cannot see a spike on scope right at the MCU pin, then it is something internal.

But it is not a first time that sampling with ADC will cause spikes but usually they are seen externally. In another microcontroller it always affected ADC channel 0 pin.

What RC filter component values you have there, which op-amp? Does the op-amp have high enough bandwith (and current driving ability) to drive the ADC input when it gulps current?

Are the daughterboards well grounded to main board ground, so that spikes on other converted channels do not bounce the ground and cause bounces on PCINT pins?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What RC filter component values you have there, which op-amp? Does the op-amp have high enough bandwith (and current driving ability) to drive the ADC input when it gulps current?

I understand why you'd be asking that, but does it really matter when the 'scope trace looks very very clean?

Lessee--LM358, unity gain, single supply (5V). Series R 10k; 100nF to ground.

Indeed, the RC is about 50mm from the ADC pin in this layout. And I just used my common bench equipment Tek TDS2024 200MHz 200Gsps. The signal looked "dead clean" as I mentioned. No hint of anything spiky. In "envelope" mode there is a bit of drift (the input is a very old analog signal generator) but nothing at all spikey.

I tried lower and higher frequencies, but let's noodle with a nominal 100Hz. I expect 200 edges each second; see about 230.

100Hz is 5ms high 5ms low. Rise time negligible; fall time maybe 200us to get very close to Gnd.

Continuous interrupt-driven ADC conversions. Nominal conversion time at 57600 ADC clock is 225us so let's estimate 250us per conversion. For each input square wave cycle of 10ms that would be 40 ADC conversions; 8 on each of the 5 used channels. About 4000 conversion per second total.

As the 100Hz input signal and the ADC are not in sync a S/H eventually will occur at any time in the input signal period, right?

About 30 extra hits each second; 4000 ADC conversions. An extra hit about every 130 conversions.

Quote:

If the ADC operation is changed so that no conversions are done on ADC0, the symptoms [mostly] go away. Instead of about 30 extra hits every second, it drops to a spurious hit every 5 to 10 seconds.

The interesting part is that the bad hits did not totally go away. THAT surprised me.

The above wasn't good enough to satisfy me, so I switched to fast-poll which I was trying to avoid. 400us poll rate lets me reliably and accurately count input pulses up to 1000+Hz. Most flowmeters we use are more like 100Hz at max rate so now I'm happier.

While the pin-change seems to be affected, no apparent problems with PINA itself.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.