crash/reset when using debouncing cap on pcint port

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

This is using an attiny861a but I don't think it's limited to this model.

It has, a.o, three ports used for counting two of them on port A, which have no problems whatsoever. The third, on port B, is "strange", it's on pin 9, between the crystal (7/8) and reset (10) (maybe that matters).

All of the inputs have their PCINT enbled and working. The weirdness begins when I connect a 3 ft coaxial cable to the strange input (pin 9). Whenever the cable is shortened (which should give an interrupt), the controller resets.

The reset only happens when the 3 ft cable is used AND a debouncing cap is used (100 nF). If the pins are shorted directly OR the cap is left out, it works as designed.

The others ports on "A" work fine, with debouncing cap and 3 ft cable.

These are the possible (but ineffective) solutions I've tried:

- disable PCINT altogether, controller still crashes, so apparently it's not a software bug
- use smaller caps, didn't help
- use clamping with two 1N4148 diodes
- use 5V1 zener

None of this helps.

I guess I am creating some sort of RC-circuit with the cable and the capacitor and the input voltage rises above Vcc? But why don't the other ports suffer from this?

The controller gets it's Vcc from USB, which is stabilised using an elco, a 5V1 zener and two 100 nF caps (Vcc and AVcc).

I am totally puzzled...

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

Forgot to mention: also tried both internal and external pull-ups, in various values.

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

The preferred way was debouncing in software.
It cost no remarkable code size nor CPU load.
And once programmed, it was easy reusable on other projects without any effort.

But a debouncing cap was a devilish thing.
A switch has almost zero ohms.
So on closing the switch there can flow several 10 Amperes, which may influence anything.
Thus a debouncing cap need always at least about 100 Ohms in series to limit the discharge current.

Peter

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

Quote:
Whenever the cable is shortened (which should give an interrupt), the controller resets.

Any specific reset source?
As mentioned, use RC low pass filter, not a capacitor only or you can ruin the switch. The charged C shorted in parallel with inductance of the wire should oscillate till the energy is dissipated (can take some time).

No RSTDISBL, no fun!

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

danni wrote:
The preferred way was debouncing in software.
It cost no remarkable code size nor CPU load.
And once programmed, it was easy reusable on other projects without any effort.

But a debouncing cap was a devilish thing.
A switch has almost zero ohms.
So on closing the switch there can flow several 10 Amperes, which may influence anything.
Thus a debouncing cap need always at least about 100 Ohms in series to limit the discharge current.

I didn't mention that the ports are going to be triggered by a phototransistor, there is no switch. I am just short-circuiting the lead for testing.

I was under the impression that a 100 nF cap won't hold an enormous amount of charge. Still I think you have really good point there, I will certainly add such a resistor.

Software debouncing is out of the question here, for various reasons, one of them is the flash being completely full and no optimisations left...

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

Brutte wrote:
Quote:
Whenever the cable is shortened (which should give an interrupt), the controller resets.

Any specific reset source?

No sorry, I really don't know. I have two leds connected that flash a certain pattern on code start, and all I can see that every time I do this, the init code is called, so I assume it's a reset. I also assume it's not a crash, because it never freezes, gets unpredictable etc, it just resets.

Talking about reset, maybe I should add an external pullup to the reset line? But it needs to remain useable for isp.

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

Quote:
Talking about reset, maybe I should add an external pullup to the reset line?

Clear MCUCSR (write 0x00), set a breakpoint at 0x0000, run the application and make the "wire reset". When the chip hits that breakpoint then post the MCUCSR value in here.

No RSTDISBL, no fun!

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

I will try that when I get home.

What are you expecting to see in MCUCSR? I guess something else than 0x00, but what then? I don't have the datasheet handy right now, but I already tried with all interrupts disabled and still the reset took place. Apparently it doesn't go together with the PCINT interrupt.

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

The MCUSR has flags for what caused the latest reset (Watchdog, Brown-out, External, Power-on).

Quote:
I don't have the datasheet handy right now

On what strange part of The Web are you, where you can post to AVRfreaks but not d/l a data sheet from Atmel? :roll:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
The MCUSR has flags for what caused the latest reset (Watchdog, Brown-out, External, Power-on).
Just to be clear, the flags will show not only the latest reset source, but all previous reset sources since either A) the last power-on-reset, or B) the last time the flag was cleared by software.

It's a subtle but important distinction.

After a clean power-on reset, the only flag that is set is PORF. If the device then experiences an external reset, both the PORF and EXTRF flags will be set. If the device then experiences a brown-out reset, the three flags PORTF, EXTRF, and BORF will be set. Finaly, if the device then experiences a watchdog reset, all four flags will be set.

The only way to clear BORF, EXTRF, or WDRF is via software by writing 0 to those bits. They are also cleared when the device experiences a power-on reset.

The only way to clear PORF is via software by writing 0 to PORF.

JJ

"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

JohanEkdahl wrote:
The MCUSR has flags for what caused the latest reset (Watchdog, Brown-out, External, Power-on).

Yes I remember now. That's a pretty smart advise, will try that too!

Quote:

On what strange part of The Web are you, where you can post to AVRfreaks but not d/l a data sheet from Atmel? :roll:

It's called data roaming in Europe. It means you pay mile-high fees for every mb you download once you leave your country, in this case I'm only about 250 km from the border... Web access is still more or less affordable, downloading documents of 40 mb is unfeasable. I should have put them on my laptop.

Next week I'll be back home and be able to implement all advise given here, thanks!

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

Quote:

I should have put them on my laptop.

If you have flat-rate at home, then leaving the computer on overnight to download this from time to time works wonders.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

danni wrote:
Thus a debouncing cap need always at least about 100 Ohms in series to limit the discharge current.

This indeed fixed the issue.

Thanks!