Drehimpulsgeber schiesst ATmega644 ab

[Jaecko]

Moin.

Hab nach langer Zeit mal wieder ein elektr(on)isches Problem mit einem AVR, Kategorie "Kopfnuss aus Granit".
Schaltung: http://cihome.de/forendaten/rn/tr_schaltplan.png

ATMega644 mit 16MHz, soll als Temperaturregler für eine bestimmte Apparatur dienen; soll temperaturabhängig 2 Heizungen/Motor für Rührgerät steuern. Die Bedienung erfolgt über ein 128x64-LCD (KS0108-Controller) und 2 Drehimpulsgeber mit Tastfunktion. Und genau an einem dieser Impulsgeber bzw. den Pins, an denen der angeschlossen ist, gibt es ein Problem. An den VCC/GND-Pin-Paaren des AVR sind direkt noch weitere 100nF-Kerkos gelötet (nicht im Schaltplan eingezeichnet)

Betroffen ist Encoder 1; an PD2 (INT0) ist einer der beiden Signalpins des Encoders angeschlossen. Auf eine fallende Flanke hin wird ein Interrupt ausgelöst, in dem ich mir dann PD0 anschau und in Abhängigkeit des Pegels die Drehrichtung weiss.

Dreh ich in die eine Richtung, scheint alles ok zu sein. Dreh ich jedoch in die andere Richtung, startet mit fast jedem Schritt des Impulsgebers der AVR neu.

Erste Vermutung: Irgendas stimmt mit den Interrupts nicht, falsch konfiguriert, irgend ein Überlauf etc. Darum hab ich das ganze auf nen minimalen Code gestaucht (s.u.), der nix anderes macht, als den an PB4 angeschlossenen Buzzer mal kurz "klicken" zu lassen. D.h. jeden Neustart des AVR krieg ich durch einen Klick mit.

int main(void)
{
  PORTB &=~ (1 << 4);
  DDRB  |=  (1 << 4);  

  PORTB |=  (1 << 4);
  _delay_ms(2);
  PORTB &=~  (1 << 4);

  while(1);
  return 0;
}

Dreh ich in die eine Richtung: stille.
Dreh ich in die andere Richtung: *tickticktickticktick*, also ständige Neustarts bei so gut wie jedem Drehschritt.

Encoder 2 (PD1/PD3) funktioniert perfekt. Auch wenn ich die beiden Encoder umstecke, bleibt das Problem bei dem, der an PD0/PD2 angeschlossen ist.

Auch der Verdacht, dass evtl. der Quarz gestört wird, dessen Pins ja direkt daneben verlaufen, haben sich als nicht ganz zutreffend erwiesen. Ich kann zwar am Oszi sehen, dass beim Drehen des Encoders XTAL2 kurz mit der Spannung leicht hochgeht. Aber auch, wenn ich auf den internen Taktgeber mit 8 MHz umschalte, (und auch den Quarz auslöte) bleibt dieses Problem bestehen.
Ansonsten kann ich mit dem Oszi keine weiteren Spannungseinbrüche o.ä. sehen.
Auch die Art der Spannungsversorgung spielt keine Rolle. Sowohl über ein 12V-Netzteli über den 7805, als auch direkt versorgt über ISP gibts das Problem.

Gibts da beim M644 irgendwas bestimmtes zu beachten? Oder weiss jemand, was das sonst für ein Problem sein könnte?

MfG

[Holomino]

Kann eigentlich nur der Reset oder die BOD-Fuse sein, wenn die Versorgung i.O. ist.
(1k am Reset finde ich "knapp")

[Jaecko]

Thx, das mit dem BOD scheints tatsächlich gewesen zu sein. War auf 4,3V gesetzt. Habs jetzt auf 2,7V runter; ich dreh mir grad nen Wolf und bisher tickt nichts.
Aber da wunderts mich etwas, warum das dann nur bei Encoder 1 hackt und beim 2er nicht.
Das mit den 1k am Reset mach ich eigentlich "schon immer" so, da gabs bisher eigentlich nie Probleme, solange man nicht direkt mitm Finger auf die Resetleitung langt.

MfG

[Holomino]

Das tut aber nicht not. Du hängst einen Kondensator dran, der Dir Spikes auf dem Reset filtert und lutschst Ihn über den 1k- Widerstand gleich wieder leer. Übliche Werte sind 4.7..10k.

Noch eine Anmerkung: Deine Entprellung schaltet den gesamten Strom in den Kondensatoren auf die Masse kurz, wenn die Encoder schließen???!!!???
Vielleicht ist das die eigentliche Ursache des Problems.

[oberallgeier]

.. BOD scheints tatsächlich gewesen zu sein. War auf 4,3V gesetzt. Habs jetzt auf 2,7V runter; ich dreh mir grad nen Wolf und bisher tickt nichts ..

Also mir wäre das ein sicherer Hinweis darauf, dass die Controllerspannung kurzzeitig gestört ist. Siehe Datenblatt ATmega164A/164PA/324A/324PA/644A/644PA/1284/1284P (Atmel-8272G-AVR-01/2015), Seite 326, 28.4 System and reset characteristics: .. tRST Minimum pulse width on RESET Pin 2.5 μs .. Wobei das (grübel - wenn ich mich nicht irre) 40 (vierzig) Controllertakte bei Deiner Quarzrate wären. Das hätte Dein Oskar doch eigentlich anzeigen müssen - und die 2.5 μs sind ja aussagegemäß das Minimum *kopfschüttel*.

[Jaecko]

Leider zu früh gefreut (zumindest teilweise). Ne halbe Stunde ca. gings und jetzt gehts wieder los. Gleiches Problem wie oben, sogar bei BOD = 1,8V. Hab auch mal den Reset-Widerstand etwas erhöht (5,6k), ebenfalls keine Änderung. Das Oszi würde sogar bis 40MHz/25ns gehen. Hab auch grad nochmal nachgemessen; der Spannungsregler spuckt hinten 4,95V aus, schön glatt; da hätte der BOD (wenns der gewesen wäre) ja noch garnicht triggern dürfen. Auch direkt in der Nähe des AVR ist nichts zu sehen, wenn gedreht wird. Reset ist auch sauber.

Ich hab jetzt mal spontan den AVR gegen einen 644P getauscht, den ich schnell aus nem anderen Projekt gepflückt hab. Da gehts dann. 644 (ohne P) wieder rein: tickticktick.
Hab jetzt gut 5-6x den AVR hin und hergetauscht, mit immer dem gleichen Ergebnis: Mit dem 644er scheints das Problem zu geben, mit dem 644P nicht. Scheint so, als hätt ich nen AVR erwischt, der scheinbar ab Werk schon nen kleinen Schlag hat (ist ja jetzt vermutlich nicht unbedingt auszuschliessen).

Ich werd das jetzt mal weiter beobachten, ob das Problem beim 644P tatsächlich weg bleibt oder sich auch nach und nach wieder reinschleicht.

MfG

[Klebwax]

Etwaige Störungen oder Spannungseinbrüche sind manchmal nicht so leicht zu messen. Was wirklich zählt, ist die Spannung direkt am Die, am Silizium. Dort läßt sich so einfach nichts messen. Das nächstbeste ist direkt am Baustein, aber mit beiden Anschlüssen des Scopes. Störungen können auch über die Masse kommen. Aber auch Stromstöße über Portpins können intern einen Reset auslösen.

Noch eine Anmerkung: Deine Entprellung schaltet den gesamten Strom in den Kondensatoren auf die Masse kurz, wenn die Encoder schließen???!!!???

100nf sind schon eine ganze Menge. Sie machen das Signal auch so langsam, daß es lange im verbotenen Bereich des Eingangs bleibt. Das kann zum Schwingen des Eingangs führen. Solange Prozessor und Encoder auf dem selben Board sind, gehören da gar keine Kondensatoren hin.

Ein zweites Problem ist die Verwendung eines Flankeninterrupts. Wenn das Signal prellt, und das könnte z.B. von der Drehrichtung abhängen, wird ein Interruptsturm ausgelöst, auch das kann zum Absturz führen.

Ein brauchbare Lösung ist das regelmäßige Abfragen der Encoderleitungen. das Prinzip ist hier beschrieben. Wenn man sowieso einen Timertick hat, und den braucht man eigentlich immer, sind das nur ein paar Zeilen Code. Das ist das gleiche Prinzip, daß die Hardwaredecoder, die manche Prozessoren eingebaut haben, auch verwenden.

MfG Klebwax

[RoboHolIC]

Such mal bei Pollin nach panasonic eveq.
Das Datenblatt, Seite 2, zeigt eine Beschaltung des Encoders mit Kondensatoren und Widerständen. Die 10nF-Kondensatoren werden dort über Widerstände von den Encoder-Schaltkontakten entladen statt kurzgeschlossen. Das hat vermutlich nicht nur mit der Lebensdauer zu tun.
So ganz ohne Dämpfung ist vielleicht auch nicht perfekt. Ich vermute, dass Kontakte auch beim gleiten springen/prellen können, wenngleich wesentlich kurzzeitiger.

[Michael]

Die 10nF-Kondensatoren werden dort über Widerstände von den Encoder-Schaltkontakten entladen statt kurzgeschlossen. Das hat vermutlich nicht nur mit der Lebensdauer zu tun.

richtig, so und nicht anders wird es gemacht.
Die Schaltung nach Beitrag #1 ist, gelinde gesagt, Murks.
Die Kontakte verbrennen und die Versorgung leidet unter Spikes, das Ergebnis ist ja bekannt.

Gruß, Michael